# Automatic Key Exchange: How Cloudflare Is Making Post-Quantum TLS Handshakes Fast and Effortless
## The Problem of Guessing in TLS 1.3
Every secure connection between a user and a website involves a TLS handshake — a carefully orchestrated exchange that authenticates the server and establishes a shared encryption key. When Cloudflare acts as a reverse proxy, what looks like a single connection is actually two: one between the visitor and Cloudflare, and a second between Cloudflare and the origin server. The origin-facing leg presents a unique challenge.
TLS 1.3 requires the client (in this case, Cloudflare) to commit to a key agreement algorithm in the very first packet of the handshake, before the server has had a chance to reveal what it supports. This predictive design is what makes TLS 1.3 faster than its predecessor — if the guess is correct, the handshake completes in a single network round trip. If the guess is wrong, the server sends a HelloRetryRequest, the client retries with the correct algorithm, and the connection costs two round trips instead of one.
For years, Cloudflare used the same safe bet for every origin connection on the Internet: X25519, a widely supported classical key agreement algorithm. This was reliable, but it turned out to be suboptimal for a significant portion of connections — roughly 30% of origin connections measured in recent analysis. Worse still, X25519 offers no protection against future quantum computers.
## Enter Automatic Key Exchange
Automatic Key Exchange represents a fundamental shift in how Cloudflare approaches origin connections. Rather than guessing which key agreement algorithm to use, the system actively probes each origin server to determine its capabilities and preferences — then leads with the best option on the very first try.
The extension builds on Cloudflare’s existing Automatic SSL/TLS infrastructure, which already handles encryption mode negotiation for origin connections. With this new capability, the scanning pipeline that powers Automatic SSL/TLS now also maps each origin’s key agreement support with precision.
The process works by running a series of lightweight TLS handshakes against each origin, each offering exactly one key agreement group: X25519, P-256, P-384, P-521, or the post-quantum hybrid X25519MLKEM768. These probes reveal the full set of algorithms an origin can handle, all conducted outside the production traffic path so real user connections are never affected.
Once the capabilities are mapped, Cloudflare applies a strict priority order: post-quantum hybrid key agreement takes first place, followed by the fastest classical algorithm the origin accepts. This ensures that wherever possible, connections are both quantum-safe and efficient.
## Why Post-Quantum Key Exchange Matters Now
The urgency behind post-quantum cryptography stems from a very real threat known as harvest-now, decrypt-later. Adversaries are already recording encrypted traffic today, storing it with the expectation that they will eventually be able to decrypt it once quantum computers become powerful enough to break classical encryption. Industry estimates place the arrival of such capability around 2029 — a date that has been dubbed Q-Day.
Cloudflare has publicly committed to making the Internet quantum-secure by 2029. But achieving that goal cannot depend on millions of website operators each becoming expert cryptographers. The transition has to happen automatically, silently, and at scale. Automatic Key Exchange embodies that philosophy: hundreds of thousands of domains now have post-quantum origin connections that nobody had to configure manually, and that number grows daily.
## From Risky Default to Measured Precision
Before Automatic Key Exchange, Cloudflare had a dilemma. They wanted to prefer post-quantum connections, but sending a post-quantum keyshare (X25519MLKEM768) in the ClientHello carried risk. The keyshare is 1,216 bytes compared to the 32 bytes of a classical X25519 keyshare — large enough to push the ClientHello message across multiple network packets. While the TLS standard allows this, some legacy middleboxes and origin servers fail when receiving multi-packet ClientHello messages.
The compromise was to advertise post-quantum support but only use it after a HelloRetryRequest triggered a retry. This kept connections safe but forced every post-quantum-capable origin to pay an extra round trip latency penalty. Even for purely classical connections, over 6% of origins prefer P-256 or P-384 over X25519, meaning the static guess caused unnecessary retries for those as well.
Automatic Key Exchange eliminates this waste. By measuring capabilities directly instead of inferring them, Cloudflare can now lead with X25519MLKEM768 for origins that support it, and fall back gracefully for those that do not.
## Rolling Out Safely
The rollout follows a careful, monitored process. New key agreement preferences are first applied to a small share of an origin’s traffic. The system then monitors failure rates and HelloRetryRequest rates in real time. If retries climb above the origin’s baseline, the change is automatically rolled back — the same mechanism that powers Automatic SSL/TLS’s encryption mode upgrades. At worst, a bad preference costs an extra round trip during the rollout phase; it never breaks a TLS connection.
Because origin configurations change over time — load balancers get replaced, TLS libraries update, operators disable older algorithms — every origin gets rescanned daily. A server that adds post-quantum support tomorrow will have its preference updated by the next scan cycle.
## The Numbers Behind the Upgrade
The results so far are striking. Across the scanned cohort of domains, HelloRetryRequests have plummeted from roughly 52% to just 3.7%. For post-quantum-capable origins specifically, 99.2% of TLS 1.3 connections now complete in a single round trip — up from zero percent when the system relied entirely on retry-based upgrades.
The latency improvement is substantial: more than 150 milliseconds cut from p90 handshake latency. This benefits dynamic requests and CDN cache misses particularly, since those often require establishing a fresh TLS connection to the origin. Requests riding on existing keep-alive connections are unaffected, as they do not need a new handshake.
Post-quantum origin traffic has surged as well, growing from approximately 25 billion connections per day to 45 billion — with a significant portion of that growth attributable to Automatic Key Exchange upgrading previously classical-only connections. Approximately 9,000 domains receive a new key agreement preference each day, with the overwhelming majority moving to post-quantum support.
Breaking down the scanned cohort: about 64% of domains remained on classical X25519 because that is what their origin preferred. Around 33% now prefer X25519MLKEM768, securing those connections against harvest-now, decrypt-later attacks in a single round trip. The remaining 3% adopted a different classical curve — such as P-384 or P-256 — that their origin explicitly prefers.
## Compliance and Control
Cloudflare has also introduced compliance requirements under Automatic Key Exchange, giving operators fine-grained control over which algorithms are permitted. A post-quantum hybrid setting restricts negotiation exclusively to X25519MLKEM768, guaranteeing that every successful TLS 1.3 connection to the origin is post-quantum secure. A Federal Information Processing Standards (FIPS) setting restricts negotiation to FIPS-compliant key agreements.
These settings are configured at the intent level rather than by specifying individual algorithms, which means they automatically stay current as new algorithms emerge or compliance standards evolve. However, they should be applied with care: enforcing post-quantum hybrid on an origin that lacks X25519MLKEM768 support will cause all TLS 1.3 connections to that origin to fail, since no mutually supported algorithm would remain.
## Configuring Automatic Key Exchange
For most customers, nothing needs to be done at all. Automatic Key Exchange is active by default for all existing and new domains, and the scanning pipeline has already assigned preferences to well over a million domains.
Operators who want more control can find the settings under SSL/TLS > Overview > Configure > Origin connection & post-quantum encryption in the Cloudflare dashboard. Disabling the toggle stops active scanning and reverts Cloudflare to a fixed, static default key agreement order.
## The Road Ahead
Automatic Key Exchange is part of a broader arc that began with Universal SSL and continues through the evolution of Automatic SSL/TLS. Several initiatives are underway:
Per-origin preference granularity is being developed so that key agreement decisions can vary across the multiple origins serving a single domain, rather than being locked to a domain-wide default. On-demand scans will allow operators to trigger immediate rescans after upgrading their TLS stack, rather than waiting for the next scheduled cycle. And automatic post-quantum origin authentication aims to prevent downgrade attacks where an adversary could strip post-quantum offers from a handshake and force a classical fallback.
The ultimate vision is clear: an Internet where every connection is quantum-secure, where that security is achieved without any manual intervention, and where the handshakes that establish those connections are as fast as the underlying technology allows.
—
## Frequently Asked Questions
**Q: What is Automatic Key Exchange?**
A: Automatic Key Exchange is a feature that extends Cloudflare’s Automatic SSL/TLS by actively probing origin servers to determine which TLS key agreement algorithms they support and prefer. It then selects the strongest compatible algorithm — prioritizing post-quantum hybrid X25519MLKEM768 — for each connection, eliminating the need to guess.
**Q: How does it differ from the previous approach?**
A: Previously, Cloudflare always sent a classical X25519 keyshare in the first packet of the TLS handshake, relying on HelloRetryRequests to upgrade to post-quantum connections when needed. Automatic Key Exchange replaces this static guess with active measurement, allowing Cloudflare to lead with the optimal algorithm on the first try for every origin.
**Q: Does this feature require any configuration on my part?**
A: No. Automatic Key Exchange is enabled by default for all domains. The scanning and preference assignment happen automatically in the background. Operators who want to enforce specific compliance requirements, such as post-quantum hybrid only or FIPS-only connections, can configure those in the dashboard.
**Q: What happens if my origin server does not support post-quantum key agreement?**
A: Automatic Key Exchange will detect that X25519MLKEM768 is not supported and fall back to the strongest classical algorithm your origin accepts. This still provides benefits by reducing unnecessary HelloRetryRequests and pairing your connection with the optimal classical curve.
**Q: How does Automatic Key Exchange handle origins that support multiple algorithms?**
A: The system uses a strict priority order: post-quantum hybrids are preferred first, followed by the fastest classical algorithm the origin accepts. This ensures maximum security without sacrificing performance where post-quantum support is available.
**Q: What are compliance requirements, and should I use them?**
A: Compliance requirements let you restrict which key agreement algorithms Cloudflare can negotiate — either post-quantum hybrid only or FIPS-compliant only. These are useful for organizations with strict regulatory obligations. However, they should be applied carefully, as enabling post-quantum hybrid on an origin that does not support X25519MLKEM768 will cause all TLS 1.3 connections to fail.
**Q: How often are origins rescanned?**
A: Every origin is rescanned daily. This ensures that as servers are upgraded, TLS libraries are updated, or configurations change, the key agreement preferences stay current.
**Q: Does Automatic Key Exchange work with all TLS versions?**
A: No. Predicting the preferred key agreement method is a TLS 1.3-only feature. Automatic Key Exchange applies only to origin connections that speak TLS 1.3.
**Q: How can I check if my origin server supports post-quantum TLS?**
A: Cloudflare offers a post-quantum readiness check through Cloudflare Radar, where you can enter your hostname or IP address to determine whether your server supports post-quantum key exchange and identify any implementation issues.
**Q: What is the expected timeline for quantum-safe Internet connections?**
A: Cloudflare has committed to making the Internet quantum-secure by 2029, which is the estimated timeframe when classical encryption algorithms could be breached by sufficiently powerful quantum computers. Automatic Key Exchange is a key part of that journey.
—
## Conclusion
Automatic Key Exchange represents a meaningful leap forward in how the Internet secures its backbone connections. By replacing blind guessing with systematic measurement, it delivers both stronger cryptographic protection and faster handshakes — simultaneously advancing the goals of quantum security and user experience. The fact that it operates entirely in the background, requiring no manual configuration from site operators, is a testament to the principle that security at scale must be automatic by design. As scanning continues to expand across millions of domains and post-quantum adoption grows daily, this feature quietly but powerfully pushes the entire Internet closer to a quantum-safe future.
Thank you for reading
