You know that ML-KEM is being deployed in TLS. This lesson shows you exactly where it lives in the TLS handshake, what hybrid key exchange looks like in practice, and how to verify whether a real connection is using post-quantum cryptography. By the end you will be able to look at an actual browser connection and identify the quantum vulnerability, or its absence.
Unit 2 progress
By the end of this lesson you will be able to
Map the TLS 1.3 handshake steps and identify where quantum vulnerability lives
Explain what hybrid key exchange is and what X25519MLKEM768 means
Describe the difference between the key exchange migration track and the certificate migration track
Name three real-world deployments of hybrid PQC TLS already in production
Explain what a browser's Security tab reveals about PQC status of a connection
Part 1 — Where the vulnerability lives in a TLS connection
A TLS connection has two cryptographic layers that need to migrate to post-quantum cryptography. They are separate, they migrate on different timelines, and confusing them is one of the most common mistakes in PQC planning discussions.
Vulnerable — HNDL risk
Key exchange layer
ECDH or RSA establishes the shared secret. An adversary recording this handshake today can decrypt the entire session when a quantum computer is available. This is the HNDL threat in action. Replacement: ML-KEM (FIPS 203)
Needs migration — future risk
Certificate layer
RSA or ECDSA certificates authenticate the server. A quantum computer could forge these signatures, enabling impersonation. Less immediate than key exchange, session content is not at HNDL risk here. Replacement: ML-DSA (FIPS 204)
The key exchange layer is the more urgent of the two precisely because of HNDL. Session content encrypted today with a classically-negotiated key is at retrospective risk. Certificate forgery requires a quantum computer at the moment of the attack, it cannot be done retroactively against recorded traffic. This is why key exchange migration (ML-KEM) is deployable and worth deploying right now, even before certificate migration is possible.
Part 2 — The TLS 1.3 handshake, step by step
Walk through the TLS 1.3 handshake below. Toggle between classical and hybrid PQC mode to see exactly what changes, and what stays the same.
TLS 1.3 Handshake Simulator
🖥️ Client (browser)
↔
🌐 Server
Step 0 of 5
Part 3 — What X25519MLKEM768 means
When you see a TLS connection advertised as using X25519MLKEM768, this is the hybrid key share identifier. It tells you exactly what is happening in the key exchange: two algorithms are running simultaneously and their outputs are combined.
X25519MLKEM768
X25519
Classical ECDH
Curve25519 Diffie-Hellman. The fastest and most widely deployed ECDH variant. Vulnerable to Shor's algorithm. Included for backward security, if ML-KEM has any unknown flaw, this component still protects the session classically.
+
combined via HKDF
MLKEM768
ML-KEM (FIPS 203, level 768)
Post-quantum key encapsulation. Resistant to Shor's algorithm. The "768" refers to the ML-KEM-768 parameter set, the middle security level, balancing quantum resistance with performance. Adds ~1,100 bytes to the handshake.
Result: shared_secret = HKDF(X25519_secret ‖ MLKEM768_secret). The session is protected against both classical attacks (by X25519) and quantum attacks (by MLKEM768). Breaking the session requires breaking both simultaneously.
The security property of hybrid key exchange is elegant: an attacker must break both components simultaneously to compromise the session. X25519 protects against attackers who find a flaw in ML-KEM. ML-KEM protects against attackers with quantum computers. Neither alone is sufficient for an attacker, both are required.
Part 4 — Key share sizes: what changes in the handshake
One practical concern about hybrid PQC TLS is handshake size. ML-KEM adds bytes to the ClientHello and ServerHello messages. The table below shows the key share sizes for the algorithms involved.
Key share sizes in TLS ClientHello
Algorithm
Type
Public key size
Ciphertext size
X25519
Classical
32 bytes
32 bytes
ML-KEM-768
Post-quantum
1,184 bytes
1,088 bytes
X25519MLKEM768 (hybrid)
Hybrid
1,216 bytes combined
1,120 bytes combined
RSA-2048 (legacy, key exchange)
Deprecated
256 bytes
256 bytes
P-256 ECDH (legacy)
Classical
65 bytes
65 bytes
The hybrid key share is about 38× larger than X25519 alone, but the performance impact is smaller than this suggests. Key exchange is a one-time handshake operation. For a typical HTTPS session, the added bytes amount to roughly one additional network round trip in constrained environments, and modern network conditions absorb this without measurable user-facing latency in most cases. The Cloudflare and Google deployments confirmed this empirically.
CFor IT professionals planning TLS migration: the key exchange size increase matters most for environments with very small MTUs, high-latency links (satellite, some mobile networks), or TLS session ticket resumption infrastructure. For CDN-fronted web services, the impact is negligible: Cloudflare measured no meaningful latency increase. For direct connections to internal APIs over constrained links, benchmark before deploying in production. The test is worth running before dismissing hybrid TLS or deploying blindly.
Part 5 — Real deployments: who is live today
Hybrid PQC TLS is not theoretical. These are production deployments running at scale right now.
Browser
Google Chrome / Chromium
Enabled X25519MLKEM768 by default for all TLS 1.3 connections in Chrome 124 (April 2024). This means every Chrome user's HTTPS connections to supporting servers already use hybrid PQC key exchange. The server must also support it: Chrome falls back to X25519 if the server does not advertise the hybrid key share.
Live since: April 2024
CDN / infrastructure
Cloudflare
Enabled post-quantum key exchange across their entire global network. All TLS 1.3 connections to Cloudflare-proxied sites negotiate hybrid ML-KEM when the client supports it. Cloudflare published latency measurements confirming no meaningful user-facing impact.
Live since: 2023 (X25519Kyber768 draft), updated to X25519MLKEM768 in 2024
Cloud provider
AWS (Amazon Web Services)
AWS Key Management Service (KMS) and AWS Certificate Manager support hybrid PQC TLS. AWS-LC (Amazon's cryptographic library) implements ML-KEM and is used across AWS infrastructure. Elastic Load Balancer supports PQC cipher suites.
Live since: 2023–2024 rollout
Search / infrastructure
Google (servers)
Google's servers support X25519MLKEM768, completing the loop with Chrome's client-side deployment. Google Search, Gmail, and other Google services negotiate hybrid PQC TLS when accessed from a supporting client.
Live since: 2024
BFor SMB decision-makers: if your business uses Cloudflare, AWS, or Google Cloud for any infrastructure, you are already benefiting from hybrid PQC key exchange protection for traffic to those services, even without doing anything. What this does not cover: your own origin servers, internal APIs, VPN infrastructure, or any service you host directly. The cloud provider protects the edge; your internal infrastructure still needs its own migration plan.
AFor motivated learners: you can verify hybrid PQC TLS in Chrome right now. Open Chrome DevTools (F12), go to the Security tab, and connect to cloudflare.com or any Google property. Look for "Key exchange: X25519MLKEM768" in the connection details. If you see it, the key exchange for that session is quantum-resistant. If you see "X25519" alone, it is classical. This is the hands-on test that confirms what this lesson describes.
Part 6 — How to check a real browser connection
The Security tab in Chrome DevTools shows the cryptographic details of any TLS connection. Here is exactly what to look for and what each field means.
Chrome DevTools → Security tab (mock)
Connection to cloudflare.com
Protocol
TLS 1.3
Key exchange
X25519MLKEM768 ✓ Post-quantum
Server signature
ECDSA with P-256 Classical — will migrate
Cipher suite
TLS_AES_256_GCM_SHA384
Certificate
*.cloudflare.com · RSA 2048 · DigiCert
Reading this: Key exchange is quantum-safe (X25519MLKEM768). The server signature and certificate are still classical (ECDSA P-256, RSA-2048): Track 2 migration not yet complete. Session content is HNDL-protected. Server identity verification is not yet post-quantum.
Comprehension check
Question 1 of 3
A TLS connection shows "Key exchange: X25519MLKEM768" and "Certificate: RSA-2048." Which statement accurately describes its PQC status?
Question 2 of 3
In the hybrid key share X25519MLKEM768, why is the classical X25519 component kept alongside ML-KEM rather than dropped entirely?
Question 3 of 3
Why is deploying hybrid ML-KEM key exchange in TLS more urgent than waiting for ML-DSA certificate migration to be complete first?