Safari 15 iOS Bypasses proxy.pac PROXY setting for HTTPS 400 code

Question

Created Oct ’21

Replies 2

Boosts 1

Views 2.7k

Participants 3

We use a proxy.pac file to redirect connections to blacklisted URLs by PROXY-ing the request to a local server proxy. For example, the proxy.pac file sends requests to https://unwarranted.tracker.website/?whatever to

PROXY http://my.blackhole.server:8119

This has worked for years on Safari iOS, and still works on Safari macOS, but has stopped working for HTTPS requests on all i-devices after updating to Safari on iOS/iPadOS 15. Most requests are HTTPS.

The observed behavior is that Safari 15 bypasses the PROXY and sends requests to https://unwarranted.tracker.website/?whatever.

I hypothesize the reason is that the proxy returns 400 for such HTTPS CONNECT requests. Its behavior, expected for HTTPS CONNECT requests,looks like:

curl -I --proxy http://my.blackhole.server:8119 https://unwarranted.tracker.website/?whatever. HTTP/1.1 400 Bad Request Server: nginx/1.21.3 Date: Sat, 25 Sep 2021 19:17:07 GMT Content-Type: text/html Content-Length: 157 Connection: close

curl: (56) Received HTTP code 400 from proxy after CONNECT

Is bypassing a proxy.pac’s PROXY if the proxy server returns a 400 code expected behavior for Safari iOS?

We would like to be able to block unwanted requests on iOS with a proxy.pac file.

Boost

Answer 1

vityachis OP

Oct ’21

I agree: "We would like to be able to block unwanted requests on iOS with a proxy.pac file."

Why, if the proxy is not available, does iOS let traffic go? Is this a bug? When will this be fixed?

2

Answer 2

juan.lbc OP

Dec ’21

This needs to be addressed asap. As the OP stated, this has worked for years until iOS 15 (to my knowledge as I've just recently discovered this loophole). As for Safari on MacOS, I cannot validate that claim since I haven't used Safari as my primary, goto browser for many, many years but for iOS, it's seemingly the only good choice because of good adblocking extensions (other iOS browsers, minus iCab lack adblocking extensions).

On MacOS: Firefox and Brave on MacOS DO NOT bypass proxy.pac, blocking websites specified by the proxy's ACL, as expected while Safari on MacOS DOES bypasses proxy.pac.

On iOS: Firefox, Firefox focus, Safari DO bypass proxy.pac (my guess is because Apple forces developers to develop browers using Safari's rendering engine).

We use a proxy to help stop tracking at the OS level so that all traffic filtered. All other apps that access the internet are filtered.

My testing has concluded this issue is specific to only Safari across both platforms most likely due to Apple's implementation of Private Relay. You'd think the issue would be resolved if Private Relay is disabled but the setting (enabled or disabled) has no effect.

I believe this is an issue (or bug) with Private Relay. Disabling Private Relay should address Safari bypassing proxy.pac but it doesn't. What I am unable to confirm, however, is whether or not all Safari traffic is directed to Apple's server even if Private Relay is disabled. Seems plausible because a cross reference with Squid proxy, it can be configured to ignore ACLs and provide direct connections to website (meaning all requests can be direct to proxy server and proxy will ignore ACLs). If anyone can shed some light on that, please do.

For consideration, Safari extensions, such as 1Blocker, can fill in the gap here.

1