TLS 1.3 lets a client finish a handshake in one round trip, but only if it guesses the origin's preferred key agreement algorithm correctly in the first packet. Guess wrong and the origin answers with a HelloRetryRequest (HRR) — protocol-legal, but it costs a full extra round trip before any content moves.
For years Cloudflare's guess on origin connections was always X25519. On 2026-09-08 the company announced Automatic Key Exchange, which replaces that static guess with a measurement: it probes each origin, learns which key agreement groups it supports, and leads with the strongest one on the first try. Across the scanned cohort, HelloRetryRequests fell from roughly 52% to 3.7%, cutting more than 150 ms off handshake latency at p90.
What Actually Changed On The Wire
The problem is structural, not a bug. Cloudflare acts as a reverse proxy, so a page load is two independent TLS connections: visitor-to-Cloudflare and Cloudflare-to-origin. The second one is what AKE touches. Cloudflare is the TLS client there and must commit to a key share in the ClientHello before the origin says anything about itself.
The old default, X25519, is supported by over 95% of origins — a safe guess, but not the preferred one for a sizeable minority. Two failure modes were baked in:
- More than 6% of origins prefer P-256 or P-384 over X25519, so even purely classical handshakes paid an HRR round trip.
- Post-quantum capable origins were forced to request an upgrade via HRR, because a X25519MLKEM768 keyshare is 1,216 bytes versus X25519's 32 bytes — enough to push the ClientHello past a single network packet. Around 0.34% of scanned origins previously failed outright when handed a post-quantum keyshare first, so Cloudflare used HRR as a safety valve.
Automatic Key Exchange extends Automatic SSL/TLS and reuses its scanning pipeline. For each TLS 1.3-capable origin it runs a handful of lightweight handshakes, each offering exactly one group — X25519, P-256, P-384, P-521, or X25519MLKEM768 — then selects the strongest supported option in strict priority order: post-quantum hybrid first, classical fallback after.
The Rollout And The Guardrails
The interesting engineering here is the blast-radius control, not the crypto. Preference is assigned per subdomain, weighted by that subdomain's actual traffic volume, so a dormant host doesn't hold the busiest endpoint's key agreement hostage. The new preference then goes to a small share of traffic first, with the system watching failure and HRR rates against that origin's baseline — retries climbing above baseline triggers a rollback.
When I run anything behind a proxy with auto-negotiated parameters, that's the part I care about: a bad preference costs an extra round trip during the rollout window, not a broken TLS connection. Cloudflare rescans every origin daily, so a load-balancer swap or a TLS library upgrade that adds post-quantum support gets picked up at the next scan.
First-cohort results, from an enrolled base of "well over a million domains":
| Preference after scanning | Share of domains |
|---|---|
| X25519 (unchanged) | ~64% |
| X25519MLKEM768 (post-quantum) | ~33% |
| Other classical curve (P-384, P-256, P-521) | ~3% |
Post-quantum origin TLS 1.3 traffic grew from roughly 25 billion to 45 billion connections per day, and the share of post-quantum origin connections completing without a HelloRetryRequest rose from 0% to 99.2%. About 9,000 domains per day get a non-X25519 preference assigned.
The Setting That Can Break Your Origin
Automatic Key Exchange is on by default for existing and new domains; no action needed for most setups. It can be toggled under SSL/TLS > Overview > Configure > Origin connection & post-quantum encryption, and disabling it stops scanning and reverts to a fixed default order.
There is a new Compliance requirements setting that filters which key agreements may be used. Two options:
- Post-quantum hybrid — restricts negotiation exclusively to X25519MLKEM768, removing classical algorithms entirely.
- FIPS — restricts negotiation exclusively to FIPS-compliant key agreements.
Read the source's warning carefully before touching either: enforcing post-quantum hybrid on an origin that lacks X25519MLKEM768 support leaves no mutually supported algorithm, causing all TLS 1.3 connections to fail. These options narrow what Cloudflare may negotiate; they do not add capability to your origin. Unless you have a policy obligation, leave both unselected.
If your origin isn't post-quantum ready yet, AKE still helps — it finds the classical curve your origin actually prefers and avoids the HRR there too. Today only about 12% of individual origins on Cloudflare's network support post-quantum key exchange. Two upgrade paths from the source: put the origin behind Cloudflare Tunnel (cloudflared-to-Cloudflare already uses post-quantum key agreement), or upgrade the TLS endpoint — and audit the load balancers, WAF appliances and middleboxes in between, because manually configured allowed-curves lists can override the new defaults that BoringSSL, OpenSSL and rustls now ship.
What I'd Check Before Trusting It
One caveat worth naming, and one an HN commenter already raised: the 52% → 3.7% number is a saved possible round trip, and Cloudflare doesn't publish the added lookup latency now incurred on every connection to fetch the per-origin preference. The company's counter-argument — that this sits in the same record lookup already needed to resolve an origin — is plausible but unmeasured in the post.
For the practical check, Cloudflare Radar takes a hostname or IP and reports whether the server supports post-quantum TLS key exchange, including implementation-bug detection that characterises failures from middleboxes dropping multi-packet ClientHellos. AKE will not switch a domain whose origin fails those checks.
What's not shipped yet: per-origin (rather than domain-level) preference granularity, an on-demand rescan trigger from the dashboard or API, and automatic post-quantum origin authentication — key agreement protects today's traffic from harvest-now-decrypt-later, but does nothing about a forged certificate on Q-Day.
Sources: