Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Timing attack against HSTS to sniff browser history in Chrome and Firefox

zyan.scripts.mit.edu

Post reply on HN
Print view View original

21–30 of 99 posts

Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox

#21

Post by toomuchtodo »

ejcx wrote: post #13

Mitigation, get your site added to the HSTS Preload list. Most of the advanced webappsec security features leak information. CSP, HPKP, HSTS, etc, which was all 100% known. This talk is excellent because it puts together the attacks into real PoCs, real attacks, and great information on how it all works. These attacks in the talk are quality too, instead of being 'mostly' theoretical. This wasn't really documented al…

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

Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox

#23

Post by yeukhon »

ejcx wrote: post #13

Mitigation, get your site added to the HSTS Preload list. Most of the advanced webappsec security features leak information. CSP, HPKP, HSTS, etc, which was all 100% known. This talk is excellent because it puts together the attacks into real PoCs, real attacks, and great information on how it all works. These attacks in the talk are quality too, instead of being 'mostly' theoretical. This wasn't really documented al…

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.

Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox

#24

Post by kentonv »

spacehome wrote: post #22

I'm using HTTPS Everyhwere, and it couldn't get a single website correct.

Yes, HTTPS Everywhere blocks this particular attack, hence why the top bar says to disable it.

(Incidentally, the author of this attack is also one of the authors of HTTPS Everywhere.)

Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox

#25

Post by meowface »

ejcx wrote: post #13

Mitigation, get your site added to the HSTS Preload list. Most of the advanced webappsec security features leak information. CSP, HPKP, HSTS, etc, which was all 100% known. This talk is excellent because it puts together the attacks into real PoCs, real attacks, and great information on how it all works. These attacks in the talk are quality too, instead of being 'mostly' theoretical. This wasn't really documented al…

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.

Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox

#26

Post by meowface »

bretthopper wrote: post #17
hamhamed wrote: post #14

A different version of this would of been to mess around with the :visited css selector since it's assuming a list of domains that you probably visit

This has mostly been fixed. See http://dbaron.org/mozilla/visited-privacy and https://blog.mozilla.org/security/2010/03/31/plugging-the-cs...

Yes. If you're using a browser version that's been updated past 2010-2011, this will no longer work.

Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox

#27

Post by ejcx »

meowface wrote: post #25
ejcx wrote: post #13

Mitigation, get your site added to the HSTS Preload list. Most of the advanced webappsec security features leak information. CSP, HPKP, HSTS, etc, which was all 100% known. This talk is excellent because it puts together the attacks into real PoCs, real attacks, and great information on how it all works. These attacks in the talk are quality too, instead of being 'mostly' theoretical. This wasn't really documented al…

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.

Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox

#28

Post by kentonv »

hobs wrote: post #2

Probably a good idea to edit the title to indicate that this is an example attack site as well, not my favorite thing in general to land on without warning. No js seems to mean no worries though.

The results never leave your browser, though, so there's not much to worry about.

Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox

#29

Post by ejcx »

toomuchtodo wrote: post #21
ejcx wrote: post #13

Mitigation, get your site added to the HSTS Preload list. Most of the advanced webappsec security features leak information. CSP, HPKP, HSTS, etc, which was all 100% known. This talk is excellent because it puts together the attacks into real PoCs, real attacks, and great information on how it all works. These attacks in the talk are quality too, instead of being 'mostly' theoretical. This wasn't really documented al…

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.

Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox

#30

Post by peteretep »

Having disabled NoScript, Privacy Badger, HTTPS Everywhere, and AdBlock Pro, it can tell I've been to npmjs.com. I'm not immediately worried.

Maybe too obvious to point out, but as far as I can tell, it looks for entries in the browser cache, rather than looking at the history per-se. If you have the browser cache empty when you close the browser (gotta watch those evercookies!), that's also not an issue.

Post reply on HN