Post-quantum TLS explained: what X25519MLKEM768 means for your website
Most of what keeps a TLS connection private rests on two pieces of public-key cryptography: the key exchange that agrees on a session key, and the certificate signature that proves who the server is. Both rely on math (elliptic curves, RSA) that a large enough quantum computer could break with Shor's algorithm.
Nobody has that machine yet. So why are browsers, CDNs and TLS libraries already switching? Because of one attack that works today.
Harvest now, decrypt later
An attacker who can record encrypted traffic, such as a state actor on a backbone link or anyone with access to a compromised network, can simply store it. If the key exchange can be broken later, every recorded session can be decrypted later, including passwords, health data, trade secrets and private messages.
Data that must stay confidential for 10 years or more is already exposed if it travels over classical-only TLS today. That is why key exchange is the urgent part. Certificate signatures only matter at the moment of the connection: a signature forged in 2035 can't impersonate a server in 2026.
ML-KEM and the hybrid approach
In August 2024 NIST published FIPS 203, standardizing ML-KEM (formerly CRYSTALS-Kyber), a key-encapsulation mechanism built on lattice problems that are believed to resist quantum attacks.
TLS doesn't use ML-KEM alone. The deployed scheme is a hybrid: X25519MLKEM768 runs the classic X25519 elliptic-curve exchange and ML-KEM-768 side by side and combines both secrets. An attacker has to break both. If a flaw is ever found in the new algorithm, the connection is still as strong as today's X25519.
The cost is size, not speed: the client's key share grows from 32 bytes to about 1.2 KB. Handshakes stay fast, but the larger ClientHello occasionally trips up old middleboxes that assume it fits in one packet.
Who supports it
- Browsers: current Chrome, Edge and Firefox offer X25519MLKEM768 by default, and Apple has added it to its recent OS releases. A large share of real browser traffic already sends a post-quantum key share.
- CDNs: Cloudflare negotiates it with browsers for every site behind its proxy, at no cost. If your site is proxied by Cloudflare, visitors are most likely already protected at the edge.
- Servers and libraries: OpenSSL 3.5 and later, BoringSSL, Go 1.24+ and recent rustls versions support it. Older OpenSSL 3.0/3.2 builds, which many Linux distributions still ship, do not.
How to enable it
For a site that terminates TLS itself (nginx, Apache, HAProxy and so on):
- Upgrade the TLS library to one that supports ML-KEM, for example OpenSSL 3.5+.
- Make sure TLS 1.3 is enabled, because hybrid key exchange is TLS 1.3 only.
- If you set the key exchange groups explicitly, put the hybrid group first, e.g. in nginx:
If you don't set them, OpenSSL 3.5 already prefers the hybrid group by default.ssl_protocols TLSv1.2 TLSv1.3; ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1; - Test it. sslverify.net offers only X25519MLKEM768 in a dedicated handshake and reports whether the server accepts it.
Behind Cloudflare, remember there are two legs: browser → Cloudflare is already post-quantum, while Cloudflare → your origin is only post-quantum if your origin server supports it too.
What about certificates?
Post-quantum signatures (ML-DSA, FIPS 204) exist, but the certificate ecosystem (CAs, browsers, Certificate Transparency) hasn't moved to them yet, and the signatures are much larger. For now, the practical step is the key exchange. Plan your certificate migration, but don't wait on it to protect traffic today.
Checklist
- TLS 1.3 enabled, TLS 1.0/1.1 disabled
- X25519MLKEM768 accepted by every public endpoint, including APIs and mail servers
- Origin servers behind a CDN upgraded as well
- An inventory of where long-lived sensitive data travels