Cloudflare AKE: Reducing Origin HelloRetryRequests from 52% to 3.7%

Automatic Key Exchange (AKE) is delivering faster, post-quantum secure handshakes for over 45 billion daily connections.

By Suleman Ahmad, Yawar Jamal, and Alex Krivit | September 8, 2026

---

The TLS 1.3 Guessing Game

Whenever Cloudflare establishes a new TLS 1.3 connection to an origin server, it faces a dilemma. The protocol mandates that the client commit to a specific key agreement algorithm in the very first packet sent—before the origin server has provided any information regarding its own capabilities or preferences.

The outcome depends entirely on the accuracy of this guess:

1. Correct Guess: The handshake finishes in a single round trip.
2. Incorrect Guess: The origin responds with a HelloRetryRequest (HRR), forcing the process to restart and doubling the connection cost to two round trips.

For a long time, Cloudflare utilized a static guess for every single origin on the web: X25519. While this algorithm is widely compatible, our measurements revealed it was optimal for everyone suboptimal for approximately 30% of origin connections.

Introducing Automatic Key Exchange (AKE)

We are now debuting Automatic Key Exchange, an evolution of our Automatic SSL/TLS suite. Instead of relying on a static guess, AKE utilizes empirical measurement.

Cloudflare now probes each origin to determine its supported and preferred key agreement algorithms. We then lead with that specific algorithm during the initial attempt, prioritizing the post-quantum hybrid X25519MLKEM768 whenever the origin is capable of handling it.

The Impact at a Glance

---

The Urgency of Post-Quantum Security

While reducing latency by milliseconds is a win for performance, the security implications are far more critical. We are currently facing a specific cryptographic threat:

Harvest-Now, Decrypt-Later: An adversary records encrypted traffic today, even if they cannot read it, betting that future quantum computers will allow them to decrypt it retrospectively.

Cloudflare has set a goal to make the internet quantum-secure by 2029, the estimated window when classical encryption may become vulnerable. To achieve this, we cannot expect millions of independent site operators to become experts in cryptography.

Our Roadmap for Quantum Security:

• Advertise PQ support to origins.
• Implement Automatic Key Exchange (AKE).
• Achieve universal PQ-secure origin handshakes by 2029.

Previously, enabling post-quantum connections required manual intervention: either adjusting settings in the Cloudflare dashboard or configuring the origin server to mandate them. AKE removes this friction.

---

Deep Dive: The TLS 1.3 Handshake

To understand AKE, one must understand the mechanics of the TLS handshake, which authenticates the server and establishes a shared secret. Because Cloudflare acts as a reverse proxy, a single user request actually involves two distinct secure connections:

1. Visitor $\rightarrow$ Cloudflare
2. Cloudflare $\rightarrow$ Origin Server

Each of these is an independent session with its own keys and identity verification. When connecting to the origin, Cloudflare acts as the TLS client.

Handshake Logic Flow

In the "happy path," TLS 1.3 is significantly faster than TLS 1.2 because of this predictive key exchange. However, if the origin prefers a different algorithm, the HelloRetryRequest acts like missing a shortcut in Mario Kart—you still finish the race, but you've lost valuable time.

Regardless of the path, the process concludes when the server generates a shared key using the client keyshare and returns a server keyshare. This shared key then protects the session via symmetric encryption (e.g., AES).

---

The Technical Trade-off: Size vs. Compatibility

For years, we stuck with X25519 because it was safe. Since September 2023, we began advertising post-quantum support (initially as X25519Kyber768Draft00 and now as the standardized X25519MLKEM768).

However, there is a massive difference in data size:

• Classical X25519 keyshare: $32\text{ bytes}$
• PQ Hybrid X25519MLKEM768 keyshare: $1,216\text{ bytes}$

This increase in size often pushes the ClientHello message beyond the limit of a single network packet. This creates a risk: some legacy origin servers or "middleboxes" (network appliances) crash or fail when they receive a ClientHello split across multiple packets.

The Risk Assessment

In a previous study, we found that:

• 0.34% of scanned origins failed the handshake when receiving a PQ keyshare first.
• The vast majority still relied on classical X25519.

To avoid breaking the internet for that 0.34%, we used the HelloRetryRequest as a safety valve. We would advertise that we could do post-quantum, but we would only send the classical X25519 keyshare initially.

# Conceptual logic for the old "Safe Guess" approach
if connection_initiated:
    send_client_hello(
        supported_algorithms=["X25519", "X25519MLKEM768"],
        initial_keyshare="X25519" # The "Safe Guess"
    )

By moving to Automatic Key Exchange, we replace this static safety with dynamic intelligence, ensuring the fastest and most secure connection possible without sacrificing stability.