Try Post-Quantum TLS Today: OpenSSL 3.5, Browsers and Cloudflare Test Pages
What you can actually test
The part of TLS that is already post-quantum in the real world is key agreement, the step that protects traffic from being recorded now and decrypted later (see harvest now, decrypt later). Certificates and signatures are a separate and slower migration, covered in post-quantum certificates and PKI. So when you "try post-quantum TLS today", you are testing a hybrid of classical X25519 and ML-KEM-768, usually called X25519MLKEM768. The design idea is explained in hybrid key exchange in TLS: an attacker has to break both halves.
Names and numbers to know
The hybrid is specified in RFC 10024, a Proposed Standard published in August 2026. It lists X25519MLKEM768 with codepoint 4588 (0x11EC) as recommended, and two other hybrids, SecP256r1MLKEM768 and SecP384r1MLKEM1024, as not recommended by default. The client's key share for X25519MLKEM768 is 1,216 bytes (1,184 for ML-KEM-768 plus 32 for X25519). That is why a ClientHello can grow past one network packet, and why old middleboxes sometimes misbehave.
OpenSSL 3.5
OpenSSL 3.5.0 was released on 8 April 2025 and is a Long Term Support line (the release notes page I read does not say so; check the OpenSSL release policy). Its release notes say it adds ML-KEM, ML-DSA and SLH-DSA, and that the default TLS group list now includes and prefers hybrid post-quantum groups. By default a TLS 1.3 client sends two key shares, X25519MLKEM768 and X25519. Cloudflare's support table also lists SecP256r1MLKEM768 and curveSM2MLKEM768 from OpenSSL 3.6.0. If you relied on legacy groups, check your configured group list after upgrading, because the defaults changed.
A command line test
With OpenSSL 3.5 or later, this asks for the hybrid group and prints the negotiated one. The output line below comes from third-party notes and a GnuTLS developer report, and I could not run it with OpenSSL 3.5 for this page. I did run a control with the OpenSSL 3.0 client installed here: it connected with -groups X25519 but printed Server Temp Key instead of the Negotiated TLS1.3 group line, and it refused X25519MLKEM768 outright, so an older client cannot test this. Confirm the command on your own 3.5 or later build:
echo | openssl s_client -connect HOST:443 -tls1_3 -groups X25519MLKEM768 2>/dev/null | grep -iE "Negotiated TLS1.3 group|Server Temp Key"If the line shows X25519MLKEM768, the handshake used the hybrid. The OpenSSL 3.5 manual page for s_client only points to SSL_CONF_cmd for the -groups option and does not document this output line, so treat the exact wording as version dependent. Run a control with the group set to X25519 so you know the command itself works. Remember the result shows what the server chose, so a server that does not support the hybrid will fall back or fail. CVE-2026-2673 (published March 13, 2026) affects OpenSSL TLS 1.3 servers whose group list uses the DEFAULT keyword: a less preferred group may be chosen even when a preferred one is supported by both sides, which can happen with the new hybrid groups. The record lists 3.5.0 up to but not including 3.5.6, and 3.6.0 up to but not including 3.6.2, as affected, so patch level matters.
Browsers
Cloudflare's docs list default hybrid key agreement in Chrome 131 and later, Edge 131 and later, Brave 1.73.86 and later, Opera 116 and later, Firefox 132 and later on desktop (145 and later on Android), Tor Browser 15 and later, and Safari 26 and later (iOS 26 and macOS Tahoe 26). Because it is on by default, you normally need no flag. To check, open Cloudflare's Radar browser support check or the Cloudflare Research test page, which lists X25519MLKEM768 as recommended. If your test reports no support, update the browser first before hunting for flags.
Go, Java, Node and others
| Stack | Reported status |
|---|---|
| Go | X25519MLKEM768 on by default in crypto/tls from Go 1.24 when CurvePreferences is nil. Setting the GODEBUG value tlsmlkem=0 turns it off, which the release notes suggest for buggy servers that cannot handle large records. |
| Java | JEP 527 delivers hybrid groups for TLS 1.3 in JDK 27, with X25519MLKEM768 first in the default client list. |
| Node.js | Default key agreement in 24.5.0 and later, and 22.20.0 and later. |
| rustls | Enabled by default since 0.23.27. |
| Servers | NGINX when built with OpenSSL 3.5 or later; Caddy by default from 2.10.0; Traefik from 3.4.2. |
Gotchas when you turn it on
- Handshake timeouts: a bigger ClientHello can break broken middleboxes. Keep a rollback switch.
- Logging and inspection: proxies that parse TLS may not understand the new group.
- Do not confuse key agreement with certificates: a green PQ result says nothing about whether the server certificate is quantum-safe. It is not.
Why bother
Cloudflare reported that by late October 2025 the majority of human-initiated traffic to it used post-quantum encryption, and that only about 3.7% of origins supported X25519MLKEM768 in 2025. So the browser half is largely done and the server and origin half is where developers still have work. For the wider picture see the Cloudflare, Google and Apple rollout and the company migration checklist.
Sources and further reading
- OpenSSL 3.5 series release notes
- Cloudflare docs: post-quantum support by browser, library and server
- Cloudflare Research: post-quantum key agreement test page
- RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3
- Go 1.24 release notes (crypto/mlkem, X25519MLKEM768)
- OpenJDK JEP 527: post-quantum hybrid key exchange for TLS 1.3
- Cloudflare blog: state of the post-quantum Internet in 2025
- gnutls-devel: example of the expected Negotiated TLS1.3 group output
- CVE.org: CVE-2026-2673 (OpenSSL)
Reported as of 2026-10-09. Library versions, defaults and standards status change often, so check the primary documents and test on your own stack before relying on anything here. Nothing here is financial advice or a security audit. The QNT memecoin is independent of Quantinuum Ltd, the real company, and of every project, library, lab and chain named on this page.
Frequently asked questions
Do I need a browser flag to use post-quantum TLS?
Usually not. Cloudflare's docs list hybrid key agreement as on by default in current Chrome, Edge, Firefox and Safari releases. Update the browser and test with Cloudflare's tools.
Does post-quantum key agreement make my whole connection quantum-safe?
No. It protects the session key against later decryption. Certificates and signatures are still classical on the public web today.
Which group name should I look for?
X25519MLKEM768, a hybrid of X25519 and ML-KEM-768.
Could enabling it break my network?
Occasionally. The hybrid key share is 1,216 bytes, which can trip old middleboxes. Test in staging and keep a rollback.
Keep reading
- Hybrid Key Exchange in TLS Explained: How Your Browser Is Already Quantum Ready
A plain English guide to X25519MLKEM768, the hybrid handshake that now protects a large share of web traffic against harvest now, decrypt later attacks. - ML-KEM Explained: The Post-Quantum Key Exchange Standard
ML-KEM (FIPS 203) is NIST's standard for post-quantum key encapsulation. Learn what a KEM is, how lattices fit in, and where it is used, in plain English. - Cloudflare, Google and Apple: Who Is Rolling Out Post-Quantum Security in 2026
A tour of the big internet players moving to post-quantum cryptography: Cloudflare's traffic numbers, Chrome's certificate plan, and Apple's system-wide support. - Post-Quantum Certificates and PKI: The Hard Part of Securing the Web
Why upgrading website certificates and signatures is harder than upgrading key exchange, and what Merkle Tree Certificates and ML-DSA could change. - A Plain English Post-Quantum Migration Checklist for Companies
A step by step checklist any company can follow to get ready for post-quantum cryptography, including how banks and financial firms are prioritizing.
All Quantum computing guides | Back to top | Search the site
Main pages: Quantum computing explained | Quantum and crypto | Companies | Quantum news | Glossary