Skip to content

CLOUDFLARE 2026-09-08

Read original ↗

Cloudflare — Automatic Key Exchange: faster, post-quantum secure origin handshakes for 45 billion daily connections

Summary

Cloudflare, as a reverse proxy, opens a second TLS 1.3 connection to each customer's origin. TLS 1.3's speed comes from a predictive key exchange: the client must commit to a key-agreement algorithm and send a keyshare in the very first ClientHello, before learning what the server supports. Guess right → one round trip; guess wrong → the origin sends a HelloRetryRequest (HRR) and the handshake costs two round trips. For years Cloudflare's guess was a static classical X25519 keyshare for every origin — safe (>95% of origins support X25519) but suboptimal for ~30% of connections, and it forced every post-quantum-capable origin through an HRR because the first keyshare was classical. Automatic Key Exchange replaces the guess with a measurement: Cloudflare actively probes each origin out-of-band (one lightweight handshake per candidate group), weights results per subdomain by traffic volume, picks the strongest supported group (preferring the post-quantum hybrid X25519MLKEM768), rolls the new preference out to a small traffic slice with HRR-rate monitoring and automatic rollback, and rescans every origin daily. Result: HRR rate on scanned origins fell from ~52% to 3.7%, cutting >150 ms off p90 handshake latency; post-quantum origin handshakes completing in one round trip rose from 0% to 99.2%; post-quantum origin traffic grew from ~25B to 45B connections/ day — with post-quantum protection now default-on and requiring no customer configuration.

Key takeaways

  1. TLS 1.3's predictive key exchange is a guess that costs a round trip when wrong. The client commits to a key-agreement group + sends a keyshare in the first ClientHello; a mismatch triggers a HelloRetryRequest and a second ClientHello with the corrected keyshare — a full extra round trip. This 1-RTT-on-correct-guess design is a large part of why TLS 1.3 is faster than TLS 1.2. (Source: sources/2026-09-08-cloudflare-automatic-key-exchange-faster-post-quantum-secure-origin-han)

  2. The static-X25519 default was safe but doubly wasteful. >95% of origins support X25519, so a wrong guess never broke a connection — but ~30% of origins preferred something else. Over 6% of origins prefer P-256 or P-384, eating an HRR even for purely classical connections; and every post-quantum-capable origin ate an HRR because the initial keyshare was classical while PQ was only advertised, not led with.

  3. Leading with a PQ keyshare directly was blocked by a packet-size cliff. An X25519MLKEM768 keyshare is 1,216 bytes vs X25519's 32 bytes, pushing the ClientHello past a single network packet. ~0.34% of origins (legacy middleboxes, buffers) fail when a ClientHello is split across packets — so Cloudflare couldn't just always lead with PQ. HRR was used as a safety valve instead.

  4. Automatic Key Exchange = active out-of-band probing, not passive inference. For each TLS 1.3 origin, Cloudflare runs a few lightweight handshakes each offering exactly one group (X25519, P-256, P-384, P-521, X25519MLKEM768). Because probing is off the production traffic path, it confirms the origin and the network between can handle the stronger group before real traffic depends on it. Passive observation cannot reveal an origin's full capability — many origins accept X25519 without advertising a preference for PQ, so active probing surfaced "thousands of origins whose post-quantum support never appeared in their origin traffic."

  5. Per-subdomain, traffic-weighted preference. One domain fronts many subdomains resolving to different origins; each is evaluated independently and weighted by actual HTTP traffic volume, so the busy www/api endpoints dominate the domain-wide preference rather than a dormant subdomain.

  6. Strict priority order + monitored progressive rollout + daily rescan. Selection order: X25519MLKEM768 first, then fastest accepted classical (X25519 → P-256 → P-384 → P-521). New preference ships to a small traffic share first while HRR/failure rate is watched; if retries climb above the origin's baseline it rolls back — worst case is one extra round trip, never a broken connection. Every origin is rescanned daily to catch stacks that add or drop PQ support.

  7. Headline production numbers. HRR on scanned origins 52% → 3.7%; >150 ms off p90 handshake latency; PQ origin handshakes in a single round trip 0% → 99.2%; PQ origin traffic ~25B → 45B connections/day; preference assigned to well over a million domains so far (~9,000 more domains/day move off X25519, nearly all to PQ). Of the first cohort: 64% stayed on X25519 (no change), 33% now prefer X25519MLKEM768, 3% a different classical curve.

  8. Intent-based compliance settings, not algorithm lists. A new Compliance requirements control lets customers restrict negotiation to Post-quantum hybrid (X25519MLKEM768 only — guarantees every successful TLS 1.3 origin connection is PQ-secure) and/or FIPS (FIPS-compliant groups only). You configure intent; the algorithm set stays current as standards evolve. Caveat: enforcing PQ-hybrid on an origin lacking X25519MLKEM768 leaves no mutual algorithm → all TLS 1.3 connections fail.

  9. This is the encryption half; authentication is next. PQ key agreement defeats harvest-now-decrypt-later but does nothing against a post-Q-Day attacker forging a certificate. Roadmap: extend Automatic SSL/TLS scanning to detect PQ authentication support (ML-DSA certs, later Merkle Tree Certificates) and auto-disable classical fallback for origins that support PQ auth, closing the downgrade gap. Also planned: per-subdomain/per-origin preference granularity, and on-demand rescans from the dashboard/API.

Systems / concepts / patterns extracted

  • System — Automatic Key Exchange: the named product; extension of Automatic SSL/TLS that scans origins out-of-band and leads with a dynamically selected per-origin keyshare. Default-on for all domains.
  • System — Automatic SSL/TLS: the parent product (in public since 2024) that manages origin encryption mode and owns the origin-scanning pipeline Automatic Key Exchange reuses.
  • Concept — TLS 1.3 predictive key exchange: committing to a key-agreement group + keyshare in the first ClientHello for 1-RTT setup; wrong guess → HRR → 2 RTT.
  • Concept — HelloRetryRequest (HRR): the server message that rejects the offered keyshares and forces a second ClientHello, adding a round trip.
  • Pattern — Measure, don't guess (out-of-band active probing): replace a static per-target guess with a direct out-of-band measurement of each target's real capability, off the production path, then act on the measurement.
  • Reinforces hybrid KEM, default-on security upgrade, TLS-first PQC rollout, monitored progressive cutover with rollback, and protocol algorithm negotiation.

Operational numbers

Metric Value
HRR rate on scanned origins (before → after) ~52% → 3.7%
p90 handshake latency reduction > 150 ms
PQ origin handshakes completing in 1 RTT (before → after) 0% → 99.2%
PQ origin traffic growth ~25B → 45B connections/day
Domains with preference assigned so far > 1 million (≈9,000 more/day off X25519)
First-cohort split 64% stayed X25519 · 33% → X25519MLKEM768 · 3% other classical curve
X25519 keyshare size 32 bytes
X25519MLKEM768 keyshare size 1,216 bytes
Origins failing a split (multi-packet) ClientHello ~0.34%
Origins supporting X25519 >95%
Origins preferring P-256/P-384 over X25519 >6%
Individual origins supporting PQ key agreement (2023 → now) 0.5% → 12.8%
Selection priority X25519MLKEM768 → X25519 → P-256 → P-384 → P-521
Rescan cadence daily
Q-Day target for full PQ security 2029

Caveats

  • Automatic Key Exchange only helps origins that speak TLS 1.3 — predictive keyshare selection is a TLS-1.3-only feature.
  • It cannot grant an origin new crypto capability; it only leads with the best the origin already supports. If the origin has no PQ support, it just picks the best classical curve and still removes needless HRRs.
  • The Post-quantum hybrid compliance option is a footgun on non-PQ origins: no mutual algorithm → all TLS 1.3 connections fail. Cloudflare advises leaving both compliance options unset unless there's a hard policy mandate.
  • Only affects the Cloudflare → origin hop. Requests over existing keep-alive connections need no new handshake and are unaffected.
  • Encryption only — does not address post-Q-Day certificate forgery / downgrade; that's the separate PQ-authentication workstream.

Source

Last updated · 766 distilled / 2,225 read