> To the best of our knowledge, we are the first to report on the applicability of TLS session resumption for user tracking.
Whoa. I had no idea browsers were sending unique identifiers back to previously visited sites, even with cleared/disabled cookies. Nginx can pass $ssl_session_id upstream, so it's very possible that this is being used for tracking in the wild: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#varia...
But it's unclear, for instance, whether mobile browsers use separate TLS caches for private browsing.
On top of the tracking described in the OP, the very presence of session resumption introduces an interesting timing attack. Imagine a malicious site which attempts to embed assets from various sites, all of which are known to have a similar RTT (perhaps they're hosted from the same datacenter). By seeing which are fulfilled more quickly than others (by virtue of resuming TLS sessions), you could probabilistically know which sites the user has visited before. Malicious actors could use this for phishing, or to establish bona fides in extorting payments (particularly for obscure sites with questionable content). It's exactly why we don't allow Javascript to introspect whether a link is blue or purple. Not good.
FWIW, Tor browser has had it disabled for years. Caching and anonymity are almost always at odds.
For timing attacks, I think the required sample size of first connection to third party would be too large to reasonably exploit. You have to see if your first attempt does just a couple of TCP handshake messages shorter, future attempts would send the session ID from the first in client hello. There's too much between the third party and your user's browser for you to make any assumptions about just one loaded resource's TLS shortcut.
> There's too much between the third party and your user's browser for you to make any assumptions about just one loaded resource's TLS shortcut.
Are you assuming that or is there some testing you know of that can help back that up?
Because I've heard of timing attacks happening over networks with a surprising amount of precision.
Granted I'm inclined to believe you, it's my gut feeling as well, but I've been so very wrong about this in the past that I default to assuming there is no amount of latency or jitter that can hide a timing attack from a determined attacker.
"Because I've heard of timing attacks happening over networks with a surprising amount of precision."
They can, when you can issues thousands, millions, or even billions of attempts that are sufficiently statistically independent and then do statistics on the result. In this case, you want to see if the user has an open TLS session to a particular resource, but you only get one shot at the result, because after the first shot, now the user certainly has a TLS session open to the particular resource. So you have no opportunity to do many K/M/Grequests to nail down the differences and are swamped by other random events.
Across a population of browsers you might be able to extract a small fraction of a bit per user, but you're certainly not getting anywhere near the full bit (yes they have open session/no they do not) on a per-user basis. While you can extract non-zero amounts of information I don't think you could count on getting any sort of useful information from it.
Consider that an attacker could find a number of websites hosted on EC2 us-east-1, and build statistics across not only all those websites from a single browser, but also from multiple attacked users with similar average RTTs to us-east-1. Deviations from the mean across similar users would be the flags. And with a phishing campaign, you don't need to be accurate all the time.
I didn't know you could not check if a link is blue or purple with javascript. I assume you can't do it through standard means. What about this css hack? https://github.com/maxchehab/CSS-Keylogging Wouldn't using a selector like a:visited { background-image: url-to-tracking-image }? You can apply this with JS and check the href, although you can do that with CSS as well.
You can still trick users into clicking on overlays on top of visited links (e.g. with a fake captcha that says "click all the things that are purple"). But because this requires manual actions, it's less critical than something like the session resumption attack above, which could run all night and enumerate the RTT of every single banking site and niche mature-content site out there.
This is interesting and disturbing (like many other studies related to tracking/profiling). It looks like a never ending race between privacy and convenience/performance.
I’m disappointed that iOS has longer windows (120 minutes) for session resumption. Also, is the browser engine restriction on iOS the reason why all the tested browsers support the same duration? Or is it that the browser developers haven’t yet looked at this in their iOS code?
Even the desktop scene looks good, among well known browsers (to me), only for Brave and Opera, with a duration of 30 minutes. The others are subpar for me. Firefox and Safari on the desktop are both terrible, with a one day duration for session resumption. When I started reading this paper I expected these two to be the best or the second best.
This has been known forever, and it doesn't only affect websites. DNS over TLS has the same issue, and effectively gives more information to DNS providers than regular DNS.
Which is why dnscrypt-proxy can disable session resumption for DoH, or can use a new key for each transaction when using the dnscrypt protocol.
I don't think Firefox ever touches your user.js, I've never seen that happen or anyone complaining about it. And then it overrides prefs.js generated settings. The only time I encountered problems was with a big update failing to replace a couple of prefs.js entries, and it was some really obscure settings.
I dont think this is correct. I added the boolean security.ssl.disable_session_identifiers set to true in Firefox 62.0.3 and ran the SSL Labs browser test here: https://www.ssllabs.com/ssltest/viewMyClient.html. With the boolean set to true, Session Tickts under the Protocol Details section says false. Toggling the setting back to false and rerunning the set showed Session Tickets Yes. So perhaps you had a typo in the seeting name?
> To the best of our knowledge, we are the first to report on the applicability of TLS session resumption for user tracking.
Whoa. I had no idea browsers were sending unique identifiers back to previously visited sites, even with cleared/disabled cookies. Nginx can pass $ssl_session_id upstream, so it's very possible that this is being used for tracking in the wild: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#varia...
Luckily, it looks like Chrome incognito mode does have a different TLS session cache, so at least things aren't leaking there. https://bugs.chromium.org/p/chromium/issues/detail?id=30877
But it's unclear, for instance, whether mobile browsers use separate TLS caches for private browsing.
On top of the tracking described in the OP, the very presence of session resumption introduces an interesting timing attack. Imagine a malicious site which attempts to embed assets from various sites, all of which are known to have a similar RTT (perhaps they're hosted from the same datacenter). By seeing which are fulfilled more quickly than others (by virtue of resuming TLS sessions), you could probabilistically know which sites the user has visited before. Malicious actors could use this for phishing, or to establish bona fides in extorting payments (particularly for obscure sites with questionable content). It's exactly why we don't allow Javascript to introspect whether a link is blue or purple. Not good.
FWIW, Tor browser has had it disabled for years. Caching and anonymity are almost always at odds.
For timing attacks, I think the required sample size of first connection to third party would be too large to reasonably exploit. You have to see if your first attempt does just a couple of TCP handshake messages shorter, future attempts would send the session ID from the first in client hello. There's too much between the third party and your user's browser for you to make any assumptions about just one loaded resource's TLS shortcut.
> There's too much between the third party and your user's browser for you to make any assumptions about just one loaded resource's TLS shortcut.
Are you assuming that or is there some testing you know of that can help back that up?
Because I've heard of timing attacks happening over networks with a surprising amount of precision.
Granted I'm inclined to believe you, it's my gut feeling as well, but I've been so very wrong about this in the past that I default to assuming there is no amount of latency or jitter that can hide a timing attack from a determined attacker.
"Because I've heard of timing attacks happening over networks with a surprising amount of precision."
They can, when you can issues thousands, millions, or even billions of attempts that are sufficiently statistically independent and then do statistics on the result. In this case, you want to see if the user has an open TLS session to a particular resource, but you only get one shot at the result, because after the first shot, now the user certainly has a TLS session open to the particular resource. So you have no opportunity to do many K/M/Grequests to nail down the differences and are swamped by other random events.
Across a population of browsers you might be able to extract a small fraction of a bit per user, but you're certainly not getting anywhere near the full bit (yes they have open session/no they do not) on a per-user basis. While you can extract non-zero amounts of information I don't think you could count on getting any sort of useful information from it.
That's a really good point, thanks!
Consider that an attacker could find a number of websites hosted on EC2 us-east-1, and build statistics across not only all those websites from a single browser, but also from multiple attacked users with similar average RTTs to us-east-1. Deviations from the mean across similar users would be the flags. And with a phishing campaign, you don't need to be accurate all the time.
I didn't know you could not check if a link is blue or purple with javascript. I assume you can't do it through standard means. What about this css hack? https://github.com/maxchehab/CSS-Keylogging Wouldn't using a selector like a:visited { background-image: url-to-tracking-image }? You can apply this with JS and check the href, although you can do that with CSS as well.
Many browsers have specifically disabled background-image, or anything with side effects, on :visited selectors - https://hacks.mozilla.org/2010/03/privacy-related-changes-co...
You can still trick users into clicking on overlays on top of visited links (e.g. with a fake captcha that says "click all the things that are purple"). But because this requires manual actions, it's less critical than something like the session resumption attack above, which could run all night and enumerate the RTT of every single banking site and niche mature-content site out there.
This is interesting and disturbing (like many other studies related to tracking/profiling). It looks like a never ending race between privacy and convenience/performance.
I’m disappointed that iOS has longer windows (120 minutes) for session resumption. Also, is the browser engine restriction on iOS the reason why all the tested browsers support the same duration? Or is it that the browser developers haven’t yet looked at this in their iOS code?
Even the desktop scene looks good, among well known browsers (to me), only for Brave and Opera, with a duration of 30 minutes. The others are subpar for me. Firefox and Safari on the desktop are both terrible, with a one day duration for session resumption. When I started reading this paper I expected these two to be the best or the second best.
Now this identified I'm sure Mozilla will fix the issue quickly
This has been known forever, and it doesn't only affect websites. DNS over TLS has the same issue, and effectively gives more information to DNS providers than regular DNS.
Which is why dnscrypt-proxy can disable session resumption for DoH, or can use a new key for each transaction when using the dnscrypt protocol.
(Intra won't allow disabling it because apparently, users are idiots https://github.com/Jigsaw-Code/Intra/issues/101 )
Is there a setting to change this in firefox?
There is a setting (security.ssl.disable_session_identifiers). You have to add it yourself, it's not in about:config by default. See https://bugzilla.mozilla.org/show_bug.cgi?id=967977
And many settings are documented in this project https://github.com/pyllyukko/user.js
https://github.com/pyllyukko/user.js/blob/master/user.js#L10...
It also seems to get deleted across browser version updates, at least on (old) Aurora. Pocket got re-enabled for me as well after 64 came out :/
I don't think Firefox ever touches your user.js, I've never seen that happen or anyone complaining about it. And then it overrides prefs.js generated settings. The only time I encountered problems was with a big update failing to replace a couple of prefs.js entries, and it was some really obscure settings.
That does not seem to work according to ssllabs browser test.
I dont think this is correct. I added the boolean security.ssl.disable_session_identifiers set to true in Firefox 62.0.3 and ran the SSL Labs browser test here: https://www.ssllabs.com/ssltest/viewMyClient.html. With the boolean set to true, Session Tickts under the Protocol Details section says false. Toggling the setting back to false and rerunning the set showed Session Tickets Yes. So perhaps you had a typo in the seeting name?
Under Firefox 62.0 (64-bit), setting security.ssl.disable_session_identifiers=true, I also see "Session tickets" change from Yes to No. Thanks!
you are right, bad case of a Layer 8 issue.
There is a Firefox configuration hardening project: https://github.com/pyllyukko/user.js It has security.ssl.disable_session_identifiers enabled
I was unable to find one. Right now the only way seems to be to patch nss.
Lol I’d rather someone cut my tounge than have to praise Microsoft but dang, edge protects against this and chrome and Firefox sleepin
Url changed from http://front.math.ucdavis.edu/1810.07304.