← Back to Table of Contents

Session Resumption

The TLS handshake involves public key cryptography, certificate validation, and key derivation. It’s computationally expensive and adds latency. If a client reconnects to the same server shortly after, doing the full handshake again is wasteful. Session resumption lets them skip most of it.

It’s like going through airport security. The first time, you show your passport, get your bags scanned, walk through the metal detector. But if you step out to grab a coffee and come back two minutes later, it would be ridiculous to go through the whole process again. You flash your boarding pass and walk through. That’s session resumption.

Session IDs

The original resumption mechanism. During the initial handshake, the server assigns a Session ID and stores the session state (master secret, cipher suite, etc.) in memory.

When the client reconnects, it includes the Session ID in its ClientHello. If the server still has the session state cached, it responds with the same Session ID in the ServerHello, and both sides skip directly to ChangeCipherSpec and Finished. No certificate exchange, no key exchange.

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: Abbreviated Handshake
    C->>S: ClientHello (with Session ID from previous session)
    S->>S: Look up Session ID in cache
    S->>C: ServerHello (same Session ID)
    S->>C: ChangeCipherSpec
    S->>C: Finished
    C->>S: ChangeCipherSpec
    C->>S: Finished
    Note over C,S: Resumed. Encrypted data flows.

The problem: the server must store session state for every client. For a busy server handling millions of connections, this requires significant memory. And it doesn’t work across multiple servers behind a load balancer (unless they share a session cache).

Session Tickets

Session tickets solve the server-side storage problem. Instead of the server storing the session state, it encrypts the session state and sends it to the client as a “ticket.” The client stores the ticket and sends it back on reconnection. The server decrypts the ticket, recovers the session state, and resumes.

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: Initial Handshake (full)
    C->>S: ClientHello
    S->>C: ServerHello + Certificate + ...
    Note over C,S: ... full handshake ...
    S->>C: NewSessionTicket (encrypted session state)
    Note over C: Store the ticket

    Note over C,S: Later: Resumption
    C->>S: ClientHello (with session ticket)
    S->>S: Decrypt ticket, recover session state
    S->>C: ServerHello
    S->>C: ChangeCipherSpec + Finished
    C->>S: ChangeCipherSpec + Finished
    Note over C,S: Resumed.

The server doesn’t need to store anything. The ticket is encrypted with a key only the server knows (the Session Ticket Encryption Key, or STEK).

The Forward Secrecy Problem

Session tickets have a subtle security issue. The STEK is a long-lived symmetric key on the server. If it’s compromised, an attacker who recorded past session tickets can decrypt them and recover the session state (including the master secret) for every resumed session.

This partially undermines forward secrecy. The original handshake used ephemeral keys, but the resumed session’s security depends on the STEK.

Mitigations:

• Rotate the STEK frequently (every few hours)
• Use different STEKs across servers
• TLS 1.3 redesigned session resumption to address this (covered in the TLS 1.3 chapters)

---