1.2.6 Ensure Ticket Keys Are Rotated
In TLS, session resumption is implemented using one of two approaches. The original approach was to have the server keep the state in persistent storage. Later, session tickets were added, and they work like HTTP cookies. Session state is packaged into a binary blob, encrypted, and sent back to the client to store and send with all subsequent connections.
Session ticket security is very important to get right if you’re deploying TLS 1.2. In this scenario, knowing the ticket key is all you need to decrypt past communications. Fortunately, TLS 1.3 brought some much-needed improvement in this area. This updated protocol version uses session tickets for authentication, but has an option (enforced by all modern browsers) to perform an ephemeral Diffie-Hellman handshake on all resumed connections, thus protecting them individually. The end result is that knowing the ticket key is no longer sufficient for passive decryption, making it a much smaller attack vector.
When session tickets are used with TLS 1.2, the security of all connections depends on the main ticket key. This key is used to safely encrypt and decrypt session tickets. The security of the ticket key is an area in which current server software doesn’t provide adequate controls. Most applications that rely on OpenSSL use implicit ticket keys that are created on server startup and never change. If the server process stays up for weeks and months, then so does the ticket key. Backdooring applications is relatively easy for skilled attackers; you can inject a static, never-changing ticket key to give you the ability to decrypt all communication. The most secure deployments of TLS configure ticket keys explicitly and rotate them on a predetermined schedule—for example, daily.