Skip to content

Thoughts on the HTTPS Unholy PAC Exploit

For those not familiar with HTTPS, here's a quick rundown: It works just like regular HTTP, except that there is an end-to-end layer of encryption applied so that intermediate servers/people can't snoop on the contents of the communication. This matters for obvious things like online banking & shopping, but also helps keep your social media details and-the-like private—don't want someone seeing your login token, then using that to post all manner of truly horrible things without your knowledge or consent especially since you'd be held responsible—after all, it was done with your login token.

The take-home is in what HTTPS is supposed to allow potential attackers to see (because anything you do tells your attacker something):

  • The IP address of the host you're sending the request to
  • Your IP address
  • The ciphertext request that you're sending to the host

And that's all.

Now, this exploit arises from the way that Web Proxy Autodiscovery works. A web proxy is a server that ideally allows other machines on the network navigate the local topology in order to find things—a guide, as it were. In the usual case, there is no proxy, and your computer uses whatever DNS servers are associated with your network. Should you request the URL https://www.google.com/search?q=my+little+pony, your computer securely requests the DNC records for www.google.com, and packages up a request to the IP that gets returned. An attacker knows you contacted a DNS server, and that you contacted a google server (DNS records are public, after all, and they can reverse-lookup the IP) — but that is all.

Proxies change that. When a proxy is in the mix, you can't necessarily use the results of the DNS server lookup to prepare your route. Instead, you package up your request, and tell the proxy server, "Hey, deliver this request to https://www.google.com/search?q=my+little+pony". Therein lies the problem: You've leaked some details about your request to whoever controls the proxy. Now, for the example given, you just now know about someone's My Little Pony fetish. But many sites errantly believe that the URL is always hidden as long as HTTPS is in use, and so attach login tokens, password reset tokens and-the-like directly into the request URL. Now an attacker that controls the proxy can get far more that they would otherwise.

The sad part is that your computer isn't passing the entire request URL due to some error, but rather that's what is required by the spec. I suppose the idea at the time was to allow the proxy to handle different paths within the URL differently, but to be honest: There's no real good (both morally and practically) reason for this—in the non-proxy case, there's no provision for doing server lookups differently based on the URL's path, only its host. Yet, that's the proxy spec we ended up with—hell, [tinfoil hat, activate!] it was probably so that advertisers could advertise easier[/tinfoil hat].

The "fix" (as is the fix to so many, many things) is to lie to the proxy: Only tell it to send to the hostname, and have the path component only in the encrypted request—which it is already, due to a different, older spec. In a turn of events that I found somewhat bewildering (in a good way), Microsoft's Edge browser (and technically, IE11, too—but, just, no.) already does this. So… good on them, and hopefully other browser manufacturers will jump onboard quickly. As an end-user, there's not much you can do (I mean, unless you like Edge) other than lean on browser manufacturers and site webmasters.

Appendix For Webmasters:

Login tokens should always be in the form of a cookie, and people should be required to have 1st-party cookies turned on—the cookie is always securely on the encrypted part of the request, after all.

Password reset emails are more tricky, in that people like having a simple-to-click link right in their email. Moving to a two-step could be a possibility: The email contains a link and a code, where the link is to a form accepting their email and the given code. It prevents the proxy attack, but any email you send to a user might itself be sent over-the-clear.

P.S. When looking for a banner for this post, my search for thing related to "proxy" turned up quite a few images that literally just said "proxy" over-and-over. Well trolled, internet. Well trolled.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *