Optimizing TLS Handshakes with Dynamic Key Exchange Preference at Scale
Cloudflare significantly improved TLS 1.3 handshake efficiency by moving from a static assumption about origin TLS preferences to dynamic, per-origin measurement. This architectural shift reduced HelloRetryRequests from 52% to 3.7% and cut p90 handshake latency by over 150ms, demonstrating the impact of intelligent edge-based protocol optimization on large-scale distributed systems. The solution involves probing origins out-of-band and applying learned preferences for key agreement algorithms, including post-quantum options.
Read original on InfoQ ArchitectureThe Challenge: Inefficient TLS 1.3 Handshakes at Scale
TLS 1.3 requires clients to commit to a key agreement algorithm in the initial ClientHello packet. If the client's guess for the server's preferred algorithm is incorrect, the server issues a `HelloRetryRequest`, forcing the client to send a second ClientHello with a different algorithm. This adds an extra round trip (RTT) to the handshake, significantly impacting latency, especially across a global network like Cloudflare's. Initially, Cloudflare statically guessed X25519 for all origins, assuming its high adoption rate (95%) would suffice. However, this led to a suboptimal experience for a substantial portion of connections, with 30% of origins preferring other curves, resulting in a 52% HelloRetryRequest rate for scanned origins.
Architectural Solution: Dynamic Key Exchange Preference
To address this, Cloudflare implemented "Automatic Key Exchange," an extension of its Automatic SSL/TLS service. This system probes each origin to dynamically learn and store its supported and preferred key agreement algorithms. This dynamic preference allows Cloudflare's edge to initiate handshakes with the correct algorithm, achieving a one-round-trip completion without retries. The probing mechanism operates outside the production traffic path to avoid impacting live connections and is designed to be resilient.
- Out-of-band Probing: Origins are scanned daily using one key agreement group at a time. This ensures preferences track changes in origin configurations (load balancers, TLS libraries).
- Preference Storage: Learned preferences are stored and applied across an entire zone.
- Prioritizing Post-Quantum: Where an origin supports it, Cloudflare prefers post-quantum hybrid X25519MLKEM768, moving towards future-proofing against quantum computing threats.
- Conservative Rollout: New preferences are initially applied to a small fraction of an origin's traffic. Failure and retry rates are monitored against a baseline, with automatic rollback if performance degrades.
System Design Takeaway: Dynamic Adaptation vs. Static Assumptions
This case highlights a critical principle in designing large-scale distributed systems: dynamic adaptation often outperforms static assumptions, even when those assumptions are based on high probabilities. Architectures that can observe, learn, and adapt to varying conditions across their ecosystem are inherently more resilient and performant. The overhead of observation and learning (out-of-band probing) is often a worthwhile trade-off for significant performance gains.
Handling Legacy and Post-Quantum Challenges
The implementation considers various complexities: A larger post-quantum keyshare (X25519MLKEM768 at 1,216 bytes) can push the ClientHello past a single network packet. While TLS allows multi-packet segments, some legacy middleboxes and origin servers fail when a ClientHello is split. Cloudflare initially used `HelloRetryRequest` as a safety valve, advertising post-quantum but leading with classical X25519, effectively forcing an extra RTT for post-quantum capable origins. The new system largely removes this penalty, increasing post-quantum origin traffic by enabling direct negotiation.
Furthermore, new compliance settings allow operators to enforce post-quantum hybrid only or FIPS-compliant algorithms. However, these settings carry a risk: enforcing unsupported algorithms will cause all TLS 1.3 connections to fail. This demonstrates a trade-off between strict compliance and connection availability, requiring careful management.