Apple to stop ad firms hacking HTTPS protections to track iPhone users

Apple has developed mitigations to stop online ad companies from using the security standard HTTP Strict Transport Security (HSTS) to gather web history data about Safari users. 

The Internet Engineering Task Force (IETF) standard allows sites to set a policy that ensures returning visitors using browsers only connect to the site over HTTPS, the secure and encrypted version of HTTP. 

The problem with HSTS is that details collected by browsers to ensure a visitor only uses HTTPS on subsequent visits can be abused to discover what sites a visitor has previously connected to. 

Apple’s WebKit developers have now revealed two mitigations to prevent HSTS abuse after discovering that theoretical attacks described in 2015 using HSTS were recently deployed in the real world against Safari users.

The iPhone maker doesn’t say who was using HSTS to target Safari users but mentions a problem in the HSTS standard that allows someone interested in tracking web users to create a so-called “super cookie that can be read by cross-site tracking servers to mark users across sites". 

That goes against the goals of Intelligent Tracking Prevention (ITP), the Safari privacy feature Apple introduced in iOS 11 and macOS High Sierra last September to hinder cross-site tracking. 

Given Apple now has 1.3 billion active users, many online ad firms were concerned about its impact. Online ad firm Criteo, which suffered multi-million dollar losses due to iOS 11, in November publicly stated it adopted HSTS to create super cookies specifically to bypass Apple’s ITP protocols, though the company admitted Apple could close the bypass.  

Apple has now done that with mitigations it claims make it uneconomical to essentially hack HSTS for cross-site tracking. 

Brent Fulgham, a developer who works on Safari’s WebKit engine, says that Apple uses HSTS on iCloud.com to ensure returning visitors will always automatically go to the HTTPS iCloud address.  

Fulgham explains how it can be abused: “The HSTS standard describes that web browsers should remember when redirected to a secure location, and to automatically make that conversion on behalf of the user if they attempt an insecure connection in the future. This creates information that can be stored on the user’s device and referenced later. And this can be used to create a “super cookie” that can be read by cross-site trackers.”

In order to support HSTS, a web server gives each visitor a unique number — a tracking identifier — that is represented in binary as 1s and 0s. A tracker script then makes requests to a tracker-controlled server over HTTPS at a rate of “one request per active bit in the tracking identifier”. 

On return visits, the tracking script also loads invisible pixels over HTTP that represent the bits in the series of 1s and 0s. 

“Since some of those bits (bit02.example.com, bit13.example.com, and bit23.example.com in our example) were loaded with HSTS, they will automatically be redirected to HTTPS,” explains Fulgham. 

“The tracking server transmits one image when they are requested over HTTP, and a different image when requested over HTTPS. The tracking script recognizes the different images, turns those into zero (HTTP) and one (HTTPS) bits in the number, and voila — your unique binary value is recreated and you are tracked!”

Apple will roll out to two mitigations in Safari’s WebKit engine for attacks it has observed to address the first stage, where tracking identifiers are created, and the subsequent use of invisible pixels to track users. 

The first mitigation addresses the use of long URLs that encode the digits in subdomains of the main domain name and the practice of setting HSTS across many sub-domains at once. Now Safari will limit the HSTS state to the loaded hostname and the top level domain.

The measure introduces a cost to actors that set HSTS for many long sub-domains at once. 

“This prevents trackers from efficiently setting HSTS across large numbers of different bits; instead, they must individually visit each domain representing an active bit in the tracking identifier,” writes Fulgham.

“While content providers and advertisers may judge that the latency introduced by a single redirect through one origin to set many bits is imperceptible to a user, requiring redirects to 32 or more domains to set the bits of the identifier would be perceptible to the user and thus unacceptable to them and content providers. WebKit also caps the number of redirects that can be chained together, which places an upper bound on the number of bits that can be set, even if the latency was judged to be acceptable.”

The second stage mitigation involves Safari ignoring HSTS requests for domains it already blocks, such as invisible tracking pixels. This relates to a the first major update to ITP, announced last week, and following the new Storage Access API