Post-Quantum TLS: Your Origin Server Is the Half Nobody Checked

Every connection through a reverse proxy is really two connections: browser to edge, and edge to origin. For two years the industry has celebrated the first leg going post-quantum, because that is the leg you can see. Chrome ships ML-KEM by default, the padlock looks the same, everyone moves on. The second leg is the one nobody at your company has ever measured, and on 8 September Cloudflare published the numbers that show how bad it is.

TL;DR

• Cloudflare’s new Automatic Key Exchange actively probes every TLS 1.3 origin behind its network, daily, to learn which key agreement algorithms it supports, then leads with the strongest one.
• HelloRetryRequests on scanned origin connections fell from roughly 52% to 3.7%, cutting more than 150ms off p90 handshake latency. Post-quantum origin handshakes completing in one round trip went from 0% to 99.2%.
• Only about 12.8% of origins behind Cloudflare support post-quantum key exchange at all. That is not a security-policy failure, it is a distribution-release failure.
• We verified it on a current box: Ubuntu 24.04 LTS ships OpenSSL 3.0.13, which cannot set X25519MLKEM768 as a group at all. ML-KEM landed in OpenSSL 3.5.0 in April 2025. Ubuntu 24.04’s standard support runs to May 2029.
• The decision is currently made per domain, not per origin, and one weak backend holds the whole zone back. The compliance toggles that enforce post-quantum can take every TLS 1.3 connection offline if your origin cannot speak it.

What Cloudflare actually shipped

TLS 1.3 is fast because it guesses. The client commits to a key agreement algorithm in the very first packet, before the server has said anything at all. Guess right and the handshake completes in one round trip. Guess wrong and the server replies with a HelloRetryRequest, the client starts again with a different keyshare, and the connection costs two round trips instead of one.

For years Cloudflare’s guess to your origin was always X25519. Over 95% of origins accept it, so it was the safe bet. Automatic Key Exchange replaces the guess with a measurement: lightweight out-of-band handshakes against each origin, each offering exactly one group (X25519, P-256, P-384, P-521 or X25519MLKEM768), weighted across subdomains by traffic volume, rescanned daily.

The results are not marginal. Across the first cohort of over a million scanned domains, HelloRetryRequests dropped from roughly 52% to 3.7% and p90 handshake latency fell by more than 150ms. Around 33% of that cohort now prefers the post-quantum hybrid X25519MLKEM768, 64% stayed on classical X25519, and 3% moved to a different classical curve. Post-quantum origin traffic grew from roughly 25 billion to 45 billion connections a day.

Note what that 3% implies. Over 6% of origins prefer P-256 or P-384 over X25519, and every one of those was paying a full extra round trip on every cache miss, for years, for no security benefit whatsoever. Nobody noticed, because passive observation cannot tell you what a server prefers. It only tells you what it will tolerate.

Why the safe guess was never actually free

The reason Cloudflare led with a classical keyshare for so long is a size problem. An X25519 keyshare is 32 bytes. An X25519MLKEM768 keyshare is 1,216 bytes, which pushes the ClientHello past a single network packet. The standard permits that, but a meaningful population of middleboxes, firewalls and origin TLS terminators cannot reassemble a ClientHello split across TCP segments and simply drop the connection. Cloudflare’s earlier study put the failure rate at around 0.34% of scanned origins.

That is a small percentage and a very large absolute number, so HelloRetryRequest became the safety valve: advertise post-quantum support, lead with something everyone accepts, and let capable origins ask for the upgrade on retry. Safe, and permanently one round trip slower. Active probing is what lets you have both, and it is the part that deserves attention: an external party now fingerprints the TLS behaviour of your infrastructure on a daily schedule and acts on the result automatically.

The ceiling is your base image, not your security policy

The number that should stop you is 12.8%: the share of origins behind Cloudflare’s network that support post-quantum key exchange at all. Automation cannot move it, because Automatic Key Exchange can only select an algorithm your origin already speaks. It measures the ceiling, it does not raise it.

So we checked the most boring possible thing: what a default server actually ships. On a current, fully patched Ubuntu 24.04.3 LTS box:

$ openssl version
OpenSSL 3.0.13 30 Jan 2024

$ openssl s_client -groups X25519MLKEM768 -connect example.com:443
Call to SSL_CONF_cmd(-groups, X25519MLKEM768) failed
error:0A080106:SSL routines:gid_cb:passed invalid argument:
group 'X25519MLKEM768' cannot be set

It is not disabled. It does not exist. ML-KEM, ML-DSA and SLH-DSA arrived in OpenSSL 3.5.0 on 8 April 2025, which is also the release that changed the default TLS keyshares to offer X25519MLKEM768 alongside X25519. Ubuntu 24.04 LTS shipped in April 2024 with 3.0.13 and, as of today, noble-updates still carries 3.0.13-0ubuntu3.15. There is no OpenSSL in noble-backports either. Ubuntu 26.04 LTS ships 3.5.5 and is post-quantum capable out of the box, but 24.04’s standard security maintenance runs to May 2029.

That date is the point. Cloudflare is explicitly racing a 2029 estimate for Q-Day. The most widely deployed Linux LTS on the internet is supported, patched and fully compliant with its own support policy right through that year, and it cannot perform a post-quantum key exchange. Your origin is not failing because someone made a bad security decision. It is failing because LTS distributions do not backport cryptographic feature work of that size, and nobody has treated a major-version OpenSSL bump as a security deliverable with a deadline attached.

The same logic applies to every managed load balancer, WAF appliance and embedded TLS terminator in the path. There is a second trap too: a hand-configured curve allow-list silently overrides the modern defaults even after you upgrade. An origin on OpenSSL 3.5 with a 2019 cipher-suite config is still a classical origin.

What the automation now decides on your behalf

Automatic Key Exchange is on by default for existing and new domains. Two consequences are worth writing into your runbook.

First, the preference is currently set per domain, not per origin. A single origin can hold an entire zone back, and Cloudflare has said per-subdomain granularity is on the roadmap rather than shipped. If your marketing site and your API resolve to different backends with different TLS stacks, the weaker one may be setting policy for both.

Second, the new compliance requirements setting lets you restrict negotiation to post-quantum hybrids only, or to FIPS-approved groups only. Cloudflare’s own documentation is blunt about the failure mode, and it is worth repeating: enforcing post-quantum hybrid against an origin that does not support X25519MLKEM768 leaves no mutually supported algorithm, and every TLS 1.3 connection to that origin fails. This is a toggle that reads like a hardening checkbox and behaves like an outage switch. Unless you have a written policy obligation, leave it alone and let the negotiation do its job.

Finally, key agreement protects confidentiality, not identity. It does nothing about an adversary who forges a certificate and impersonates your origin. That gap needs post-quantum authentication, which reached origin connections this year through ML-DSA certificate support in Authenticated Origin Pulls and Custom Origin Trust Store, and it carries its own downgrade problem if you run classical and post-quantum certificates side by side.

What to do this quarter

• Inventory by OpenSSL version, not by hostname. Run openssl version on every box that terminates or inspects TLS. Anything below 3.5 is classical-only, regardless of what your edge reports.
• Check your origin directly, not through the proxy. Cloudflare Radar’s post-quantum tool will test a hostname, but if that hostname is proxied it tests the connection to Cloudflare, not to you. Test the origin address, and use the implementation-bug detection to catch middleboxes that mangle a multi-packet ClientHello.
• Audit hand-written curve and cipher configuration. Legacy allow-lists survive upgrades and quietly cancel the new defaults.
• If you cannot upgrade the TLS endpoint, tunnel. The connection between cloudflared and Cloudflare is already post-quantum, which makes Cloudflare Tunnel the pragmatic route for appliances and managed hosting you do not control.
• Put the distribution end-of-life date on the same page as the Q-Day date. If your platform plan has Ubuntu 24.04 running until 2029, you have already decided to be classical-only until 2029. Make that an explicit decision rather than an inherited one.

We wrote about the broader post-quantum migration back in April, when the framing was still “start planning”. The Cloudflare rollout changes that framing. Somebody else is now measuring your cryptographic posture every single day and making routing decisions from the result. Being measured is not the same as being ready.

REPTILEHAUS works with teams on infrastructure security, TLS and origin architecture, and the unglamorous platform upgrades that turn out to have deadlines attached. If you are not certain what your origin negotiates, or you are staring at an LTS end-of-life date that outlives your compliance obligations, get in touch.

📷 Photo by Scott Rodgerson on Unsplash