TLS is the fundamental protocol facilitating secure web browsing. Simply speaking it identifies the server identity and establishes an encrypted connection. That’s how we may securely use banking, do shopping, and do other things we take for granted. Establishing such a connection comes with a performance footprint because computation and sending cryptographic material use CPU cycles and network bandwidth. Improving performance is always welcome. TLS session tickets enhance these interactions by allowing users to reconnect to servers more swiftly, skipping parts of the standard security checks (the TLS handshake). These tickets contain information from a previous session, which can be used to resume sessions. While designed to improve efficiency, the session ticket mechanism may be used to track users, potentially triggering regulatory issues due to data protection law. It’s a form of an identifier like a cookie. Some wonder how TLS session tickets stand with respect to EU or US data protection laws.
I solve this puzzle once and for all. TLS session tickets are compatible with data protection law. In the end of this post, I include a remark why LLMs are not a good way to reason about such innovative and corner-case things.
Tickets, how do they work
Before you browse a website, a TLS handshake process happens (in the majority of cases in 2024, website connections or application data exchange are encrypted on a standard basis). The client web browser and the server negotiate data such as types of ciphers, and encryption keys. The server may set a session ticket to identify such data bundles.
ServerHello {
Version: TLS 1.2 (0x0303)
…
}
NewSessionTicket {
Ticket Lifetime Hint: 86400
Ticket: 0x9fabdc002456abcdef0123456789abcdef0123456789abcdef0123456789abcdef
}
Later on, when you reconnect to this website there may be no need to renegotiate (regenerate) such data like encryption keys, or verify identity certificates. This improves performance, limiting CO2 emissions that are related to global warming, and your smartphone battery consumption is also reduced. All the client needs to do is offer the session ticket to say “Hey, let’s reuse the data we already established!”. Here, the ticket lifetime is often valid for 24 hours.
ClientNewHello {
Version: TLS 1.2 (0x0303)
…
Extensions: {
server_name: www.example.com,
session_ticket: 0x9fabdc002456abcdef0123456789abcdef0123456789abcdef0123456789abcdef
}
}
If things go in undesirable ways, session tickets may sometimes weaken the security guarantees of TLS, especially if they are not well deployed. Things going bad may mean that the exchanged data might be vulnerable to decryption. But in this post, we are optimistic and assume that security level is appropriate, which it almost always is.
The ability to reuse previously established encryption setup means that the server can identify such a connection, unambiguously linking it to a user who perhaps previously has been logged in to a website. This may allow a rogue server to link activities with a particular user. The session ticket is included by the server, meaning that it links the user and the server, facilitating the identifiability of the user. This also means that the particular session ticket cannot be used to identify the user across various websites/servers — it only works for a particular connection. This fundamentally limits the tracking potential of first-party interactions. That is, those on the particular website.
Of course, I could devise a scheme to extend the tracking potential. Let’s imagine a third-party tracker having a specially crafted domain name that is included in various websites visited by the user. Connections to such a tracker are also protected with a TLS—just the session ticket links the user's web browser and the tracker server (not the visiting website). Using a special naming scheme could allow some forms of cross-site tracking. But let’s leave this aside and focus on the big picture, the single-server scheme. In other words, there’s no third-party tracking possible (just because it may be done in theory, does not mean that it would, or that it would bring any consequences at all for the use of TLS session tickets; it wouldn’t).
The technical standard document does not consider privacy systematically outside of a recommendation to include a new session ticket to each web browser connection (“Servers SHOULD issue new tickets with every connection”). But I assure you: it is a persistent identifier and as such it needs to be treated as personal data. It does fall in data protection law scope. Session tickets are unique identifiers enabling the linkage of user actions (here enters GDPR), and the setting of the ticket modifies the user’s system (here enters the EU ePrivacy Directive, the so-called cookie law).
Data protection extremists, or skeptics, could now demand (and skeptics — complain about) asking for consent each time the user initiates a network connection to a website. After all, a session ticket is being set. However, interpreting data protection law in such a literal way would have some undesirable consequences, namely, it would make the use of the internet totally unbearable. Fortunately, there’s no need for that.
Data protection view
First, let me start that the use of TLS is a GDPR requirement. All network connections that may contain personal data must always be encrypted. Does this also mean that TLS session tickets are automatically a fair game?
The GDPR states that: “Natural persons may be associated with online identifiers provided by their devices, applications, tools, and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them”. TLS Session Tickets checks this box.
Furthermore, GDPR defines personal data as “any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier”. TLS Tickets meet this threshold. Session tickets are unique identifiers assigned to individuals, effectively making them personal data just like identifiers such as cookies. This is undeniable.
The consequence is that GDPR data protection principles enter the game, including fairness, or lawfulness of processing (hypothetically — like consent requirement). However, I argue that the use of session tickets does not need user consent because (when) it is merely used to establish and maintain a network connection state. Unless of course it would indeed be used to do anything beyond, like tracking the user activity—further processing—in this case, user consent is needed (unless different grounds for processing were valid). Of additional note is this GDPR lawfulness provision: “Processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject”. In this case, improving server computing performance could be treated as a legitimate interest if such identifiers are not processed for any other purpose. It does not impair fundamental rights and freedoms in any way, the potential risk is negligible. But GDPR is not the main issue here.
The ePrivacy Directive is the tricky part. It considers that user consent is necessary whenever a user device is accessed, for example, to store or access data. Access or storage of any information—potentially information like session cookies, session tickets, but also TLS encryption keys. That would be an overkill when it comes to consent popups. But there’s none. There’s no massive data breach here. How come?
Article 5 of ePrivacy prohibits storage or access to “the terminal equipment of a subscriber or user” unless the user is informed and has a way to refuse this. In practice, this may mean that information pop-up or consent is a requirement when identifiers are placed in user web browsers or systems. However, the critical point here is that this is not necessary when “technical storage or access” is made “for the sole purpose of carrying out or facilitating the transmission of a communication over an electronic communications network, or as strictly necessary in order to provide an information society service explicitly requested by the subscriber or user”. Since the user is entering the website then it is explicitly requested by the user. But is the use of session tickets “strictly necessary”?
In other words, are session tickets essential? Session tickets contain data required to establish an encrypted connection, data like state and key. Those data are essential to establish a subsequent TLS connection. While in principle the web browser could disregard the data and reestablish a completely new connection each time the user reconnects to a website, this does not invalidate the fact that session ticket data may still be considered “essential” just because a connection may be made in different ways. Concluding otherwise could mean—I’m using reductio ad absurdum here—that even a full TLS connection to a department store website would not be necessary because the user may as well go there physically, in a hat, mask, fake mustache, and paying with cash, to reduce any traces, including those digital ones when using a web browser. In our case—we leave the absurd case now— we compare two types of making a network connection, one being simpler because of the uses of session tickets. While their use is not absolutely technically necessary (meaning: it can be made differently, though there would be no gains, only losses for users), I argue that performance improvement means that the “essential” criterion is met.
Recital 22 supports this: “The prohibition of storage of communications … is not intended to prohibit any automatic, intermediate and transient storage of this information in so far as this takes place for the sole purpose of carrying out the transmission in the electronic communications network and provided that the information is not stored for any period longer than is necessary for the transmission and for traffic management purposes, and that during the period of storage the confidentiality remains guaranteed. …”
I point out that:
- It is undeniable that session tickets are meant to improve performance.
- They are used for “sole purpose of carrying out the transmission”.
- They are stored temporarily.
- Confidentiality is ensured.
And I did not even refer to the “legitimate interests” magic wand: “… should be allowed only for legitimate purposes, with the knowledge of the users concerned”. Still, if you want to be extra-safe, include the information about the use of TLS session tickets in the privacy policy (I am not arguing that it is necessary; in my opinion, it is not necessary). The situation changes completely if TLS session tickets were to be used to reidentify users, link their behaviors with user profiles, used to track user behavior, etc. So further processing. That is not allowed. Don’t do this and all is well.
Session management, but different than cookies
The legal term “strictly necessary” is typically directed toward the use of cookies to manage user sessions while browsing a website. For example, to facilitate the functionality of user accounts on a website — being logged in and logged out. Another example is the well-known shopping cart case — a user browsing an e-commerce site, adding stuff to a shopping cart—and thanks to cookies the shopping cart remains linked to the same user. While theoretically, in principle, the same functionality may be implemented without the use of cookies or similar (even if in a more cumbersome way) it is universally accepted that this checks the “strictly necessary” box. It improves performance at a minimum, and it definitely improves user convenience and experience.
Reasoning in the same way it is even more obvious that TLS session tickets may be treated as “strictly necessary” — while technically not absolutely needed, they significantly improve network connection management, experience, speed, and limit computational overhead. Which is why they may be treated as “strictly necessary”. While the Court of Justice of the European Union (CJEU) did not have an opportunity to issue any guidance in these respects, it is sensible to assume that if it came to that, they could make a copy-paste of the reasoning I just laid out here. While I don’t wear the CJEU judge robe, I'm pretty sure about this.
Summary
This addresses any questions or concerns about whether TLS session tickets may or may not be triggering EU data protection prohibitions. If not, it would be an overkill. It would also be a clear signal that something is very wrong with EU data protection law. Fortunately, this is not the case, and on the contrary, EU data protection law fully allows such uses. And that’s it.
Bonus point: ChatGPT
Can a large language model (AI) reason about such innovative, if ambiguous, things? Nope.
What does ChatGPT have to say about this
After I wrote the above analysis, for my entertainment I had a conversation with GPT-4o to “discuss” the matter. I asked questions, and then presented an argument in the above manner, but without saying openly that TLS Session Tickets are or are not meeting the “strictly necessary”. There was a curious conversation when ChatGPT tried to copy-paste and extend what is known. In the end, ChatGPT finally gave up with the below (I skip the full conversation):
“You're absolutely right to point out that TLS session tickets, while technically part of the security protocol between the user's device and the server, involve storing data on the user's device that can be used to resume sessions. This stored data can act as an identifier, which brings it under the scope of regulations that concern personal data. …
Based on the function and use of TLS session tickets, it is likely that websites and online services need to obtain consent before using these tickets, especially when they are used primarily for performance improvements rather than for essential services.
…
the use of TLS session tickets indeed engages significant privacy considerations. Their deployment and management must adhere to the principles of lawful, fair, and transparent processing as required by GDPR, with a likely need for consent under the ePrivacy Directive, unless a clear justification for their necessity can be provided. This scenario underlines the importance of aligning technological implementations with robust privacy practices and regulations”
[I skipped the GPT-provided space-filler about GDPR requirements, data protection principles, etc]
In light of my assessment, I conclude that ChatGPT is wrong. Naturally, it only had access to existing knowledge. This one does not exist per se for TLS Session Tickets (it seems that my blog post is the first one covering the substance at length).
This highlights the ultimate limitations of large language models in matters of technology policy and aspects of legal interpretation. Chances are that once OpenAI makes a new crawl for GPT to memoize this blog note, ChatGPT will become more educated. Oh, that’s also kind of related to a complaint.
Ps. When I pointed out to ChatGPT what would be the implications—the inability to use the internet in the European Union, it tried to slightly tone down its answer, but still resulted in a wrong conclusion of “this being a grey area”. Again: it’s not a grey area—although admittedly the European Data Protection Board chose not to clarify those points (if they did intend to do so in the future, they would likely be familiar with this blog note; still, I bet that they would still prefer not to refer to it in their opinion, for reasons only they know :-) ).