Cloudflare Automatic Key Exchange

A TLS 1.3 client proposes a key share before the server has described its preference. If the server cannot use that first choice, it returns a HelloRetryRequest and the client sends another ClientHello. The connection still succeeds, but the extra exchange delays the first request that needs a new origin connection.

Cloudflare reports that its initial deployment reduced HelloRetryRequests from roughly 52 per cent to 3.7 per cent and removed more than 150 milliseconds from the 90th-percentile handshake in the measured traffic. Those figures describe Cloudflare's rollout, not a guaranteed improvement for every application. Sites that reuse established connections extensively, sit close to their origins or already agree on the first key share may see a smaller effect.

The most useful interpretation is operational. Edge performance does not stop at the CDN. Certificate validation, protocol support, connection reuse and the distance to each origin all contribute to the route that carries a request into the application. A faster negotiation is valuable, but it does not compensate for an unhealthy origin or slow application work after the handshake.

Automatic Key Exchange applies when a Cloudflare zone uses Full, Full (strict) or Strict SSL mode, the origin negotiates TLS 1.3 and the connection does not use Cloudflare Tunnel. It affects new TLS connections only. Requests that reuse an existing connection do not perform a fresh key exchange.

The preference is selected for the zone rather than one hostname or server. It also applies to outbound origin connections created by Workers fetch requests. When a zone has several active origins, Cloudflare derives one preference from traffic-weighted probe results. Teams with mixed server generations or different TLS libraries should therefore confirm that the selected behaviour remains compatible across the complete origin pool.

When both classical and post-quantum agreements are available, Cloudflare prefers the standardised hybrid X25519MLKEM768 agreement unless a compliance requirement excludes it. That does not remove the need for certificate validation or sound origin access controls. Key agreement, certificate trust and network reachability solve different parts of the connection.

Start with a current inventory of origin endpoints, TLS versions, certificates and termination layers. Record whether the connection ends at a load balancer, reverse proxy or application server. A probe against one public hostname cannot prove that every internal origin uses the same library, policy or certificate chain.

Watch connection errors, handshake latency and origin availability while the preference changes. Cloudflare stages its own rollout from a small share of traffic and rolls back an unhealthy selection, but application teams should still correlate edge errors with load balancer and origin logs. The absence of browser errors is not enough because visitors terminate TLS at Cloudflare rather than at the origin.

Use compliance controls cautiously. Requiring hybrid post-quantum exchange can prevent an origin connection when the server does not support an allowed agreement. Unless policy demands a restricted set, Cloudflare recommends allowing automatic selection to choose from the agreements both sides support. Test policy changes against every origin group before treating them as production defaults.