# What Is Session Ticket (TLS session ticket)?

> 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.

Source: https://ssl.sh/glossary/session-ticket/
Last updated: 2026-11-10

Session tickets were introduced for TLS 1.2 in [RFC 5077](https://www.rfc-editor.org/rfc/rfc5077). 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](https://ssl.sh/glossary/psk/) for later [session resumption](https://ssl.sh/glossary/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](https://ssl.sh/glossary/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
```bash
openssl rand 80 > /etc/nginx/ticket.key   # nginx accepts 80- or 48-byte key files
chmod 600 /etc/nginx/ticket.key
```

```nginx
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.

## Related terms

- [会话恢复](https://ssl.sh/zh/glossary/session-resumption/): 会话恢复是 TLS 的一种机制，客户端重连时复用先前会话的密钥材料，跳过完整的密钥交换和证书验证。
- [PSK](https://ssl.sh/zh/glossary/psk/): PSK（预共享密钥）是 TLS 双方在握手前就已共同持有的秘密，用于会话恢复，或在不使用证书的情况下完成身份认证。
- [前向保密](https://ssl.sh/zh/glossary/forward-secrecy/): 前向保密是密钥交换的一种安全属性：即使服务器的长期私钥日后泄露，过去连接的会话密钥也不会因此暴露。
- [0-RTT](https://ssl.sh/zh/glossary/0-rtt/): 0-RTT 是 TLS 1.3 和 QUIC 的特性，允许回访的客户端用上一次会话留下的密钥，在第一个数据包里就发送应用数据。
- [密钥轮换](https://ssl.sh/zh/glossary/key-rotation/): 密钥轮换是按计划或在安全事件后，用新生成的密钥替换旧密钥，以限制密钥泄露造成损失的做法。
- [TLS 1.2](https://ssl.sh/zh/glossary/tls-1-2/): TLS 1.2 是 2008 年由 RFC 5246 定义的 TLS 版本，引入了基于 SHA-256 的密钥派生和 AES-GCM 等 AEAD 加密算法，至今仍被广泛使用。
- [TLS 1.3](https://ssl.sh/zh/glossary/tls-1-3/): TLS 1.3 是当前最新的传输层安全协议版本（2018 年的 RFC 8446，现行规范为 RFC 9846），完整握手只需一个往返，且只保留 AEAD 加密算法。