Cloudflare Stops Guessing on TLS Key Exchange, Slashes Handshake Retries by 93%
For years, Cloudflare made the same assumption about every origin server on the internet: it supports X25519 for key agreement. That assumption was reasonable. More than 95% of origins do support it. But "supports" and "prefers" are different things, and the gap between them was costing Cloudflare's customers real latency on a significant share of connections.
This week, Cloudflare replaced that static guess with a measurement system called Automatic Key Exchange. The results are dramatic. HelloRetryRequests, the extra round trips that happen when the client picks the wrong key agreement algorithm, dropped from roughly 52% of scanned origins to 3.7%. P90 handshake latency fell by more than 150 milliseconds. And the feature unlocks post-quantum key exchange for origins that support it without imposing the round-trip penalty that previously made it impractical.
Why the Old Approach Was Suboptimal
TLS 1.3 changed the handshake dynamics in a way that makes the initial key agreement choice consequential. The client has to commit to a key agreement algorithm in its first packet, before the server has said anything about what it supports. If the client guesses right, the handshake completes in one round trip. If it guesses wrong, the server responds with a HelloRetryRequest, the client sends a second ClientHello with the correct algorithm, and the connection costs two round trips.
Cloudflare's previous strategy was to always lead with X25519, the elliptic curve that dominates modern TLS deployments. The logic was sound: X25519 is fast, secure, and supported by nearly every origin. But measurement revealed that roughly 30% of origin connections were suboptimal under this approach. More than 6% of origins prefer P-256 or P-384 over X25519. Those connections were paying an extra round trip for entirely classical reasons, not because of any security requirement or performance trade-off.
The extra round trip is not just a theoretical cost. For dynamic requests and CDN cache misses that require a fresh origin handshake, the additional 150-plus milliseconds at the p90 level compounds across millions of connections per day. For latency-sensitive applications, that margin matters.
How Automatic Key Exchange Works
The new system probes each origin to learn which key agreement algorithms it supports and which it prefers, then leads with the preferred algorithm. Probing runs outside the production traffic path, one key agreement group at a time, so it does not add latency to live connections. Origins are rescanned daily so that preferences track changes to load balancers, TLS libraries, and infrastructure updates.
Where an origin can handle the post-quantum hybrid X25519MLKEM768, Cloudflare prefers it. This is the meaningful upgrade: post-quantum key exchange protects traffic against future quantum computers that could break classical cryptography. But until now, enabling it carried a mandatory penalty. An X25519MLKEM768 keyshare is 1,216 bytes compared to X25519's 32 bytes, which pushes the ClientHello past a single network packet. Some legacy middleboxes and origin servers fail when a ClientHello is split across TCP segments. Cloudflare's earlier measurement found that roughly 0.34% of scanned origins failed to complete the handshake when sent a post-quantum keyshare first.
To work around this, Cloudflare had been using HelloRetryRequest as a safety valve since September 2023. The client would advertise post-quantum support but lead with classical X25519, and capable origins would request the upgrade via a retry. The result was that almost every post-quantum origin handshake paid a mandatory second round trip. The security benefit was real but the performance cost made adoption impractical for many use cases.
Automatic Key Exchange eliminates that penalty by probing first and leading with the algorithm the origin actually prefers. For origins that support post-quantum key exchange, the share of handshakes completing without a HelloRetryRequest jumped from 0% to 99.2%.
The Numbers in Context
Post-quantum origin support has grown from 0.5% in 2023 to 12.8% today. That means roughly seven in eight origins still cannot use it. Among the cohort Cloudflare has scanned so far, 64% stayed on classical X25519 with nothing about their connections changing, 33% moved to X25519MLKEM768, and 3% moved to a different classical curve such as P-384, P-256, or P-521.
The post-quantum traffic volume tells the adoption story. Post-quantum origin traffic across the scanned cohort grew from roughly 25 billion connections per day to 45 billion. Cloudflare attributes part of that increase to Automatic Key Exchange upgrading classical connections that previously could not use post-quantum key exchange because the origin preferred a different algorithm or because the round-trip penalty made it impractical.
The feature is on for all existing zones and on by default for new ones. A toggle in the dashboard under SSL/TLS controls it, and Cloudflare applies one preference across a zone. The rollout mechanism is conservative: a new preference goes to a small share of an origin's traffic first, with the system monitoring failure and retry rates against that origin's baseline. If retries climb, the change is rolled back. The worst case of a rollback is an additional round trip rather than a broken connection.
New Compliance Controls and Deprecations
A new Compliance requirements setting lets operators filter which key agreements Cloudflare may negotiate, with options for post-quantum hybrid only and for FIPS-compliant algorithms only. These settings narrow what Cloudflare can use rather than granting the origin new capabilities. Enforcing post-quantum hybrid against an origin that does not support X25519MLKEM768 leaves no mutually supported algorithm, and all TLS 1.3 connections to that origin fail. Selecting both options simultaneously is rejected if no algorithm satisfies both constraints. The settings apply only to TLS 1.3 connections.
Teams with existing automation should note that the Origin Post-Quantum Encryption API is now effectively a no-op. Requests to it do not change a zone's post-quantum key agreement behavior. Cloudflare plans to deprecate the API but has not given a date. Origins can be checked directly with BoringSSL's bssl client tool against port 443, confirming that the negotiated curve reports X25519MLKEM768.
What Teams Should Do Now
The latency improvement applies to new connections, so existing keep-alive connections are unaffected. The gain concentrates on dynamic requests and CDN cache misses that require a fresh origin handshake. Teams with high cache-miss rates or latency-sensitive dynamic content will see the most benefit.
For teams evaluating the compliance settings, the risk is straightforward: enforcing a key agreement that the origin does not support breaks connections. Test against your origins before enabling strict post-quantum or FIPS-only modes in production. The daily rescan means changes propagate quickly, but the initial configuration still requires care.
Key agreement protects today's traffic from future decryption but does not prevent an attacker with a quantum computer from forging a classical certificate and impersonating an origin. Cloudflare has supported ML-DSA post-quantum signatures since mid-2026 in Authenticated Origin Pulls and Custom Origin Trust Store, which together allow end-to-end post-quantum authentication to an origin. But presenting an ML-DSA certificate achieves nothing unless the verifying side rejects classical certificates, since an attacker who compromises a classical key can otherwise impersonate the peer.
Cloudflare frames the work against a 2029 target it calls Q-Day, the year some industry estimates suggest classical encryption could be breached, and against harvest-now-decrypt-later attacks where recorded traffic is stored for future decryption. The roadmap includes per-origin granularity for preferences, on-demand scans through the dashboard and API, and automatic detection of ML-DSA support to disable classical fallback for customers wanting strict protection. For now, the measurement approach has proven that even well-established assumptions about TLS behavior can hide significant performance costs, and that probing is cheaper than guessing.