Removing the guesswork from TLS 1.3 key exchange
Opening a TLS 1.3 connection to an origin server forces the client to commit to a key agreement algorithm before the server reveals what it supports. The right guess yields a one-round-trip handshake; the wrong one triggers a HelloRetryRequest and forces the connection to start over at the cost of an extra round trip.
Cloudflare historically defaulted to X25519 as its initial keyshare for every origin connection. It was a safe bet — over 95% of origins support it — but it was also suboptimal for a meaningful share of traffic. New measurements show that roughly 30% of origin connections would have been faster with a different choice. The company is now rolling out Automatic Key Exchange to replace that guess with per-origin telemetry.
Under the new scheme, Cloudflare probes each origin to learn which key agreement algorithms it actually supports and prefers, then leads with that algorithm on the first ClientHello. Where the origin can handle it, the preference is X25519MLKEM768, the post-quantum hybrid. Early rollout data shows HelloRetryRequest rates on origin connections dropping from roughly 52% to 3.7%, cutting more than 150 ms off handshake latency at the p90 mark. Hundreds of thousands of domains now negotiate post-quantum origin connections without any manual configuration, and that count is growing daily.
The latency win matters, but the security rationale is the longer-term driver. Adversaries can record encrypted traffic today and decrypt it later once quantum computers break classical key exchange — the "harvest now, decrypt later" threat. Cloudflare's stated goal is quantum-secure connections by 2029, the year some estimates put on the arrival of a practical quantum break. Meeting that deadline cannot depend on every site operator manually enabling post-quantum settings on their origin stack. Until now, preferring post-quantum to origins required either turning it on from Cloudflare's side or having the origin insist on it.
The two-step handshake problem
Cloudflare operates as a reverse proxy, so what looks like a single secure connection is actually two: one between visitor and Cloudflare, and a second between Cloudflare and the origin. Each runs its own handshake with independent keys. Automatic Key Exchange targets the second leg, where Cloudflare acts as the TLS client. That leg begins with a ClientHello that carries the hostname and a list of supported key agreement algorithms.
In the best case, TLS 1.3 completes a new connection in a single round trip. The client sends a ClientHello with its supported algorithms plus one or more client keyshares, and the server accepts one. If the server prefers something different, it answers with a HelloRetryRequest; the client sends a second ClientHello with a fresh keyshare for the requested group, and the handshake costs an extra round trip before any content can be fetched.
The keyshare itself is the seed for the shared secret. The origin derives the shared key from the client keyshare, returns its own server keyshare, and the client computes the same key to protect the session with symmetric cryptography such as AES.
The cost of a conservative keyshare
Defaulting every TLS 1.3 origin connection to an X25519 keyshare was operationally cautious for two reasons. First, the vast majority of origins understand it. Second, an X25519MLKEM768 keyshare is 1,216 bytes versus X25519's 32 bytes, which pushes the ClientHello past the size of a single network packet. The TLS standard permits multi-packet segments, but some legacy middleboxes and origin servers fail when a ClientHello is split. In an earlier Cloudflare study, approximately 0.34% of scanned origins failed the TLS handshake outright when presented with a post-quantum keyshare first.
That conservative default had real costs. Cloudflare has advertised support for post-quantum key agreement to origins since September 2023, first as X25519Kyber768Draft00 and now as the standardized X25519MLKEM768. But advertising support is not the same as leading with a keyshare. With X25519 as the initial keyshare, post-quantum-capable origins that wanted the hybrid had to request it via a HelloRetryRequest. Modern builds of OpenSSL, BoringSSL, and rustls handle a classical X25519 keyshare differently — some accept it unless explicitly configured to prefer post-quantum, while newer builds immediately issue a HelloRetryRequest to force the hybrid exchange. Meanwhile, over 6% of origins prefer P-256 or P-384 over X25519 even on purely classical connections, which meant an unnecessary retry round trip for them as well.
Measuring instead of guessing
Automatic Key Exchange builds on the same scanning infrastructure that powers Automatic SSL/TLS. Rather than infer an origin's capabilities from its TLS library or operator documentation, Cloudflare measures them directly with lightweight active probes outside the production traffic path.
The process works in five stages:
- For each TLS 1.3-capable origin, Cloudflare runs a small series of handshakes, each offering exactly one key agreement group: X25519, P-256, P-384, P-521, or X25519MLKEM768. The responses map the origin's full algorithm set and confirm both the server and the intervening network can handle stronger key agreement before real traffic depends on it.
- Domains often front multiple subdomains that resolve to different origins with different capabilities. Each subdomain is evaluated independently, weighted by its actual HTTP traffic volume. A domain-wide preference therefore reflects where traffic actually flows rather than treating a dormant subdomain as equal to the busiest endpoints.
- From the groups an origin supports, the strongest is selected by strict priority: post-quantum hybrids come first, falling back to the fastest classical algorithm accepted — X25519, then P-256, P-384, or P-521.
- The new preference is rolled out gradually, starting with a small share of that origin's traffic. Failure and
HelloRetryRequestrates are monitored against the origin's baseline; if retries climb, the change is rolled back. The worst case of a bad preference during the rollout phase is one extra round trip — not a broken TLS connection. - Origins change: a load balancer moves, a TLS library adds post-quantum support, an operator disables an older curve. Cloudflare rescan every origin daily, so a server that gains post-quantum support — or drops the curve currently in use — receives an updated preference at the next scan.
For the vast majority of customers, there is no configuration step. If the origin speaks TLS 1.3, Cloudflare will automatically negotiate the strongest key exchange it supports. An origin that handles X25519MLKEM768 gets a post-quantum connection on the first try, with no additional round trip and no human intervention.
Managing Automatic Key Exchange
Automatic Key Exchange is enabled by default for all domains, new and existing, so most setups need no manual intervention. Administrators who want finer control can manage the feature independently in the Cloudflare dashboard under SSL/TLS > Overview > Configure > Origin connection & post-quantum encryption.
With the toggle on, Cloudflare scans origins out-of-band and leads with a dynamically selected keyshare. Disabling it stops the scans and reverts Cloudflare to a fixed, static default key agreement order.
A new Compliance requirements setting lets you filter which key agreements Cloudflare may use for origin connections. When configured, Automatic Key Exchange and all origin-facing traffic strictly follow these rules:
- Post-quantum hybrid: Restricts negotiation exclusively to hybrid post-quantum key agreements (X25519MLKEM768), removing classical algorithms entirely. All successful origin TLS 1.3 connections are then guaranteed post-quantum secure.
- Federal Information Processing Standards (FIPS): Restricts negotiation exclusively to FIPS-compliant key agreements.
Selecting both options requires an algorithm that satisfies both criteria; if no overlapping key agreement exists, the configuration is rejected. These settings express intent rather than pinning specific algorithms, so configurations stay current as compliance standards evolve or new post-quantum algorithms emerge.
These requirements deserve careful consideration. They do not grant an origin new cryptographic capabilities — they only narrow what Cloudflare can negotiate. Enforcing post-quantum hybrid on an origin lacking X25519MLKEM768 support leaves no mutually supported algorithm, causing all TLS 1.3 connections to fail. Unless a strict policy obligation demands enforcement across every connection, leaving both options unselected lets Automatic Key Exchange negotiate optimal algorithms safely.
Rollout results and measured impact
Automatic Key Exchange applies to domains whose origins speak TLS 1.3, since predicting preferred key agreement is a TLS 1.3-only feature. The scanning pipeline has already assigned key exchange preferences to well over a million domains, with enrollment continuing across the network.
From that initial cohort, roughly 64% retained classical X25519 as their preference, so nothing changed for their connections. Around 33% now prefer X25519MLKEM768, protecting traffic from harvest-now, decrypt-later quantum attacks in a single round trip. The remaining 3% selected a different classical curve — such as P-384, P-256, or P-521 — preferred by their origin.
Approximately 9,000 domains each day have their key agreement preference set to something other than X25519. Nearly all of these move directly to post-quantum key exchange; the remainder adopt other classical curves their origin's TLS configuration supports better.
Before Automatic Key Exchange, almost every post-quantum origin handshake required a HelloRetryRequest (HRR) because the static initial guess defaulted to classical X25519. That forced a mandatory second round trip before completing the TLS handshake.
That latency penalty is now virtually gone for almost all post-quantum capable origins: 99.2% of post-quantum TLS 1.3 connections in the currently scanned cohort complete in a single round trip. Post-quantum origin traffic across that cohort has grown from roughly 25 billion to 45 billion connections per day, driven significantly by Automatic Key Exchange upgrading classical connections to a post-quantum preference.
Many origins support multiple key agreement algorithms without preferring one. An origin that supports post-quantum key agreement may still accept a classical X25519 keyshare without rejecting it or issuing an HRR, so passive observation cannot reveal full capabilities. Active probing uncovered thousands of origins whose post-quantum support never appeared in their traffic.
Once the scanner discovered such origins and updated their client keyshare preference, post-quantum connections quickly accounted for the vast majority of traffic to those domains. The remaining classical share comes primarily from multi-origin setups mixing post-quantum and classical-only backends.
Automatic Key Exchange also pairs origins with their preferred classical curve other than X25519, reducing overall HRR rates across all scanned origins.
Before rollout, roughly 52% of origin connections for scanned domains required an HRR. That rate dropped to 3.7%. Avoiding an HRR removes an entire round trip from TLS connection setup, reducing p90 latency more than 150 ms for scanned origins. This particularly benefits dynamic requests and CDN cache misses requiring a fresh TLS 1.3 connection to the origin. Requests over existing keep-alive connections need no new handshake and are unaffected.
Verifying post-quantum capability
Several tools can check whether a server supports post-quantum key agreement. Cloudflare Radar offers one; entering a hostname or IP address checks for post-quantum TLS key exchange support. Note that for a hostname proxied by Cloudflare, the check tests the connection to Cloudflare rather than the origin behind it.
Beyond algorithm support, the tool now detects post-quantum TLS implementation bugs. If the result is negative, it characterizes the likely failure reason. Common causes include legacy middleboxes, firewalls, or server buffers dropping multi-packet payloads or failing to reassemble a ClientHello split across TCP segments. Some origins give up on an unrecognized keyshare instead of sending a HelloRetryRequest as TLS 1.3 requires, or send one and then cannot complete the handshake.
Radar shows whether the network path handles post-quantum traffic cleanly. Automatic Key Exchange will not switch a domain whose origin fails these checks, so passing them is what enables the upgrade.
When your origin lacks post-quantum support
Origins not yet supporting post-quantum encryption still benefit from enabling Automatic Key Exchange. The scanner discovers what the origin actually supports. If X25519MLKEM768 is unavailable, Cloudflare continues using a compatible classical key agreement and avoids unnecessary HelloRetryRequest round trips by learning the origin's preferred method.
Automatic Key Exchange can only prefer post-quantum connections when the origin server already supports the algorithm. Today, over 12% of individual origins across Cloudflare's network support post-quantum encryption. Support in TLS server implementations is growing as recent versions of BoringSSL, OpenSSL, and rustls include it. Enterprise origin stacks, cloud load balancers, and embedded TLS terminators are upgrading on their own timelines.
Two options exist for adding post-quantum protection to origin-facing connections:
- Use Cloudflare Tunnel. The connection between cloudflared and Cloudflare already uses post-quantum key agreement. This is the simplest option when the TLS software on a public origin endpoint cannot be changed.
- Upgrade the TLS endpoint. Many current frameworks and TLS libraries enable X25519MLKEM768 by default. But manually configured allowed curves from earlier setups may override these new defaults. Audit every device terminating or inspecting TLS — load balancers, WAF appliances, and other middleboxes — to confirm X25519MLKEM768 is enabled everywhere between the origin and Cloudflare. On managed hosting, ask the provider whether it supports X25519MLKEM768.
See the documentation on post-quantum cryptography between Cloudflare and your origin for supported software, configuration examples, and verification steps.
Roadmap: finer-grained control and PQ authentication
Automatic Key Exchange is one step in a longer initiative, not the finish line. Three areas are in active development.
Per-origin settings
Today, Automatic SSL/TLS makes decisions at the domain level, which means one origin server's behavior can limit the whole domain. Work is underway to move to per-subdomain and per-origin granularity, so key agreement and SSL/TLS encryption modes can differ across the multiple origins serving a single domain.
On-demand rescanning
If you upgrade your origin's TLS stack, you currently have to wait for the next scheduled Automatic SSL/TLS scan to pick up the change. The scan frequency is intentionally balanced: frequent enough to track origin changes, but not so aggressive that it burdens origins that return the same security posture. An on-demand rescan option is being built for both the dashboard and API, letting you move to stronger key agreement immediately after an upgrade. The same tool will double as a diagnostic, reporting which key agreements your origin can negotiate and characterizing the reason for any failures, similar to the external Cloudflare Radar scanning tool.
Automatic post-quantum origin authentication
Post-quantum key agreement protects today's traffic from future decryption, but it does nothing against an attacker using a quantum computer to forge a certificate and impersonate your origin. Closing that gap requires post-quantum authentication. Earlier this year, Authenticated Origin Pulls and Custom Origin Trust Store added support for ML-DSA certificates, covering origin connections.
The remaining problem is downgrades. An origin may serve both a classical RSA/ECDSA certificate and a post-quantum ML-DSA certificate to keep legacy clients working. On Q-Day, an active adversary between Cloudflare and the origin could strip the post-quantum offer from the handshake. Cloudflare, seeing only a classical response, would fall back to validating the RSA/ECDSA certificate — which the attacker could forge with a quantum computer.
Preventing this downgrade in the broader WebPKI is complicated. One proposed path has Certificate Authorities adding a post-quantum signature to classical certificates, proving a legacy server genuinely lacks PQ support. That is a likely direction for the public web, but it takes time and coordination. A faster route, where feasible, is to stop trusting classical certificates entirely.
For origin connections, that route is available. The plan is to extend Automatic SSL/TLS scanning to detect origin support for post-quantum authentication — ML-DSA certificates now, and Merkle Tree Certificates later. Once the scanner identifies such an origin, Cloudflare can automatically disable classical fallback for customers who want strict post-quantum protection, eliminating downgrade risk without disrupting un-upgraded endpoints.
Checking your origin's status
The SSL/TLS section of your Cloudflare dashboard shows your current origin encryption level. Cloudflare Radar can verify your origin's post-quantum readiness and indicate whether server stack updates are needed. If your origin already supports post-quantum, Automatic Key Exchange will detect it and ensure Cloudflare connects faster and more securely.
