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

The HTTP Alternative Services header can be abused to conduct network reconnaissance and attacks, to bypass malware protection services, and to foil tracking defenses and privacy assumptions, according to a paper scheduled to be presented at the WOOT '19 security conference on Tuesday. Back in March 2016, the Internet …

  1. pavel.petrman

    They haven't been particularly responsive

    We have been trying to communicate with them, but they haven't been particularly responsive... And why would they? Google seems to be in full Microsoft-in-the-00's mode, owning their users fully and completely. It looks to me that the business model at Google is to own everything they can, build a nice walled garden for theis users subjects and fsck the rest. Which of course works nicely for everyone who expose themsevles to Google willingly or unwittingly. For the rest, though - tough luck. Just when the desktop alternatives became good enough for the average Joe, there is a new plague in store for us.

    1. Robert Helpmann??
      Thumb Up

      Re: They haven't been particularly responsive

      They also implemented this attack on Chrome and Chromium-based Brave using QUIC as an Alt-Svc endpoint. ...QUIC is currently hidden from Chrome users behind an experimental flag and must be activated by the user.

      Google's business model notwithstanding, this is one of the few instances in an article concerning security where the fix was out ahead of the problem being inflicted upon the masses. Bravo for that!

    2. Notas Badoff

      Re: They haven't been particularly responsive

      "We have been trying to communicate with them, but they haven't been particularly responsive..."

      Don't forget Hanlon's Razor and friends. There could be incompetency involved.

      Recently was surprised to see a chrome bug report of some years' note get resolved with a fix. Then I remembered that the particular Googly Humpty Dumpty who read one line of a spec differently from all the other browser developers had some few months before that moved back home to Australia.

      It can be the spec reader at fault rather than the spec.

    3. Anonymous Coward
      Anonymous Coward

      The HTTP extensions Google pushes are to serve Google

      If you think they want to make the web faster to improve your experience, you're wrong. They want to make the web faster so they can deliver more ads, and reduce the speed gain you get by blocking ads so you (hopefully) have less reason to do so.

  2. Anonymous Coward
    Anonymous Coward

    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.

  3. Orv Silver badge

    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...

  4. GnuTzu

    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.

  5. Anonymous Coward
    Anonymous Coward

    Concept fundamentally flawed from the first line

    To quote:

    1. Introduction

    HTTP [RFC7230] conflates the identification of resources with their

    location. In other words, "http://" and "https://" URIs are used to

    both name and find things to interact with.

    In some cases, it is desirable to separate identification and

    location in HTTP; keeping the same identifier for a resource, but

    interacting with it at a different location on the network.

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

    1. Anonymous Coward
      Anonymous Coward

      Re: Concept fundamentally flawed from the first line

      I'm sure it wouldn't take much to start ripping that "specification" to bits on security and technical grounds but I stopped reading at the second paragraph, as the idea is so patently flawed.

      Now I'm trying to find out how a) if alt-svc comes enabled in Firefox and b) how to disable it.

      1. Anonymous Coward
        Anonymous Coward

        Re: Concept fundamentally flawed from the first line

        Ok, found it:

        about:config → network.http.altsvc.enabled → false

        Note that at one point the preference was misspelled as network.http.atsvc.enabled. That was fixed years ago so you shouldn't come across the old spelling.

  6. Anonymous Coward
    Anonymous Coward

    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"

  7. Michael Wojcik Silver badge

    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 authors1 came up with for this. Anyone know offhand?

    1Incidentally, 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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like