TL/DR: we rotate them every hour, but need to keep history of previous STEKs for 18 hours to support the maximum session lifetime:

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

These are great details, but they don't really answer my question.

It says in that deck: Distribute globally, rotate hourly, expire after 18 hours.

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?

I assume that's the point </s>

With Anycast I don't think you have the choice of not georeplicating the STEK. And latency is one of their biggest selling points. So you could say they are trying to make the best of a bad situation.

It is absolutely bizarre that the STEK-encrypted session key is not itself sent inside the session encrypted channel.

You do have the choice. You don't need session tickets at all to run TLS. The cost of geographically-distinct STEKs would simply be an additional handshake if the client hops regions. (Is this common?)

This is a choice Cloud Flare is making in favor of performance, and it seems sort of risky with respect to a well-funded global adversary. This makes persistent access to any single endpoint server incredibly valuable.

But maybe regional STEKs are impractical from a performance perspective. I assume Cloud Flare has performance measurements to justify this choice. I'd be interested to read a blog post about it.