# Post-Quantum TLS Checker | Verify ML-KEM negotiation paths

Probe an authorized server with default and ML-KEM-only TLS clients to exercise negotiation success and fallback, or inspect pasted handshake output locally.

Canonical: https://tamperbox.dev/post-quantum-checker

Docs: https://docs.tamperbox.dev/tools/post-quantum-checker.md

Updated: 2026-10-26

Reviewed: 2026-10-17

## 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](https://docs.tamperbox.dev/tools/post-quantum-checker/).

## 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](https://www.rfc-editor.org/rfc/rfc9846#section-4.3.7) (obsoletes RFC 8446) · [ML-KEM hybrids for TLS 1.3: RFC 10024, section 4](https://www.rfc-editor.org/rfc/rfc10024#section-4) · [Hybrid key exchange in TLS 1.3: RFC 9954, section 3](https://www.rfc-editor.org/rfc/rfc9954#section-3) · [ML-KEM: FIPS 203](https://csrc.nist.gov/pubs/fips/203/final) · [TLS Supported Groups registry](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8).