Re: HSTS preload flaw

Hi,

On Sun, Feb 9, 2020 at 3:47 PM Austin Wright <aaa@bzfx.net> wrote:

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

Well, the contents of the list itself are not part of the RFC, so it is
possible to spec-lawyer one's way into saying this isn't a bug (and maybe
that's reasonable).

This topic is covered in RFC 6797, though. See "12.3.  HSTS Pre-Loaded
List" https://tools.ietf.org/html/rfc6797#section-12.3

That section discusses "the bootstrap MITM vulnerability" at hand here. A
second problem with these TLDs is that they were marketed with their
presence in the HSTS pre-load list as a benefit, but not even the owner of
these TLDs got this HSTS pre-load implemented in all of their products.



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

I don't agree with this analysis. There are several ways to escalate this
attack once you get the user to load a single HTTP page without realizing
they've been mislead. If they're using an app, they probably won't get any
indication there's a problem. Ultimately, I'm glad this behavior was
improved in iOS, macOS, tvOS, watchOS, and for many apps running on them.
As in the top post, I hope we can start automating HSTS list checks using
continuous integration or telemetry.

thanks,
Rob