New Browser security features have tracking side-effects
Most modern browsers are not simple tools anymore to display HTML websites properly in the browser. They are complex programs that support a wide variety of technologies including several designed to improve the security and privacy of users.
While that is a good thing usually, it may lead to issues as well if these new technologies can be abused.
A recent blog post by Ars Technica's Dan Goodin indicates that this is the case for two new technologies that some web browsers support.
HTTP Strict Transport (HSTS) and HTTP Public Key Pinning (HPKP) are designed to improve the security of connections made to websites supporting these measures.
HTTP Strict Transport does so by instructing browsers to only establish connections if HTTPS connections can be established. If that is not the case, the connection is refused.
It is similar on first glance to what the popular browser extension HTTPS Everywhere offers which can be used to enforce HTTPS connections as well. The difference however is that it is the web server in the case of HSTS which is enforcing the rule.
The side-effect of HSTS is that it can be used to track users on the Internet. We have talked about this already in our guide to prevent HSTS tracking in the Firefox web browser.
The Firefox tracking method abused the fact that Mozilla stores information about HSTS supporting sites in a plain text document. The new tracking method however users another system that makes it compatible with all browsers supporting it.
The basic idea behind the method is to embed non-existing images from known HSTS sites on a target web page and to measure the time it takes to register an error (since the image does not exist). A quickly resolving error indicates that the site has been visited in the past.
You can check the method out for yourself by visiting this demo site. It checks the HSTS cache against a number of popular websites only.
If you want to know more about this, check out the Advanced Browser Fingerprinting talk by Yan Zhu. She discovered the vulnerability and programmed the proof of concept attack site. It is an excellent talk that anyone can follow who has a basic understanding of computers and the Internet.
The HTTP Public Key Pinning attack works in a different way and only in Chrome currently. While it is limited to Chrome, other browsers will implement certificate-pinning reporting, which is required for the attack.
Basically, it allows websites to specify HTTPS credentials that a browser should accept in the future when connections are made to the site.
The method can be abused by pinning unique text to each visitor which can then be read on subsequent visits.
Defenses against these new privacy-invading attack forms
One option that you have to defend yourself is to clear site data completely in your browser of choice. The main issue that many users may have with it is that it will remove user-set preferences and data that the user requires as well.
Chrome users may also load chrome://net-internals/#hsts to check individual domains this way, but it is far from comfortable. Unfortunately, there is no option in Chrome currently to list all HSTS sites to delete select ones more comfortable.
Firefox users on the other hand can follow the guide linked in the opening paragraphs of this article for ways to delete entries from the HSTS file.
“The basic idea behind the method is to embed non-existing images from known HSTS sites on a target web page and to measure the time it takes to register an error (since the image does not exist). A quickly resolving error indicates that the site has been visited in the past.”
This needs to be clarified. No contact is initiated with any of the HTTPS sites.
“[The web server] Sniffly sets a CSP policy that restricts images to HTTP, so image sources are blocked before they are redirected to HTTPS”
Concerning HPKP as I’ve understood it Mozilla pointed out that it is not (yet) available on Firefox (when it is with Chrome).
As far as HSTS is concerned I’ve made the choice to avoid it here with Firefox by setting my SiteSecurityServiceState.txt file to 0 bytes and Read-Only. And I haven’t ‘HTTPS Everywhere’ running. I remember having read that this HSTS posed a cruel dilemma between security and privacy. Not so cruel IMO if I compare what is lost in security (by “disabling” HSTS as above mentioned) with what is gained in privacy. An ‘HSTS-ready’ site is very, very unlikely to be in the situation of having to refuse the http connection because https would have failed (which would occur with HSTS active). The MIM (Man In the Middle) is the only true risk I take by disabling HSTS. The risk would be reduced with ‘HTTPS Everywhere’ installed : this is at this time what I’m hesitating to do. I’m not very fond of HTTPS Everywhere, I saw it actively resolving to https non-connections when these had been blocked by uBlock Origin, which means it deploys before uBlock or independently of uBlock by setting a secure connection to external calls even when these haven’ occurred, which is a loss. I don’t know, not really convinced of the best thing to do right now …
Security != Privacy/Anonymity
This is something that people shouldn’t forget since it’s rather common to conflate the two.