中文

Glossary

Session Ticket (TLS session ticket)

Last verified

Definition

Session tickets are encrypted blobs of TLS session state that a server hands to the client, so the client can later resume without the server storing anything.

Session tickets were introduced for TLS 1.2 in RFC 5077. After a handshake the server encrypts the session state, including the master secret, with a symmetric session ticket encryption key (STEK) that only the server knows, and sends the result to the client. When reconnecting, the client presents the ticket and the server decrypts it to resume. TLS 1.3 keeps the name: the server sends NewSessionTicket messages after the handshake, and each ticket identifies a PSK for later session resumption.

Why it matters

Tickets make resumption work across a large fleet without a shared session cache, as long as every server holds the same STEK. That key is the weak point. In TLS 1.2, anyone who obtains a STEK can decrypt every recorded session whose ticket it protected, which undermines forward secrecy. Ticket keys therefore need to be random, kept out of backups and logs, distributed securely and rotated often. Some hardening guides recommend disabling tickets for TLS 1.2 when rotation cannot be guaranteed.

Example

openssl rand 80 > /etc/nginx/ticket.key   # nginx accepts 80- or 48-byte key files
chmod 600 /etc/nginx/ticket.key

ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/ticket.current.key;   # encrypts new tickets
ssl_session_ticket_key /etc/nginx/ticket.previous.key;  # still accepted for decryption

When several keys are listed, nginx uses only the first to encrypt new tickets, which allows overlap during rotation.

Common misconceptions

  • Tickets are encrypted with the certificate's private key. They use a separate symmetric key; the certificate key is not involved.
  • Renewing the certificate also rotates the ticket keys. The two are independent. A long-lived STEK survives any number of certificate renewals unless you rotate it yourself.
  • TLS 1.3 tickets have the same forward-secrecy problem. With the psk_dhe_ke mode, TLS 1.3 resumption adds a fresh ECDHE exchange, so a leaked ticket key exposes only 0-RTT data.

See also