Apple burns the HSTS super cookie

Want to know something cool?
Quietly and without fanfare Apple has rolled out a change to its Safari browser that munches one of the web’s most advanced “super cookies” into crumbs.
So-called “super cookies” are tracking methods that rely on esoteric things like browser fingerprints, ETags, Local Storage and Flash LSOs rather than cookies. They’re popular with people who really, really want to track you because they’re much harder for you to block, purge or manage than plain old regular cookies.
A few years ago I wrote about a theoretical super cookie that could defeat Incognito mode by abusing HSTS, a technology that’s designed to make your browsing more secure.
Abusing HSTS would allow these imagined super cookies to hide in plain sight because removing them results in reduced security. In the face of HSTS cookies in the wild, users and browser vendors would be forced to trade privacy and security off against each other.
At the time we weren’t aware of anyone actually using them.
Well, that’s changed now, and Apple has responded.

How HSTS can be used for tracking

HSTS is a simple instruction that websites can send to browsers that says, in effect, “remember not to talk to me in an insecure way”.
After receiving an HSTS instruction from a website, a browser will use HTTPS – the encrypted form of HTTP – to talk to that site, even if a user clicks on or types a link that uses the insecure HTTP.
Just like a cookie, an HSTS instruction is a piece of information that a website can ask a browser to remember.
However, to track a browser you need to be able to assign it a unique ID, and a single HSTS instruction just doesn’t hold enough information to do that.
While a cookie can contain thousands of bits of information, a single HSTS instruction holds just a single bit (because it’s either on or off).
However, if somebody can get your browser to make HTTP requests to a handful of websites under their control (which could be done easily by embedding a number of tiny images in web page, for example) they can set enough HSTS on/off switches in your browser to store an ID.
An array of 30 images would be enough to track just over 1 billion different IDs.

It works like this…

A visitor goes to a web page with a nefarious HSTS tracking code provided by Evil Marketing Corp Inc.
The code asks for 30 different images from 30 different websites under the control of Evil Marketing Corp. The images are all fetched using HTTP – some respond with an HSTS instruction, and some don’t.
The specific pattern of 30 on/off responses is that visitor’s unique ID.
The next time that same visitor goes to a page with the tracking code on it, their browser will ask for the same images from the same websites as before. This time though, the browser will remember its HSTS instructions and ask for some of the images over HTTPS instead of HTTP.
The pattern of HTTPS/HTTP requests received by Evil Marketing Corp across its 30 websites matches the pattern of on/off responses it sent earlier – the visitor’s unique ID.
For a fully illustrated, step-by-step example of HSTS tracking, take a look at my article about how HSTS ‘supercookies’ make you choose between privacy or security.

How Apple ate the cookie

WebKit is the open source browser engine that powers Apple’s Safari browser. Writing on the WebKit blog, Brent Fulgham volunteered a hint that HSTS tracking had recently moved from theory to practice.

Recently we became aware that this theoretical attack was beginning to be deployed against Safari users. We therefore developed a balanced solution that protects secure web traffic while mitigating tracking.

Finding itself on the horns of the privacy vs security dilemma, Apple looked for a way to step on the neck of the trackers without compromising the benefits of HSTS.
Taking a good look at how HSTS was being abused in the wild, it came up with two tactics.
Firstly, to prevent tracking codes from using an array of websites to set HSTS instructions, Safari now blocks HSTS instructions from everything other than the site you’re on, or its root domain (or the Top Level Domain + 1, as it’s described on the WebKit blog).
So, if you visit tracking.website.example.org then you can only get HSTS instructions from tracking.website.example.org (the hostname you’re on) and example.org (the root domain).
This reflects the fact that the HSTS tracking it spotted was using arrays of related subdomains, like this:

http://a.tracking.website.example.org
http://b.tracking.website.example.org
http://c.tracking.website.example.org
http://d.tracking.website.example.org

Or like this:

http://a.tracking.website.example.org
http://b.a.tracking.website.example.org
http://c.b.a.tracking.website.example.org
http://d.c.b.a.tracking.website.example.org

Safari’s second countermeasure is to ignore HSTS instructions from websites that its Intelligent Tracking Protection blocks cookies from.
Having deployed and monitored the changes, Fulgham writes that Apple may have successfully sidestepped the privacy vs security problem that we feared:

Telemetry gathered during internal regression testing, our public seeds, and the final public software release indicates that the two mitigations described above successfully prevented the creation and reading of HSTS super cookies while not regressing the security goals of first party content.

Let’s hope it’s enough to blunt the progress of HSTS tracking in the wild and return it to a theoretical curiosity.