
Tracking Users Across the Web via TLS Session Resumption - tombrossman
https://arxiv.org/abs/1810.07304
======
btown
> 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...](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables)

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](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.

~~~
kodablah
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.

~~~
Klathmon
> 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.

~~~
jerf
"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.

~~~
Klathmon
That's a really good point, thanks!

------
newscracker
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.

~~~
alex_duf
Now this identified I'm sure Mozilla will fix the issue quickly

------
jedisct1
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](https://github.com/Jigsaw-
Code/Intra/issues/101) )

------
settingsquest
Is there a setting to change this in firefox?

~~~
fiveop
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](https://bugzilla.mozilla.org/show_bug.cgi?id=967977)

~~~
c487bd62
And many settings are documented in this project
[https://github.com/pyllyukko/user.js](https://github.com/pyllyukko/user.js)

[https://github.com/pyllyukko/user.js/blob/master/user.js#L10...](https://github.com/pyllyukko/user.js/blob/master/user.js#L1004)

------
getcrunk
Lol I’d rather someone cut my tounge than have to praise Microsoft but dang,
edge protects against this and chrome and Firefox sleepin

------
dang
Url changed from
[http://front.math.ucdavis.edu/1810.07304](http://front.math.ucdavis.edu/1810.07304).

