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.

  • @brombek
    link
    34 years ago

    Also as noted in this paper the STEK keys are defeating perfect forward secrecy and are often not rotated for like 3 days. Related article https://blog.filippo.io/we-need-to-talk-about-session-tickets/. So disabling this on client side also enables true PFS. You could also imagine NSA level actor to simply provide set of STEK keys to be used and now they can passively decrypt all the traffic (assuming resumption was attempted) despite using Diffie–Hellman.

    • @jsgohacOP
      link
      24 years ago

      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.

        • @jsgohacOP
          link
          34 years ago

          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