Re: HSTS preload flaw

> On Feb 9, 2020, at 02:30, Rob Sayre <sayrer@gmail.com> wrote:
> 
> On Sun, Feb 9, 2020 at 12:05 AM Austin Wright <aaa@bzfx.net <mailto:aaa@bzfx.net>> wrote:
> I don’t think you can call this a bug.
> 
> I think it's a bug, but reasonable people can disagree. An "unintentional difference in behavior" is another way to describe this report.

A difference in behavior is fair to point out, and I’d even agree people might assume all user agents will have the same HSTS behavior; but I think the best we can do is point out that HSTS is optional to implement; so if a user agent is missing this feature, that should be reported as a feature request, not as a bug.

If encrypted connections are important to you as a server operator, it seems the only foolproof way to avoid plaintext communication is don’t listen on port 80.

>  
> As far as I know, this behavior is not standardized as any part of HTTP, but is described and centrally managed by Chromium project. That is, it’s a feature of Google Chrome and nobody else is under any obligation to implement it.
> 
> HSTS is defined by RFC 6797. It's true that the preload list can vary between versions of browsers, but in this case I found that the macOS versions of browsers other than Safari had these TLDs preloaded, while the iOS versions of these browsers did not. I understand why this happened, but I think it would be a stretch to call it intentional. The discrepancy existed for over a year, and no browser vendor seemed aware of it.

The preload list isn’t a part of RFC 6797, which is itself optional to implement.

>  
> And even if it was, I don’t really see how you can say “At least 600k domains were impacted”. What would an attack look like? You have to have a user-agent willing to send a sensitive payload in plaintext, and a server with port 80 open to receive it.
> 
> 600k is a conservative estimate based on the number of domains that seemed to be registered under these TLDs. Any browser without these TLDs preloaded would first attempt to connect via HTTP if supplied with an http:// URL or a schemeless URL (like "foo.dev <http://foo.dev/>").  At that point, any server could provide a response. You might think "surely there will be a scary warning", but this actually was not the case in all browsers, especially on mobile phones. Safari did say "Not Secure" in the address bar, but other browsers just showed an "(i)" info icon instead of a lock, so a user would have to notice the absence of a lock.

Note that even TLS will indicate which domain you’re connecting to. If server operators make diligent use of HttpOnly and Secure for cookies, the only information at risk is the path component of the URI you’re connecting to, your user-agent details, and maybe a payload (if you can figure out a way to get an HTML form to POST to an http: endpoint without a warning).

But I agree I’d like to see better privacy designed into first-time connections. I know the HTTP WG is working on a new DNS record specifying connection requirements. Unfortunately it seems this new scheme would also be optional, and probably not widely implemented for some time.

Personally, I would like to see a new “web:” scheme that mandates usage of SRV, or the proposed HTTP service record, whatever it ends up being named… this new URI scheme would effectively require that clients understand the security requirements before connecting. People pointed out this would be a barrier to adoption; but for some applications, this is entirely the point.

Cheers,

Austin.


> 
> thanks,
> Rob
>