Can anyone who runs a high trafficked site and isn't on the HSTS preload list explain why not? I am genuinely interested.

There's a lot of pressure to turn the includeSubdomains flag on, with the new Google Submission Process (submit a form to hstspreload.appspot.com).

Not all businesses are in a situation where they can just turn on HTTPS across all subdomains. I'm sure agl will make exceptions if you reach out and are a high traffic site.

CSP, HSTS, and HPKP were all known to be exploitable for "supercookie" purposes, but not history sniffing like this.

So it's fair to call this a novel attack.

No. Leaks were known far beyond the "supercookie", but attacks were not as high quality as these.

Could you link some older sources discussing some of these leaks? I'm having trouble finding any. Not doubting you, since you're probably right; would just be interested in reading them.

[edit - just realized this may not answer the question you asked, which is leaks that take advantage of HSTS/HPKP/CSP. hopefully still useful info.]

I may write a blog post later about this, but here are a few that come to mind (only counting things that have demos or have been observed in the wild):

* css-visited browser history sniffing (fixed several years ago): http://dbaron.org/mozilla/visited-privacy * HSTS unique-subdomain combination supercookies: http://www.radicalresearch.co.uk/lab/hstssupercookies * lcamtuf's cache timing attack: http://lcamtuf.coredump.cx/cachetime/ * webrtc local ip leak: https://diafygi.github.io/webrtc-ips/ * panopticlick: https://panopticlick.eff.org/ * evercookie: http://samy.pl/evercookie

AFAIK most of that info is in HN and twitter discussions between webappsec people. Here's a link[0] to a CSP leak that was briefly discussed on the webappsec mailing list. I also know Homakov wrote one[1].

That's one of the reasons I like this talk so much. It really cemented these type of issue with real attacks, instead of a loosely described bunch of PoC. I remember reading somewhere on an RFC (perhaps CSP) that reporting can cause unwanted information leakage, but I didn't find it in the security considerations with a quick control+f just now.

[0] - https://lists.w3.org/Archives/Public/public-webappsec/2015Ju...

[1] - http://homakov.blogspot.com/2014/01/using-content-security-p...

In addition to Egor's stuff, I'd recommend just reading the "Privacy and Security Considerations" sections of various RFC's and W3C specs. Lots of theoretical attacks in there that people simply haven't built demos for!

In case anyone's interested, slides are up at https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf and talk recording at https://www.youtube.com/watch?v=kk2GkZv6Wjs

like you said, the security considerations are mostly theoretical. It actually might seem basic turning it into a real attack but it requires a fair bit of work.

It is always my favorite section of the RFCs. Along with anywhere that says "The UA [MUST|MAY|...] \w+". Much fun to be had....

Ah, I feel silly now. I remember reading Egor's blog post on that last year.

Thanks.

> Mitigation, get your site added to the HSTS Preload list.

If that could scale, we wouldn't need DNS?

Come to think of it, as ip addresses aren't distributed, why not have HSTS be a flag in DNS, rather than a header? (Yeah, I know, because DNS isn't secure - but that's the real problem, right there...).

Or, if the site you're visiting is DNSSEC enabled, you could just look for a TLSA record. If the TLSA record is present, don't allow unencrypted connectivity.

That's probably how you could replace HSTS with DNS.

Even without DNSsec, HSTS could pretty much work as advertised.

So what does it mean if now UA vendors have 1 million hosts added to HSTS pre-load list? Are they all created equal? Do they share the same preload list? Is there a single form to submit to all UA vendors? What if you have internal hosts that you still want the same mitigation in place? What is UA vendors' SLA on updating preload list? Preload suffers the same problem as pinning, correct me if I am wrong.

Preload does not suffer the same issue as pinning using a header. All sites on the list would just look like you probably visited them, which means ambiguity.

Not all UAs share the same preload list, but they all borrow from the chrome preload list. Read here https://hstspreload.appspot.com/.

Its not a great ecosystem and I dont forsee it as one that is improving, with encryption being a big issue in some countries