Rotating TLS session-ticket keys without weakening resumption
TLS session tickets let a server resume a connection without storing every session locally. In TLS 1.2, the ticket is protected with a ticket-encryption key. If that key is exposed, an attacker can decrypt captured tickets and recover session secrets, which erodes the forward secrecy expected from a fresh key exchange.
RFC 9325 points to a concrete operational limit: a TLS 1.2 server should not resume sessions that are older than two ticket-encryption key rotation periods. The exact period depends on traffic, token lifetime and recovery requirements, but the policy needs an explicit owner.
Treat ticket keys as live keys
A ticket key must be generated from a suitable random source, stored outside the web application's ordinary configuration bundle and distributed to every server that accepts the same tickets. Servers that disagree about the active key will reject valid tickets or issue tickets that peers cannot read.
Keep a bounded overlap for rotation. Publish the new key, make it current for new tickets, retain the previous key only for the maximum resumption lifetime, then remove it. Record the key version and the times when acceptance starts and ends. A backend restart, autoscaling event or rollback must not silently restore an expired key.
For TLS 1.3, resumption uses a pre-shared key derived through the protocol rather than a TLS 1.2 ticket protected in exactly the same way. The operational questions remain: limit ticket age, control the key material and make retirement reachable. Clients are expected to discard cached tickets after a reasonable period, and RFC 8446 sets an upper bound of seven days, but the server should enforce its own session policy.
Verify the rotation path
Open a connection before rotation, complete a second handshake after rotation and confirm whether the old ticket is accepted for the intended overlap. Then advance beyond the retirement time and confirm that it is rejected. Repeat through a load balancer and through a rolling deployment.
Inspect logs for ticket decryption failures and distinguish normal expiry from a key mismatch. A sudden rise after deployment can indicate that one pool received a different key set. Keep metrics without logging ticket contents.
The decision is not whether resumption still works on one host. It is whether every host accepts the same key versions, stops accepting retired tickets on schedule and can recover from a key-store failure without extending the overlap indefinitely.
Top comments (0)