Researchers showed it is possible as of Oct 2018 to track users via TLS Session Resumption. Zdnet covers it with an article ( https://www.zdnet.com/article/advertisers-can-track-users-across-the-internet-via-tls-session-resumption/ ) though the linked paper is fairly readable. Among interesting observations, they note:
Google and Facebook, two of the world’s largest advertising firms, used abnormally large TLS Session Resumption lifespans of 28 hours and 48 hours, respectively
Countermeasures:
The recommended upper limit of the session resumption lifetime in TLS 1.3 of seven days should be reduced to hinder tracking based on this mechanism. We propose an upper lifetime limit of ten minutes based on our empirical observations.
We note, that more than 80% of the Alexa Top Million Sites restrict the session resumption lifetime to less or equal to ten minutes by their own choice and 27, 7% of all revisits of a site occur during this period. Furthermore, the average visit duration of popular websites is of the order of ten minutes, thus this lifetime limit hinders the correlation of multiple page visits by the same user. Browser vendors should address the issue of third-party tracking via TLS session resumption, either by deactivating session resumption for third-parties or by allowing only session resumptions to third-parties if the first party site is identical.
There was an issue that mentioned this in ghacks-userjs issues list (https://github.com/ghacksuserjs/ghacks-user.js/issues/643)
Picture this: You do a google search and get a SSL Session ID, then you change VPNs, and return to google and search for something else. The SSL Session ID absolutely tracks you 100%, whereas disabling it, only makes you part of a very very small group (if used for tracking: and it is server side).
Also consider that Firefox keeps this for up to 24 hours, which is outrageous IMO. Other browsers are much quickly at releasing them
Furthermore, for firefox it is suggested here (https://www.ssl.com/article/tracking-users-with-tls/) that this behavior can be avoided by setting the following preference to true:
“security.ssl.disable_session_identifiers”
EDIT: As mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=967977, this preference is not included by default and must be set manually. Some pre-configured user.js for firefox include it.
Thanks for sharing that, I was looking at ssl handshakes as a possible supercookie for advertisers, but this is next level stuff. Will dig in.
In this case you may want to look at TLS v1.3 “opaque” tickets allowing server to store 64k bytes (+ 64k for extensions) of any data they want in the ticket: https://tools.ietf.org/html/rfc8446#section-4.6.1
Interesting stuff and quite a rabbit hole. One article claiming early_data could survive browser restarts seemed to light a fire. I started building a tls 1.3 node server to see what type of values could be set, but will have to revisit when more time avails. This list of extensions is interesting: https://tools.ietf.org/html/rfc8446#section-4.2