We Really Need to Talk About Session Tickets

A Large-Scale Analysis of Cryptographic Dangers with TLS Session Tickets

We recently published the paper “We Really Need to Talk About Session Tickets: A Large-Scale Analysis of Cryptographic Dangers with TLS Session Tickets“ . In this paper, we analyze the security of TLS session ticket implementations and deployed servers. Many servers used guessable keys to encrypt session tickets, allowing attackers to decrypt TLS traffic or to impersonate the server. We’ll present this in person at RuhrSec in May and at USENIX in August. In this post, we give a brief overview of the paper and our results.

What are Session Tickets?

Absract representation of a TLS 1.2 handshake and session resumption. (Dark mode image - for description see light mode image)

(Left) A TLS 1.2TLS 1.0 and TLS 1.1 behave the same way. For simplicity, we write TLS 1.2. handshake with a DH key exchange. Here the server issues a ticket containing key material for the second handshake. (Right) A TLS 1.2 handshake using a ticket to resume the session. It does not perform another key exchange or authentication.
Explanation of icons
Icon Description
user (Tessa) using behind a laptop User who is connecting to the server
server rack Server the user is connecting to
speech bubble containing CH Client Hello. A message containing a list of supported parameters.
speech bubble containing SH Server Hello. A message containing the chosen parameters.
document with a wax seal Certificate sent by the server. The client has to verify it (including contained signatures).
left half of a key Key Exchange sent by the server. This is signed and has to be verified by the client.
right half of a key Key Exchange sent by the client.
complete key The symmetric key derived from the key exchange.
database Local storage of the client.
blue key Session Ticket Encryption Key (STEK). Used to encrypt the ticket. This should only be known to the server.
entrance ticket The ticket containing key material for resumption.

Session tickets (RFC 5077 ) improve the performance of the TLS protocol. In a normal TLS handshake, the client and server have to agree on a shared secret key.Depicted in the figure above as left half of a key and right half of a key. Further, the server has to authenticate itself to the client using a certificate. The certificate contains a signature the client has to verify. A document with a wax-seal on it Actually, the server sends a chain of certificates. Each certificate contains a signature of the parent certificate. Each signature has to be checked.
The server also includes a signature over its key exchange Right part of a key which the server has to compute, and the client has to verify. Both of these are computationally expensive. To skip these steps in future connections, the server can send a ticket to the client. The ticket contains the established secretThe actual key material is not directly included. The master secret (1.2) or resumption secret/PSK (1.3). Additionally, some information about the connection parameters is included. which is used in the next handshake. This allows the key exchange and certificate to be skipped. The client stores the ticket and established secret for the next handshake.

Upon resumption, the client sends the ticket to the server, which can retrieve the secret from the ticket and resume the connection. As the client sends the ticket in plain upon resumption, the secret is encrypted with a key only known to the server. This key is called a Session Ticket Encryption Key (STEK). This way only the server is able to read the secret from the ticket.

Issues with Session Tickets

While TLS session tickets bring significant performance improvements for TLS connections , they have become a major target of criticism raised by security experts ; if an attacker can extract the state from a ticket, they can impersonate the server or decrypt recorded TLS connections.This holds for all versions of TLS. TLS 1.3 improved this by allowing to perform an additional key exchange. This prevents the passive decryption of data transmitted after the key exchange. It is still possible to decrypt the 0RTT data (sent before key exchange) or impersonate the server.

Such dangers are not only theoretical; in 2020, Fiona Klute discovered a vulnerability affecting the security of the session resumption mechanism in GnuTLS . The server used an all-zero STEK in the initial key rotation interval, allowing an attacker to decrypt the session tickets and learn the included secret TLS state.

Even if a client does not resume the ticket, their initial connection is still endangered by the ticket issuance. In TLS 1.2 a resumed session uses the same key material as the initial connection.The actual cryptographic keys differ, however they are derived from the same master secret and other publicly observable fields. This means, that an attacker able to extract the state from the ticket can also decrypt the initial connection. As the ticket is issued in plain, it is observable by an attacker.

Scanning the Web

We analyzed 12 open-source implementations to see how session tickets are usually formatted and which cryptographic algorithms are used to protect them. Using this knowledge, we implemented tests for five implementation pitfalls and vulnerabilities with TLS-ScannerTLS-Scanner (on GitHub) is an open-source tool to evaluate TLS implementations.. In this post, we focus on the tests of weak STEKs and reused keystreams. We scanned hosts from the Tranco List  as well as randomly chosen IPv4 hosts with port 443 open. We performed three sets of scans:

  1. pre‑T1M and T1M: Our first scan of the Tranco top 1M was performed in May 2021 during the master thesis of Simon Nachtigall. We only scanned for keys consisting exclusively of zero bytes in TLS 1.2 and 1.3.
    Before performing the final T1M scan, we performed several test scans, summarized as the pre‑T1M scan.

  2. T100k and IP100k We performed two smaller but more detailed scans of 100k hosts each in April 2022. These were chosen as the top 100k from the Tranco list and 100k random IPv4 hosts that responded on port 443. For these, we also performed further tests not covered in this post.

  3. IPF Last, we scanned the entire IPv4 address range in August 2022. To this end, we only collected session tickets and performed the tests afterward without having to contact the servers again. We performed three TLS connections per host using ZGrab2, each time attempting to obtain a session ticket. We chose this number as it reduces the number of connections while hopefully still managing to connect to different servers if there is a load balancer.

First Findings

Encryption Authentication
Scan Servers
Found		 Algorithm Key Algorithm Key
pre-T1M 1903 AES-256-CBC 00 00 ... 00 00 –
20 AES-128-CBC 00 00 ... 00 00 HMAC-SHA256 00 00 ... 00 00

Unexpectedly, the pre-T1M scan directly uncovered many servers using an all-zero STEK. In the pre-T1M scan, we scanned the Tranco top 100k hosts multiple times. Summed up over all scans, we found 1923 (1.9%) distinct servers using an all-zero STEK. These belonged to AWS and Stackpath.

AWS

1,903 of the servers using an all-zero STEK were identified as belonging to AWS. These used AES-256-CBC to encrypt the tickets. We did not find the HMAC key and assume it was set correctly. Due to the high impact, we decided to report our finding before continuing with the full scan. The issue was promptly resolved.

We could see that the hosts were not vulnerable at all times but only in some time intervals. This suggested an error in the key rotation, which was later confirmed to us by AWS developers.

Stackpath

We also found 20 hosts belonging to Stackpath that used an all-zero STEK and HMAC key. These tickets were encrypted using AES-128-CBC and authenticated using HMAC-SHA256. Again, we immediately reported the issue.

The affected servers behaved differently from the AWS servers. When connecting to the server multiple times, only some tickets were encrypted using a weak STEK. This was not limited to a specific timeframe as in the case of AWS. Interestingly, we found all servers were hosted on the same IP address. Using an online reverse DNS lookup tool, we found a total of 171 domains on the same IP.We used https://www.yougetsignal.com/tools/web-sites-on-web-server/. By scanning these, and collecting 1,000 tickets per hostname, we found a total of 90 hostnames for which we could observe vulnerable tickets. We identified that on vulnerable hosts, on average 1.4% of the issued tickets per host were affected. Stackpath did not give us any insight into how this came to be but resolved the issue.

Further Weak STEKs

Encryption Authentication
Scan Servers
Found		 Algorithm Key Algorithm Key
T1M 3 AES-128-CBC 00 00 ... 00 00 HMAC-SHA256 00 00 ... 00 00
IP100k 0 – –
T100k 1 AES-128-CBC 00 00 ... 00 00 HMAC-SHA256 00 00 ... 00 00
IPF 5 AES-256-CBC 00 00 ... 00 00 –
94 AES-128-CBC 00 00 ... 00 00 HMAC-SHA256 00 00 ... 00 00
12 AES-256-CBC 00 00 ... 00 00 HMAC-SHA384 00 00 ... 00 00
3 AES-128-CBC 10 11 ... 1e 1f HMAC-SHA256 20...2f 00...00a
75 AES-256-CBC 31...31 00...00b HMAC-SHA256 31...31 00...00b
  1. This key consists of 16 consecutively increasing bytes followed by 16 0x00 bytes. [↩︎]
  2. This key consists of 16 0x31 bytes followed by 16 0x00 bytes. [↩︎]

During the T1M scan, after AWS and Stackpath have resolved the issue, we found three further hosts using an all-zero key for both encryption and HMAC. These hosts used AES-128-CBC with HMAC-SHA256 and supported TLS 1.2. One of these hosts also supported TLS 1.3, also using zero-keys for session tickets.

As can be seen in the table, with our subsequent IPF scan we could detect more interesting keys. We found 189 servers using a weak key. Out of these, 111 servers were using an all-zero key. For 5 hosts we did not detect a weak key for the HMAC algorithm. 12 hosts used SHA384, which no analyzed open-source library uses. This implies, they use a different implementation or reconfigured the used library. The remaining 78 servers did not use keys that solely consisted of zero bytes. We explore the detected keys in our paper.

Impact

The presented issues allowed to decrypt TLS session tickets. This allows a passive adversary to decrypt all resumed sessions. In TLS 1.2 this even allows decrypting the session where the ticket was issued, even if it was never resumed. TLS 1.3 mitigates parts of this issue by deriving the keys for the new session using a one-way function instead of plainly reusing them. This means, even if the ticket is decrypted, the attacker cannot decrypt the resumed session. Further, TLS 1.3 allows performing another key exchange when resuming a session. After this key exchange, the encrypted data is secure against a passive adversary again. This still leaves the 0-RTT data vulnerable to decryption.

All versions are vulnerable to active impersonation. An attacker able to decrypt the session ticket can impersonate the server as the authentication solely relies on the ticket. The server does not send a certificate or signature, hence the client cannot verify the identity of the server. This undermines the security guarantees of TLS.

As of now, we have not released a version of TLS-Scanner that can test whether you are affected by this issue. We plan on releasing it in time for the artifact evaluation for Usenix (June-August).

Takeaways

We showed that improper usage of session tickets can have devastating consequences for TLS connections and break forward secrecy guarantees delivered by TLS. The concrete issues discovered seem unlikely, but are an important reminder that looking for seemingly trivial or contrived issues can be worthwhile for auditors.

At its core, we attribute the observed issues to the unauditability of session tickets. Since the STEK and the layout are unknown and never revealed to the client, clients cannot simply validate the strength of the key, the presence of a MAC, or even the algorithms used. This lack of transparency creates a space for bad implementations, silently failing crypto, and hidden backdoors.

While key generation always seems to have this potential, it is especially severe for one-sided symmetric keys, as with asymmetric keys, at least the public key can be audited externally . Having hard-to-analyze keys in a protocol at a place where a weak or leaked key causes the protocol to fail catastrophically is a huge risk that requires careful consideration. Since these keys cannot be audited externally, we argue that libraries should start auditing them themselves before they use them.

In public key cryptosystems, it is already common practice to ensure that the generated key material is of a specific form, for example, to ensure that the key material will result in a strong key or as a safety net for failing random number generators. Adding additional checks to randomly drawn symmetric keys could, at least to some extent, ensure that accidentally weak key material does not break the protocol.

Further Results

In our paper, we have seen a single case of a reused nonce. As we did not perform a long time study, we cannot say whether this is a one-time issue or a more general problem. We argue that libraries should use nonce reuse-resistant algorithms to avoid this issue. In general misuse-resistant APIs should be developed and enforced.

We cover further attacks that can be applicable to session tickets in our paper. We also present the analysis of open-source implementations and their usage of session tickets. See our preprint for more details:

We Really Need to Talk About Session Tickets:
A Large-Scale Analysis of Cryptographic Dangers with TLS Session Tickets
Sven Hebrok, Simon Nachtigall, Marcel Maehren, Nurullah Erinola,
Robert Merget, Juraj Somorovsky, Jörg Schwenk

Citation

@online{we-really-need-to-talk-about-session-tickets,
  author = {Hebrok, Sven},
  title = {We Really Need to Talk About Session Tickets},
  year = 2023,
  url = {https://upb-syssec.github.io/blog/2023/session-tickets/},
  urldate = {2024-11-20}
}