I want to highlight a behind-the-scenes change that improves the security guarantees provided by Cloudflare’s global HTTPS service. Since last year, Cloudflare has been using a different set of session ticket encryption keys (STEKs) in each datacenter for TLS resumption.
Previously, the same key was used across multiple datacenters, rotated every hour (blog.cloudflare.com/tls-session-re…). This was modeled after work by @j4cob and @jmhodges at Twitter (blog.twitter.com/engineering/en…) with more aggressive key rotation.
This aggressive rotation of ticket keys was not something server operators had attempted at scale and it uncovered some interesting client bugs, most notably in Microsoft Schannel (blog.cloudflare.com/microsoft-tls-…).
However, the same STEKs were used in all of Cloudflare’s 100+ locations. This sharing enabled the latency improvements of TLS resumption (one round-trip faster) to still apply when a location is taken out for maintenance and users are routed to a different one.
Global key sharing does not provide the strongest possible compromise resilience properties. If a STEK is compromised in one location, then any connection made anywhere in the world during that hour can be passively decrypted with that STEK.
This is due to the design of TLS versions prior to 1.3 in which handshake messages (including session tickets and the certificate) are always transmitted unencrypted.
Interestingly enough, this “attack” is also the inspiration for a hotly debated datacenter visibility proposal for TLS 1.3 (datatracker.ietf.org/doc/draft-rhrd…). Hint: give the STEK to whomever needs to decrypt the data.
In 2016, Drew Springall (@_aaspring_) and others did a study to measure the use of STEKs on the internet. Their findings were dire: most servers didn’t even rotate keys (aaspring.com/imc2016/crypto…)!
Due to an oversight in the research methodology (with BGP anycast, servers in different physical geographies can share the same IP) the paper does not measure resumption from multiple vantage points and therefore missed the fact that Cloudflare shared STEKs across geographies.
Each Cloudflare location now has a unique key that is mixed with an hourly key to create the STEK. The distribution mechanism was built during the development of Geo Key Manager (blog.cloudflare.com/geo-key-manage…), which limits Cloudflare’s access to private keys in different geographies.
This change tightens the risk window from STEK compromise considerably. TLS 1.3 improves things further because handshake messages sent from the server are encrypted. This reduces the risk of passive decryption with a compromised STEK to data sent over 0-RTT only.
These short-lived STEKs are still important to protect. TLS 1.3 only reduces the risk from a global passive adversary, not an active one. An active MITM can still hijack connections from clients who are resuming connections originally instantiated with a compromised STEK.
That said, Cloudflare is in a much better position to protect the confidentiality of people’s data in the event of a compromise now than previously. This is even more important now as people start to DNS-over-HTTPS with the 1.1.1.1 resolver.
As TLS 1.3 is deployed (3-4% connection to Cloudflare are TLS 1.3 already), it would be interesting to know how many big industry players followed @_aaspring_’s advice. I, for one, am happy Cloudflare made this change and encourage other service providers to do the same.
