TLS Handshake Session Resumption

What is TLS session resumption?

The full TLS handshake is expensive — key exchange, certificate validation, multiple round trips before any data flows. Session resumption lets a client and server that have already completed a handshake reconnect using the previously-established secrets, skipping the costly parts. Where a fresh TLS 1.3 handshake takes one round trip, a resumed one takes zero to one — a meaningful latency cut for the extremely common case of a client making repeated connections to the same server.

The two mechanisms

Session IDs (the older approach): the server stores session state and hands the client an ID; on reconnect the client presents it and the server looks up the cached secrets. Simple, but requires server-side state — a problem for load-balanced fleets where the reconnection may land on a different server that doesn’t have the session (solved with shared session caches, at added complexity). Session tickets (the modern approach): the server encrypts the session state into a ticket it gives the client to hold; on reconnect the client presents the ticket, the server decrypts it, and no server-side storage is needed — which is why tickets scale cleanly across stateless server fleets. TLS 1.3 unified and streamlined this into PSK-based resumption.

0-RTT and its sharp edge

TLS 1.3’s headline is 0-RTT resumption: a resuming client can send application data in its very first message, before the handshake completes — zero round trips to first byte, the fastest possible reconnection. The catch is a genuine security tradeoff: 0-RTT data is vulnerable to replay attacks (an attacker can capture and resend that early data), so it must be restricted to idempotent requests (a GET, never a “transfer money”). This is why 0-RTT is powerful but must be used carefully — it trades a replay-safety guarantee for latency, and using it for non-idempotent operations is a real vulnerability, not a theoretical one. Combined with keep-alive connection reuse, resumption is why modern HTTPS to a familiar server feels instant.

What people get wrong

• 0-RTT for non-idempotent requests — exposing state-changing operations to replay for a latency win.
• Session IDs behind a load balancer without a shared cache — resumption silently fails when reconnects hit a different node.
• Ignoring ticket key rotation: session ticket encryption keys must rotate, or a leaked key compromises past resumable sessions (a forward-secrecy gap).

Primary source: RFC 8446 — TLS 1.3 (session resumption)