HSTS History Sniffing

The security feature HSTS may be weaponized against the user for example for sniffing his browsing history. This hack is not new (it appeared more than 3 years ago). Recall that the purpose of HSTS is to force the browser, once it has visited an HTTPS (and HSTS capable) web site, to always use HTTPS for this site in the future, so mitigating the risk of downgrading attack, and accelerating a little the connection to the site in the process:

Quote:

---

The attack works by embedding non-existent images from HSTS-protected sites. The unscrupulous website then uses JavaScript to measure how long it takes for an error to register. If the user has visited the HSTS site before, the error will occur within a few milliseconds. If it takes longer for the error to register, the attacker can determine that the site has never been visited before.

---

A proof of concept of that kind of attack has been developed by Yan Zhu (a really pretty girl)
https://zyan.scripts.mit.edu/sniffly/

On my tests, many false positive appeared, but many of the sites having an entry in the SiteSecurityServiceState.txt file (where FF put the HSTS pined sites) have been detected (and when I empty this file, they are no more appearing in the Yan's test).

Fortunately, SBI seems not to be HSTS compliant, so that it's url is not pinned in SiteSecurityServiceState.txt.

Nevertheless, during the test, my (laptop) browser started to use 100% of the CPU, so apparently it's not easy to use this method to sniff people in a smooth way.

This is less "dangerous" that previous history exploits, since it only reveals domain names, and the information obtained is essentially meaningless for preloaded hosts (they'll always show up as visited, even if they're not). Still, it's interesting to see a feature aimed at keeping you secure be abused to make you slightly less so.

An interesting quirk is observed in the test when all mixed content is disabled (--enable-potentially-annoying-security-features in Chrome, security.mixed_content.block_display_content=true in Firefox). Using the HTTPS link to the test always results in false positives for all checked domains, while using HTTP instead works fine. Of course, this is expected behavior, since the procedure involves attempting to load nonsecure content. Also, CPU usage didn't go above 25% for me in either browser.

Also², Google saw the potential for this sort of exploit early on, and as a small countermeasure they decided to let HSTS pins from regular Chrome windows affect incognito ones, but not the other way around.