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“
Session tickets (RFC 5077
The server also includes a signature over its key exchange which the server has to compute, and the client has to verify.
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.
While TLS session tickets bring significant performance improvements for TLS connections
Such dangers are not only theoretical; in 2020, Fiona Klute discovered a vulnerability affecting the security of the session resumption mechanism in GnuTLS
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.
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-Scanner
pre‑T1M and T1M: Our first scan of the Tranco top 1M was performed in May 2021 during the master thesis of Simon Nachtigall
Before performing the final T1M scan, we performed several test scans, summarized as the pre‑T1M scan.
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.
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.
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.
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.
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.
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...00 a | |||||
75 | AES-256-CBC | 31...31 00...00 b | HMAC-SHA256 | 31...31 00...00 b |
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.
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).
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
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.
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:
@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-04-24}
}