The term on this page
- TLSTransport Layer Security
- the protocol behind the padlock in your browser
Also mentioned
RSARSARivest, Shamir and AdlemanA widely used public-key algorithm for encryption and digital signatures whose security relies on the difficulty of factoring large numbers.Read the full entry (new tab), ECDSAECDSAElliptic Curve Digital Signature AlgorithmElliptic Curve Digital Signature Algorithm, a widely deployed signature scheme based on elliptic-curve cryptography, offering strong security with compact keys.Read the full entry (new tab), ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab) are defined in the glossary.
Read this first
A library, runtime, or server can support hybrid post-quantum TLS while a real connection still negotiates a classical group. A useful test proves four different facts: the client offered a hybrid group, the server selected it, the full production path preserved it, and certificate authentication was assessed separately. Add a classical fallback test and a resumed-connection test before treating the result as deployment evidence.
The shortest honest answer to "does this site support post-quantum TLS?" is a captured negotiation result, not a version number. TLS 1.3 puts the offered key shares in ClientHello and the selected share in ServerHello. RFC 10024 assigns X25519MLKEM768 the supported-group value 4588 and defines exactly what each side contributes. If ServerHello selects that group, the session key comes from both an X25519 shared secret and an ML-KEM-768 shared secret.
That evidence has a narrow scope. It proves the key agreement for one connection. It does not prove that every edge location, client population, origin hop, or resumed connection behaves the same way. It also does not prove that the certificate chain uses post-quantum signatures. The hybrid TLS migration guide explains the rollout sequence; this article focuses on the acceptance test that should close each stage.
Separate four claims before collecting evidence
| Claim | Evidence to keep | What it does not prove |
|---|---|---|
| The client supports hybrid TLS | ClientHello offers X25519MLKEM768 or another approved hybrid group | That a server selected it |
| This connection negotiated hybrid TLS | ServerHello selects the hybrid group on a full handshake | That every route or future connection does |
| The production path preserves hybrid TLS | Results from each edge, proxy, load balancer, and origin hop | That certificate authentication is post-quantum |
| Authentication is post-quantum | The certificate chain and CertificateVerify signature algorithms | That the key exchange was hybrid |
This distinction prevents a common false positive. A scanner sees X25519MLKEM768 in ClientHello and reports success even though the server selects X25519. Another test sees a hybrid group at the public edge but never checks the separate TLS connection from the load balancer to the origin. The post-quantum TLS checker is useful for the public endpoint, while the cryptographic inventory guide helps map the internal termination points that an external scan cannot see.
Pass one: capture a clean full handshake
Start without session resumption so the trace contains a complete key exchange. Record the client and server versions, target hostname, resolved edge address, time, TLS version, offered groups, selected group, and whether a HelloRetryRequest occurred. Use the tracing facility built into the TLS stack or a packet capture on a controlled test system. The ClientHello and ServerHello are visible in TLS 1.3, so the group selection can be inspected without decrypting application traffic.
For X25519MLKEM768, RFC 10024 defines a 1,216 byte client key share, a 1,120 byte server key share, and a 64 byte combined shared secret. Those sizes are protocol values, not proof by themselves. They are useful cross-checks when a decoder labels an unknown group numerically or when an older capture tool has not learned the new name. The TLS hybrid key exchange reference tracks the standardized groups and identifiers.
An offer is not a selection
Keep the ServerHello result in the acceptance record. A ClientHello that offers group 4588 only proves client capability. If the server selects a classical group, the connection is classical even when the client offered ML-KEM.
Pass two: test the route, not just the hostname
Run the same full-handshake test against every relevant path: IPv4 and IPv6, each CDN or regional edge, the load balancer, the service mesh ingress, and the origin when policy permits. Repeat from representative client networks. A deployment can be mixed because configuration, library versions, and middlebox behavior differ between paths. Store results by termination point rather than reducing them to one site-wide boolean.
Larger hybrid shares also change the shape of ClientHello. Packet count, fragmentation, and old inspection devices can therefore expose path-specific failures. If the server supports a mutually acceptable group but the client's first key share is not acceptable, TLS 1.3 allows a HelloRetryRequest. Record it. A successful retry is still a successful connection, but it adds a round trip and can signal a preference or configuration mismatch worth fixing.
Pass three: run negative and fallback controls
A positive test is easier to trust when the controls behave predictably. Connect with a client that offers only the approved hybrid group and confirm that the endpoint either selects it or fails clearly. Then use a classical-only client and confirm that the result matches the stated compatibility policy. Finally, place any relevant proxy or inspection device back in the path and repeat both cases. Silent classical fallback may be allowed during a staged migration, but it must be visible in the result and bounded by policy.
- Fail the test if the reported selected group cannot be tied to ServerHello evidence.
- Flag, rather than hide, a HelloRetryRequest or an unexpected classical selection.
- Record which endpoint terminated TLS and whether a second protected hop exists behind it.
- Keep the exact client profile because group order and implementation defaults change.
- Re-run after proxy, CDN, certificate, runtime, or TLS policy changes.
The guide to enabling post-quantum TLS covers current server configuration. The acceptance test should remain implementation-neutral: a change passes because the negotiated result matches policy, not because a particular configuration line exists.
Pass four: test resumption and authentication separately
Now reconnect with session resumption enabled and label that result separately from the full handshake. TLS 1.3 can establish a resumed connection from a pre-shared key, with or without a fresh key exchange. The absence of a new hybrid key share in one resumed trace is not automatically a downgrade, but it changes what that trace proves. The original session, ticket lifetime, PSK mode, and current policy all belong in the record.
Then inspect authentication. Hybrid key agreement protects the establishment of traffic keys against a future quantum attacker when at least one component remains secure. It does not replace the certificate signature. A deployment can negotiate X25519MLKEM768 while authenticating the server with RSA or ECDSA. Track certificate and CertificateVerify algorithms as a separate migration line, using the ML-DSA reference when post-quantum signatures enter the plan.
A practical acceptance record
The final artifact can be small: target and route, timestamp, client profile, TLS version, offered groups, selected group, retry status, resumption mode, certificate signature algorithm, capture or trace hash, and the policy verdict. Keep raw traces under the same access controls as other diagnostic traffic. They can contain hostnames, addresses, session identifiers, and operational details that do not belong in a public report.
Treat a passing result as dated evidence, not a permanent property. The ML-KEM standard defines the primitive, while deployment evidence depends on software, configuration, and routing that continue to change. Repeating this four-pass test after each material TLS change turns post-quantum support from a product claim into an observable control.
References
- IETF RFC 10024: Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3. Group identifiers, wire formats, validation requirements, and shared-secret construction.
- IETF RFC 8446: The Transport Layer Security Protocol Version 1.3. ClientHello, ServerHello, key_share negotiation, HelloRetryRequest, and resumption behavior.
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. ML-KEM algorithm and parameter sets.
- IETF RFC 9325: Recommendations for Secure Use of TLS and DTLS. Operational guidance for TLS configuration and deployment.