Verify ML-KEM negotiation paths
Could recorded traffic be decrypted later? Two handshakes show whether this server uses ML-KEM key exchange.
Probe an authorized server with default and ML-KEM-only TLS clients to exercise negotiation success and fallback, or inspect pasted handshake output locally. Jump to: What does it mean?, How to fix it, Break it, Ask your agent.
Live default
Pasted handshake output stays in your browser. openssl s_client or curl -v output is read here and never uploaded.
A host name means two connections from our server. Both open TLS on port 443, keep nothing, and return the group the server chose.
Findings
Take it further
The default client’s key exchange
Two handshakes
What it protects
Turn on ML-KEM
What this result means
Written for this result.
The Tamperbox post-quantum check of tamperbox.dev ran two TLS handshakes on port 443: one with the probe's default group offer, one offering only the ML-KEM hybrids. Which of my servers and load balancers still negotiate a classical key exchange, and what would turning on X25519MLKEM768 take on each? The check came from Tamperbox /post-quantum-checker. Its method and limits are at https://tamperbox.dev/post-quantum-checker.md; read them before relying on the result.
Connect Tamperbox MCP and the agent can run this check itself, with the same limits.
The page rewrites this card with the current handshake evidence each time it opens.
- Run a TLS library with ML-KEM: OpenSSL 3.5 or later, Go 1.24 or later, Caddy 2.10 or later.
- Put X25519MLKEM768 first in the group list, then X25519 and P-256.
- Keep TLS 1.3 on; the hybrids do not exist in TLS 1.2.
- Check the CDN or load balancer that terminates TLS, not only the origin.
Use the current finding and the configuration under the result before changing a server.
Only key exchange is judged. Certificate signatures stay classical and are not assessed for post-quantum security.
Nothing you enter is stored.
How it works
Enter a host name and our server opens two TLS connections on port 443: one with the probe’s default group offer, which reports the key exchange group the server chooses, and one offering only the three ML-KEM hybrids, which shows whether the server can use them at all. Paste openssl s_client or curl -v output and the one handshake it records is read in your browser. The full method, every rule and worked examples are on docs.tamperbox.dev.
Limits and interpretation
Only key exchange is judged; certificate signatures stay classical and are not assessed for post-quantum security. The probe’s default offer is not a browser ClientHello, so a browser can get a different group. A refused ML-KEM-only handshake does not prove the server lacks support, and an unknown group name is left unclassified. One location, port 443 only, one moment. If a CDN or load balancer terminates TLS, its settings decide the result, not the origin’s. Nothing is stored.
Frequently asked questions
What does post-quantum TLS key exchange protect?
It protects the session key. A hybrid such as X25519MLKEM768 combines a classical exchange with ML-KEM, so traffic recorded today cannot be decrypted later by a quantum computer. Certificate signatures are a separate question.
Why run two TLS handshakes?
The first shows which group the server chooses when classical groups are offered too. The second offers only ML-KEM hybrids, which shows support that a classical-first preference would hide.
Does a failed ML-KEM-only handshake prove no support?
No. A handshake can fail for reasons unrelated to ML-KEM. Read it with the default handshake’s result and the error the probe reports.
References
TLS 1.3 supported groups: RFC 9846, section 4.3.7 (obsoletes RFC 8446) · ML-KEM hybrids for TLS 1.3: RFC 10024, section 4 · Hybrid key exchange in TLS 1.3: RFC 9954, section 3 · ML-KEM: FIPS 203 · TLS Supported Groups registry.
Are you an AI agent? You are in the right place.
This page and every tool are available as plain text with their methods and limits, and the same checks run over MCP.