tls – Key Material

DID YOU KNOW that TLS doesn’t actually have perfect forward secrecy in most circumstances?

Rather, TLS has “conditional future imperfect secrecy” because it would have had perfect forward secrecy without resumption.

a shattered brass metal lock on brown wood

“TLS Session Resumption” is the TLDR of the myth of forward secrecy in TLS.

SSL handshakes are expensive, requiring multiple round trips for key exchange and expensive computations. Enter TLS resumption. With TLS resumption, a session ticket enables both client and server to jump back into their shared session with a single round trip (plus the SYN/ACK round trip) — and the resumption key derivation is a tenth of the cost of the full key exchange computation (per Cloudflare’s resumption performance data).

However, that optimization comes at the cost of forward secrecy: compromising the stored session ticket compromises any past sessions (as well as future sessions, which is already assumed in the TLS threat model, since theft of TLS private key material will compromise any future sessions using that key).

Forward secrecy (or “perfect forward secrecy”, PFS) is the assurance that compromising a system at time T won’t cause a compromise of any sessions/messages before time T.

Once a system is compromised, forward secrecy does not provide assurances about future sessions, which are assumed to be compromised until secrets & keys are rotated (and attacker is removed, etc).

How does TLS provide forward secrecy when resumption isn’t enabled? Through key exchange! The foundation of confidentiality in TLS is through a sequence of cryptographic operations in which the client and server share public values that they each combine with their private values to produce their shared secret (which is cryptographically infeasible for observers to derive from only the public values).

How does resumption violate forward secrecy? If the attacker, Eve, compromises the server after a TLS session, they would have the resumption ticket and the TLS private key. The TLS private key enables Eve to impersonate the server. The resumption ticket enables Eve to breach the confidentiality of past recorded TLS sessions. (Notwithstanding the caveats in the last section.)

TLS Resumption: Stateful & Stateless

TLS resumption comes in 2 flavors, stateful and stateless. The abbreviated handshake for TLS resumption is an extension to the typical ClientHello & ServerHello, enabling the abbreviated handshake to fall back to the full handshake if either side doesn’t have the resumption data.

In stateful resumption, server designates a session ID and both the client server store that ID with the shared secret derived in key exchange. The client can then begin in the ClientHello by including a session ID along with the usual ClientHello (cipher suite, random number, etc). ServerHello response also includes the session ID with the usual ServerHello (cipher suite, random number, etc). Each side combines those random numbers are combined with the shared secret corresponding to the session ID to derive a new shared session secret.

Stateful resumption requires a connection with the same single “server” holding onto those session details, which are usually cached in memory for up to 24 hours.

The plaintext session information or session ticket IS the shared symmetric encryption key (often called the “master secret”) used to encrypt the first TLS session between a client and a server.

Would it be wise to store a different key so that past sessions are protected by forward secrecy? Yes.

Is that how session resumption was bolted onto SSL? Nope!

In stateless resumption, the server stores session details (protocol version, cipher suite, shared secret, and client identity) in an encrypted session ticket, and this session ticket is stored by the client. The client can resume the session by sending the session ticket in the ClientHello.

The session ticket is encrypted by the Session Ticket Encryption Key (STEK), which is only known to the server, and is typically rotated every 1-24 hours (but can be arbitrarily longer, per RFC 5077). Thus, the server only needs to hold on to the STEK, and the client holds onto the session ticket along with the shared secret.

See examples of session resumption packets.

Compromises Are Made

The false promise of TLS’s claim to forward secrecy was that a server compromise would not compromise the confidentiality of previous TLS sessions. However, with TLS resumption, the forward secrecy of past sessions is bound to the lifetime of the session information or Session Ticket Encryption Keys held on the server.

Compromising a server holding session information hands the shared session keys directly to the adversary, Eve. In the case of session tickets, if EVE gets hold of the STEK, they can decrypt the encrypted session ticket to get the same session information. The session information encrypted by the STEK is directly the previous session’s shared symmetric encryption key, and thus Eve can decrypt the encrypted messages of the TLS session.

Either case also requires the adversary to observe and record past sessions (from handshake onwards) — but recall that the maintaining confidentiality of all previous recorded sessions in the event of a compromise is exactly the assurance of perfect forward secrecy.

TLS 1.3 & 0-RTT

TLS 1.3 supports a resumption mode called “0-RTT” (zero round trip time). With 0-RTT, a client can use a Pre-Shared Key (PSK) to send an encrypted HTTP request with the very first message (after SYN/ACK). This is called “early data”.

Because the PSK is used directly as the symmetric encryption key, the early data transmitted by the client is not protected by forward secrecy (much like session tickets in earlier TLS versions). However, the client may start (EC)DHE key sharing in that first message, enabling the server to complete key exchange and send a response that IS protected by forward secrecy. If an attacker breaches the STEKs and has a (recently) recorded message, they can decrypt the PSK and then decrypt the early data — but starting from the server’s response, the attacker will not be able to decrypt later messages that are encrypted using the new shared key derived from (EC)DHE.

If you’re interested in digging into the details of how the TLS 1.3 handshake achieves this, I recommend this C3 talk by Filippo Valsorda and Nick Sullivan.

This sounds great! TLS 1.3 delivers forward secrecy with TLS resumption! Rejoice! Alas, briefly —

In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described in RFC 2119.

https://datatracker.ietf.org/doc/html/rfc2119

That is, the client MAY start (EC)DHE key sharing next to the PSK-encrypted HTTP request in the TLS 1.3 ClientHello. The reality of whether this is applied in practice is…inconsistent.

This (along with systemic oppression) is why we can’t have nice things.

Implementations can choose to require that clients perform key exchange (either in resumption or as a brand new session). For example, BoringSSL requires fresh key material in TLS 1.3 resumption.

0-RTT Replay Attack

Without compromising server nor client, an attacker can replay a 0-RTT message from a client. While the message’s confidentiality and integrity are protected by the PSK, a replay attack can cause a server to perform the previously requested action again, potentially under different circumstances — e.g., “undo the last action” or “open this door” [for the attacker]. Thus, 0-RTT requests should be idempotent (which by definition means “produce the same result regardless of how many times this function is applied”).

Conclusion

You might have wondered when session resumption “officially” became part of SSL or TLS. This is hard to trace, because the practice of storing session keys and using the SessionID in ClientHello extensions for session resumption dates back earlier than the 1996 SSL 3.0 protocol, as captured for historical record by RFC 6101.

Papers analyzing SSL 3.0 refer to session resumption in SSL 2.0. E.g., in Wagner & Scheier’s “Analysis of the SSL 3.0 Protocol”, they specifically call out rollback attacks involving session resumption. The paper finishes with a specific callout around the sensitivity of the master secret:

“Ensuring that the master secret remains truly secret is tremendously important to the security of SSL. All session keys are generated from the master secret, and the protection against tampering with the SSL handshake protocol relies heavily on the secrecy of the master secret. Therefore, it is important that the master secret be especially heavily guarded.“
Wagner D, Schneier B (1996) Analysis of the SSL 3.0 protocol. In: The Second USENIX Workshop on Electronic Commerce Proceedings, vol 1, no 1, pp 29–40
https://www.usenix.org/legacy/publications/library/proceedings/ec96/full_papers/wagner/wagner.pdf

That being said, forward secrecy was just barely on the radar in the mid-1990s, and primarily from the perspective of compromising months and years of confidential messages after a private key is compromised. The idea of remotely (or physically) compromising a server in order to compromise the confidentiality of a handful of recent sessions was not a relevant threat at that time.

Even today, compromising TLS session resumption tickets remains a negligible threat in the overwhelming majority of threat models.

Welcome to Stupid TLS Facts! If you particularly enjoyed/hated this, why not share it with your friends?

Appendix: Nuances are made

Threat Modeling Conditional Forward Secrecy in TLS

Is the limited nature of the conditional forward secrecy provided by TLS relevant to Alice & Bob? Let’s examine a few scenarios that could be impacted by compromised TLS session information within 24 hours after these events:

Alice browses Wikipedia: No confidential data.
Alice receives an email from her mother: Potentially confidential information. Alice would be surprised by a breach of that confidentiality. Alice probably isn’t a target of an attacker. It’s up to Alice to evaluate her own threat model, but this is almost definitely not a priority.
Alice reads Bob’s free speech and right to privacy blog: No confidential information. Alice should explain to Bob that freedom of speech is a right to expression without fear of government retaliation or censorship, give him 1984 by George Orwell, and teach him how to assess his threat model.
Alice is a CEO of a major corporation who receives an email from her CFO: Likely confidential information. Alice would be surprised by a breach of that confidentiality. Alice is probably the target of an attacker. Could have moderate impact beyond Alice. Alice’s security org might evaluate how their critical services such as email providers configure TLS resumption — but any attacker that is interested in Alice’s corporation probably has more impactful targets in reach if they manage to get resumption keys (either at that corporation or at an email provider) — such as breaching the mail database itself. High effort and high risk for a “moderate” reward at best.
Alice is a CEO of a major corporation whose customers have high expectations for confidential interaction with their services: Alice’s security org should definitely take care in evaluating resumption (and all) key management practices regularly, as well as configuration of TLS resumption. (E.g., BoringSSL requires fresh key material in TLS 1.3 resumption.)
Alice is a leader of a Nation State who receives a confidential email from another Nation State leader, Bob: Definite breach of sensitive confidential information. Alice should definitely know about this risk and work to avoid it. Nation States are definitely high profile targets for many attackers, with potentially broad and severe impact for a breach of confidentiality. Alice is undoubtedly already using protocols supporting backward secrecy (AKA self-healing secrecy providing post-compromise confidentiality), such as Signal’s double ratchet algorithm.
Alice is organizing protests against human rights violations: Alice should absolutely be relying on protocols supporting end to end encryption, full perfect forward secrecy, self-healing secrecy, and more — see the Electronic Frontier Foundation’s guide to Surveillance Self-Defense.

TLS cipher suites lacking forward secrecy

TLS 1.3 only supports cipher suites that provide forward secrecy (aside from the resumption mode without key exchange). Before TLS 1.3, some allowed cipher suites could not assure forward secrecy. These were allowed to enable compatibility

In TLS 1.2, cipher suites without forward secrecy were marked as not recommended. Notably, RSA key exchange is deprecated.

See additional detail in a recent draft RFC by John Preuß Mattsson, “NULL Encryption and Key Exchange Without Forward Secrecy are Discouraged“. This RFC has some excellent references as well, including “Pervasive Monitoring Is an Attack” (RFC 7258).

TLS 1.2 ClientHello & Random Numbers

In TLS 1.2, the client and server each send new random numbers to derive a new shared secret for each session resumption. How is this different from TLS 1.3? Because in TLS 1.2, these random numbers are hashed together with the shared secret to create the new shared secret (an inexpensive operation), whereas in TLS 1.3, these new random values are used in (EC)DHE to derive a new shared secret (a relatively more expensive operation). (c.f., RFC 4346 Security Considerations).

Modern Architecture & Key Management

The reality of modern server architecture is that you’ll have a collection of servers—and more likely, a collection of load balancers terminating TLS at the “edge” of your cloud environment. The days of deriving an encryption key held only in memory by a single server are over: more likely, a set of STEKs will need to be managed across a collection of servers, so that any given server can decrypt the session tickets that another server created for that client.

As recommended by Adam Langley, these session ticket keys should be

Randomly generated and distributed (probably regionally)
Rotated frequently (to limit how severely forward secrecy is compromised)
Held in memory and never written to persistent storage (because the only method to delete data with high assurance is to destroy the storage medium following NIST 800-88 media sanitization guidelines)

TLS 1.3 External PSKs

Earlier, I described Pre-Shared Keys in TLS 1.3 as a value provided by the server at the end of the TLS 1.3 handshake. However, as implied by the PSK naming, TLS 1.3 supports a client designating and using a Pre-Shared Keys in exactly the same way as PSKs are used in IPsec or WPA.

RFC 9257 (“Guidance for External Pre-Shared Key (PSK) Usage in TLS“) addresses the security properties provided by PSKs and the sharp edges around designing key distribution for PSKs.

Session Resumption Predates RFCs

“Ensuring that the master secret remains truly secret is tremendously important to the security of SSL. All session keys are generated from the master secret, and the protection against tampering with the SSL handshake protocol relies heavily on the secrecy of the master secret. Therefore, it is important that the master secret be especially heavily guarded.“
Wagner D, Schneier B (1996) Analysis of the SSL 3.0 protocol. In: The Second USENIX Workshop on Electronic Commerce Proceedings, vol 1, no 1, pp 29–40
https://www.usenix.org/legacy/publications/library/proceedings/ec96/full_papers/wagner/wagner.pdf