Session Tickets at CloudFlare
CloudFlare’s solution to this problem, documented in previous blog posts, is to frequently regenerate and synchronize these session ticket keys across our entire global network. We currently do this once per hour.
This means we need a mechanism for turning over session ticket keys. For instance, if a client instantiates an HTTPS session at 12:00pm and continues using that ticket past 1:00pm, our edge network will re-encrypt the ticket with a brand new session ticket key.
To accomplish this, our web servers must have both the full history of all previous keys that could have encrypted the ticket (i.e., one per hour dating back to the maximum session lifetime of 64,800 seconds) as well as immediate access to each newly generated key. The previous keys are used exclusively to decrypt tickets presented by the client, while the new keys are used to "refresh" the encryption on existing tickets and encrypt tickets for entirely new sessions.
So it would be correct to say that if any of Cloud Flare's endpoint servers is compromised, the adversary can decrypt traffic passively on a global scale?
prdonahue|8 years ago
$ openssl s_client -connect cloudflare.com:443 2>/dev/null | grep "lifetime hint" TLS session ticket lifetime hint: 64800 (seconds)
--
We've written about how we manage TLS session tickets here: https://blog.cloudflare.com/tls-session-resumption-full-spee....
Additionally, I wrote here about a bug that we encountered with Microsoft's implementation of TLS session resumption: https://blog.cloudflare.com/microsoft-tls-downgrade-schannel....
Here's a snippet from my blog post:
Session Tickets at CloudFlare CloudFlare’s solution to this problem, documented in previous blog posts, is to frequently regenerate and synchronize these session ticket keys across our entire global network. We currently do this once per hour. This means we need a mechanism for turning over session ticket keys. For instance, if a client instantiates an HTTPS session at 12:00pm and continues using that ticket past 1:00pm, our edge network will re-encrypt the ticket with a brand new session ticket key.
To accomplish this, our web servers must have both the full history of all previous keys that could have encrypted the ticket (i.e., one per hour dating back to the maximum session lifetime of 64,800 seconds) as well as immediate access to each newly generated key. The previous keys are used exclusively to decrypt tickets presented by the client, while the new keys are used to "refresh" the encryption on existing tickets and encrypt tickets for entirely new sessions.
sdevlin|8 years ago
zaroth|8 years ago
sdevlin|8 years ago