Cloudflare cuts TLS handshake retries from 52% to 3.7% with per-origin measurement

Cloudflare published data on a quiet adjustment with a measurable practical effect: a change in how it negotiates TLS with the origin servers behind its CDN. The result, according to the company, was cutting the HelloRetryRequest rate (the retransmission that adds an extra round trip to the handshake) from about 52% to 3.7% across scanned origins, removing more than 150 ms of p90 handshake latency (InfoQ).

The years-long guess that TLS 1.3 forces you to make

TLS 1.3 requires the client to choose a key exchange (key agreement) algorithm already in the first packet, the ClientHello, before knowing what the origin actually supports. Getting the algorithm right closes the handshake in one round trip. Getting it wrong forces the origin to respond with a HelloRetryRequest, the client resends a second ClientHello, and the connection ends up costing two round trips instead of one.

Cloudflare had been solving this with a fixed assumption: X25519 for every origin on the internet, because more than 95% of servers support that algorithm. But actually measuring revealed that this guess was wrong for about 30% of origin connections. More than 6% of origins prefer P-256 or P-384 over X25519, which means those connections were paying an extra round trip for a purely classical reason, with no relation whatsoever to post-quantum cryptography.

What Automatic Key Exchange does differently

The feature, named Automatic Key Exchange and derived from the existing Automatic SSL/TLS, probes each origin outside the production traffic path, testing one key agreement group at a time to discover what that origin supports and prefers. Based on that, Cloudflare starts leading the handshake with the right algorithm from the first packet. Origins are rescanned daily, so the preference tracks load balancer or TLS library changes without manual intervention.

The feature is already turned on for all existing zones and comes enabled by default on new zones, with a toggle in the SSL/TLS dashboard. It's worth noting that Cloudflare applies a single preference per whole zone, not per individual origin, which is a relevant limitation for anyone running heterogeneous infrastructure behind the same domain.

An interesting side effect of active measurement: it uncovered thousands of origins whose post-quantum cryptography support had never shown up in passive traffic, because many servers silently accept a classical keyshare instead of issuing a retry, even when they support something stronger.

Why the post-quantum key was so heavy

An X25519MLKEM768 keyshare (the post-quantum hybrid) is 1,216 bytes versus X25519's 32 bytes, which pushes the ClientHello beyond a single network packet. The TLS standard allows a ClientHello fragmented across multiple TCP segments, but some legacy middleboxes and origin servers break when that happens. In an earlier Cloudflare study, about 0.34% of scanned origins failed to complete the handshake when they received a post-quantum keyshare first.

Because of this, since September 2023 the company had been using HelloRetryRequest as a safety valve: it advertised post-quantum support but led with classical X25519, requiring capable origins to request the upgrade via a retry. In practice, almost every post-quantum handshake paid a mandatory second round trip, the opposite of the security gain it was supposed to bring.

With per-origin measurement, this picture changes: the share of post-quantum TLS 1.3 traffic completed without a HelloRetryRequest rose from 0% to 99.2%. Post-quantum support among scanned origins grew from 0.5% in 2023 to 12.8% today, and within that already-measured universe, 64% stayed on classical X25519 with no change to the connection, 33% migrated to X25519MLKEM768, and 3% moved to another classical curve such as P-384, P-256, or P-521. Daily post-quantum traffic in the scanned cohort jumped from about 25 billion to 45 billion connections per day.

What changes for those who build and operate APIs

For teams running backends behind Cloudflare, the latency gain concentrates in two scenarios: dynamic requests and CDN cache misses, situations where a new TLS handshake with the origin is mandatory. Already-established keep-alive connections aren't affected, so the benefit shows up more in traffic spikes, cold starts, and services with a low cache hit rate, not in APIs that already reuse persistent connections.

There's also a new Compliance requirements setting, with options to require only hybrid post-quantum or only FIPS-compatible algorithms. Worth paying attention here: these options restrict what Cloudflare can negotiate, they don't grant new capability to the origin. Forcing hybrid post-quantum against an origin that doesn't support X25519MLKEM768 leaves zero algorithms in common, and all TLS 1.3 connections to that origin fail. Choosing both options simultaneously is rejected if no algorithm satisfies both at once.

Anyone automating infrastructure via API needs to notice one silent change: the Origin Post-Quantum Encryption API is still available, but calls to it are now no-ops, they no longer alter a zone's key agreement behavior. Cloudflare has already signaled that it plans to deprecate this API, with no set date. To check in practice which curve is being negotiated with a specific origin, you can use BoringSSL's bssl client pointed at port 443 and check whether the result reports X25519MLKEM768.

The feature's rollout is conservative: a new preference first goes to a small slice of each origin's traffic, with failure and retry rate monitoring against that origin's baseline. If retries rise, the change is automatically reverted, the same pattern Automatic SSL/TLS already uses. According to Cloudflare, the worst-case rollback scenario is one extra round trip, never a broken connection.

What still remains open

Key exchange solves only half of the post-quantum security problem: it protects today's traffic against future decryption, but it doesn't stop an attacker with a quantum computer from forging a classical certificate and impersonating the origin. Cloudflare has already supported ML-DSA post-quantum signatures since mid-2026 in Authenticated Origin Pulls and in the Custom Origin Trust Store, which together enable end-to-end post-quantum authentication all the way to the origin. The company's own documentation warns that presenting an ML-DSA certificate accomplishes nothing if the verifying side still accepts classical certificates, since an attacker who compromises the classical key can impersonate the peer anyway.

On the roadmap, three items: per-origin granularity (today the preference is decided for the whole zone, so one lagging origin holds back the entire zone), on-demand scans via dashboard and API to reassess after a TLS stack upgrade without waiting for the daily scan, and automatic detection of ML-DSA support to disable classical fallback for clients that want strict protection.

Cloudflare frames the whole effort against what it calls Q-Day, the year 2029 flagged by some industry estimates as the horizon by which classical cryptography could be broken, and against harvest-now-decrypt-later attacks, in which traffic captured today is stored for future decryption. Recent versions of BoringSSL, OpenSSL, and rustls already bring post-quantum support, but corporate origin stacks, cloud load balancers, and embedded TLS terminators follow their own upgrade schedules, which explains why seven out of eight origins still can't use the post-quantum hybrid.