TLS Session Resumption
TLS session resumption shortens subsequent handshakes by reusing negotiated session state, via session identifiers, session tickets, or QUIC and TLS 1.3 0-RTT early data, cutting repeat-visit latency.
Definition
Session resumption lets a client prove prior session state instead of repeating a full handshake. TLS 1.2 uses session IDs or encrypted session tickets; TLS 1.3 and QUIC derive resumption secrets that can also carry 0-RTT early data. The savings are one to two round trips per reconnection.
Context and scope
Matters for short-lived connections that recur: API clients, mobile apps resuming from background, edge POPs with high churn. Also the reason ticket key rotation is a CDN security control.
Common misconceptions
- Resumption is only a performance nicety — ticket keys can decrypt past traffic if compromised, so rotation is a security requirement
- 0-RTT is always safe to enable — early data is replayable and needs per-endpoint replay protection
- Session tickets work like cookies — they are opaque server-encrypted state, not a client credential
Anti-patterns
- Reusing one ticket key across many edge servers for weeks, creating a single point of decryption failure
- Accepting 0-RTT early data on non-idempotent endpoints without replay windows or nonce tracking
- Disabling resumption entirely and wondering why mobile reconnect latency doubled
Related concepts
Related examples
Authoritative source
What it is
A full TLS handshake costs one or two round trips before the first application byte. Resumption lets the pair skip the expensive part by presenting a ticket or PSK that the server issued earlier. The connection inherits the original cipher suite decisions and identity assumptions.
How it works
In TLS 1.2 the server either stores session state keyed by an ID or encrypts it into a ticket handed to the client. TLS 1.3 separates resumption from the handshake and adds early data: the client sends application data in flight zero, encrypted under a key derived from the ticket. Servers keep a replay window to reject duplicates.
When to use it
API gateways, mobile backends, and CDN edges should enable ticket resumption with frequent key rotation. 0-RTT suits idempotent GET traffic where replay is harmless. Long-lived internal connections benefit less since they amortize the handshake anyway.
Pitfalls
Ticket keys are decryption keys for resumed traffic; rotating them frequently bounds the damage of compromise. 0-RTT data can be replayed by an attacker, so POST-like operations must not trust it without anti-replay tracking. Load balancers that pool tickets across unrelated backends can leak session affinity assumptions.