Header aches in Firefox, Tor, Brave and Chrome as HTTP opens new security holes

Tor Browser != Tor

Nitpick: having read the paper in question, its authors - and by extension this article - have repeatedly said Tor when what they really had in mind was the Tor BROWSER. Example quote: "function of browsers that support Alternative Services (such as Firefox, Tor, Brave and Chrome)". Just to be clear on the subject:

- Tor - either the software developed by the Tor Project implementing onion routing or the anonymity network based on said software. Client use of Tor does *not* require using any specific Web browser, or even HTTP at all - any network traffic will do as long as it can be tunnelled through a SOCKS proxy;

- Tor Browser - Firefox ESR-based Web browser developed by the Tor Project aiming at providing more security to users browsing the Web over Tor comparing to connecting a general-purpose browser to the Tor network by SOCKS.

Oh, and for completeness:

- Tor Browser Bundle - a software package published by the Tor Project containing the Tor client, Tor Browser and a bunch of glue code, allowing less technical users to connect to the Tor network with minimum hassle.

Wow, this sounds a lot like the FTP PORT security hole, as detailed in this old CERT release:

Problems With The FTP PORT Command or Why You Don't Want Just Any PORT in a Storm

That paper is listed as 2002, but the copyright date is 1998 and there are references to the problem dating back to 1995. We've literally known about this type of issue for 24 years, and yet...

Proxy Headaches

Yet another thing proxies will have to find a way to mitigate. And, I can tell you that simply stripping headers is a sure way to piss off users--so that's not an option. This one is not going to be easy to deal with. Yet, because the browser suppliers are slow to step up, this will surely be something that will be added onto the burdens placed on proxies until... after we all fade into history. Home users and smart phones (the un-managed ones) are simply going to be out of luck.

Concept fundamentally flawed from the first line

To quote:

Well, use another protocol where URI ≠ URL, for heavens sake!

localhost with Martian addresses

"The secondary host could even be a private IP or localhost, and the port could be on the browser’s HTTP port blacklist."

I've seen an example of something similar on a Russian language website where "tclclouds[.]com" was seen in router logs getting inside the LAN.

It makes me also wonder about the Facebook owned "scanandcleanlocal[.]com"

For the love of...

So, RFC 7838 explains (implicitly) how this is different from a simple HTTP redirect. It's transparent to the client. It's transparent to TLS - the alternative service has to provide a certificate that's valid for the original origin server. It's transparent to the request - the Host header doesn't change, for example.

What it doesn't say is why. Why is any of that desirable? The ostensible aims of Alternative Services, as explicitly detailed in the RFC, are all satisfied by HTTP redirects. (For that matter, some of them are satisfied by reverse proxies for many use cases, or by periodically terminating persistent connections and forcing clients to reconnect, the overhead of which amortized over many requests is negligible.)

I haven't tried to trawl through the discussion archives for the I-D to figure out what justification the authors¹ came up with for this. Anyone know offhand?

¹Incidentally, and while I don't mind the Google-bashing above (which is well-deserved in general; QUIC and the like are a pox), the authors of 7838 are from Akamai, Mozilla, and greenbytes. (The last, of course, is Julian Reschke, author of a number of HTTP features.) So usual suspects, in other words, but not directly the usual suspects of Google.