Re: HSTS preload flaw

On Sun, Feb 9, 2020 at 12:05 AM Austin Wright <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.


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



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

thanks,
Rob