You like HTTPS. We like HTTPS. Except when a quirk of TLS can smash someone’s web privacy
Analysis Transport Layer Security underpins much of the modern internet. It is the foundation of secure connections to HTTPS websites, for one thing. However, it can harbor a sting in its tail for those concerned about staying anonymous online.
Privacy advocates have long warned about the risks posed by various forms of web tracking. These include cookies, web beacons, and too many forms of fingerprinting to name.
Awareness of the issue has helped a bit. Apple recently rolled out improved tracking protection in Safari for macOS Mojave and iOS 12. Firefox earlier this year debuted an anti-tracking add-on called Facebook Container, among other improvements. And browsers like Brave and Tor Browser continue to offer more extensive privacy capabilities.
The privacy risks associated with web tracking, however, persist, and now it appears there’s yet another mechanism for following people online. Blame researchers from the University of Hamburg in Germany for the latest expansion of the privacy attack surface.
In a paper distributed through ArXiv this week, computer science boffins Erik Sy, Hannes Federrath, Christian Burkert, and Mathias Fischer describe a novel tracking technique involving Transport Layer Security (TLS) session resumption.
Tricky negotiations
TLS (SSL in an earlier incarnation) should be widely familiar as the cryptographic protocol used to keep web communication protected as it travels between client and server. The latest version is 1.3.
Establishing a TLS connection, say, when visiting a HTPPS website, involves some back-and-forth negotiation over the network. So it makes sense to have a way to resume previously a established session with less ritual: TLS session resumption.
The techniques for doing so vary between TLS 1.3 and older versions of the spec – 0-RTT/1-RTT (round-trip time) via pre-shared keys (PSK) represents the latest mechanism while the legacy approach involves sessions IDs and session tickets.
Fine distinctions aside, these techniques are a bit like getting one’s hand stamped at some event in order to leave and then return without paying the cost of entry a second time. Well, not really. But let’s just leave it at that to avoid a discussion of TLS handshake arcana.
The point is that session resumption relies on the identifier passed to the client device during the initial handshake. And because this identifier – session ID, session ticket or PSK identity – persists in the browser’s TLS cache, it can be tracked like any other digital identifier.
This is less of an issue for browsers running on desktop computers, provided the user restarts the browser every so often. But the researchers observe that mobile devices may go days or even weeks (given recharge time) without a browser restart.
Session resumption identifiers have varying expiration times. Servers can provide a non-binding ticket_lifetime_hint field specifying the identifier’s lifetime in seconds as a 32-bit unsigned integer. That could allow a lifetime of about 68 years. However, TLS 1.2 and TLS 1.3 call for more restricted ticket lifetimes, 24 hours and 7 days respectively.
It could be worse but still isn’t good
Sy, Federrath, Burkert, and Fischer found that 80 per cent of the TLS session ticket-enabled websites among the Alexa Top Million set lifetime hints of ten minutes or less. About 10 per cent of the remainder set lifetime hints of at least 24 hours.
They note that Facebook and Google, due to their behavioral ad businesses, specify longer session resumption ticket lifetimes than most. Facebook’s lifetime hint setting of 48 hours is higher than 99.99 per cent of all session ticket hints found. Google’s 28 hour value exceeds 97.13 per cent of Alexa’s top million websites.
But the expiration of a session resumption ticket doesn’t necessarily remove the ability to track a user if a correlated identifier can be placed before then.
When a client attempts to resume a session, it transmits its TLS session resumption identifier to the server regardless of whether the session is resumed or rejected, the researchers observe. This revealed data can then be associated with a newly established session by the same user.
The researchers observe that a website can issue a new session identifier on every visit and “thus track a user indefinitely as long as the time between two visits does not exceed the session resumption lifetime of the user’s browser.”
Kinda lingers
The default configurations of most web browsers, however, mitigate the risk. Among the 45 browsers surveyed, two-thirds only allowed session resumption lifetimes of up to 60 minutes for the session ID and session ticket mechanisms.
Even so, tracking a user for more than a week appears to be possible with most browsers.
“Our results indicate that with the standard setting of the session resumption lifetime in many current browsers, the average user can be tracked for up to eight days,” the paper says. “With a session resumption lifetime of seven days, as the recommended upper limit in the draft for TLS version 1.3, 65 per cent of all users in our dataset can be tracked permanently.”
The researchers singled out the three privacy-friendly browsers – JonDoBrowser, Orbot, and Tor Browser – for their lack of session resumption support. Four other browsers – 360 Secure Browser, Konqueror, Microsoft Edge, and Sleipnir – restrict session resumption support for third parties.
To mitigate the risk of tracking via TLS session resumption identifiers, the boffins recommend that the seven-day session resumption time specified in TLS 1.3 be reduced to 10 minutes and that browser makers address third-party tracking scenarios.
“The most effective technique is to disable TLS session resumption in browsers completely,” they conclude.
Crucially, don’t give up on TLS and HTTPS. They are invaluable for staying secure on today’s internet. Browser and website developers, though: please have a rethink about session resumption. ®
Sponsored: Following Bottomline’s journey to the Hybrid Cloud
READ MORE HERE