Post-Quantum TLS Migration
TLS is the protocol that secures every HTTPS connection on the internet. Migrating it to post-quantum cryptography is the single most impactful step in making the internet quantum-safe. The good news: it's already happening. Here's the state of play and what you need to do.
What Needs to Change in TLS for Post-Quantum?
TLS 1.3 uses three cryptographic operations that need post-quantum replacements:
Used for the key exchange during the handshake. Highest priority — protects against harvest-now-decrypt-later.
Used to sign TLS certificates. Lower urgency — an attacker needs quantum capability to forge signatures in real-time.
The CertificateVerify message in TLS 1.3 authenticates the server's certificate. Needs a post-quantum signature scheme.
Hybrid Key Exchange: X25519Kyber768
The most widely deployed approach is hybrid key exchange: running classical ECDH and ML-KEM simultaneously in the same TLS handshake.
The specific hybrid being deployed is X25519Kyber768 (also called x25519_kyber768d00 in IETF drafts):
- X25519: Elliptic Curve Diffie-Hellman using Curve25519 — the current gold standard for ECDH
- Kyber768: ML-KEM-768 — the NIST-standardized post-quantum KEM
How X25519Kyber768 works in TLS
- Client includes X25519Kyber768 in its supported_groups list in ClientHello
- Server, if it supports X25519Kyber768, generates both a classical X25519 key share and an ML-KEM key pair
- Client encapsulates a shared secret to the server's ML-KEM public key AND performs X25519 key exchange
- Both parties run a KDF (Key Derivation Function) over the concatenation of both shared secrets
- The final session key is only secure if at least one of X25519 or ML-KEM is unbroken
Who Has Already Deployed Post-Quantum TLS?
Google Chrome
Deployed X25519Kyber768 by default starting with Chrome 116 (August 2023). All HTTPS connections from Chrome to supporting servers now use post-quantum key exchange. Google's own servers (Google.com, Gmail, YouTube) support it.
Live in production
Cloudflare
Deployed post-quantum key exchange (X25519Kyber768 and ML-KEM-768) across their network. All Cloudflare-proxied sites now support PQC for clients that request it. Cloudflare reports millions of PQC connections per day.
Live in production
Apple
Deployed PQC in iMessage using PQXDH (Post-Quantum Extended Diffie-Hellman) — a hybrid that combines X25519 and ML-KEM. iMessage has used end-to-end PQC since iOS 17.4 / macOS 14.4 (March 2024).
Live in production
AWS
Added ML-KEM-768 hybrid support in AWS SDK and load balancers. Offers post-quantum TLS configuration for CloudFront, API Gateway, and other services.
Available now
Post-Quantum TLS Certificates: The Harder Part
Post-quantum key exchange is the easy part — it's opt-in and backward-compatible. Post-quantum certificates are more complex because:
- Certificates must be signed by CAs that use post-quantum signature algorithms
- Intermediate and root CA certificates need to migrate too (the whole chain)
- Certificate revocation infrastructure, OCSP, and CT logs all need updates
- ML-DSA signatures are ~50× larger than ECDSA — this increases handshake bandwidth
Hybrid Certificates
The IETF is standardizing hybrid X.509 certificate formats that contain two signatures — one classical (ECDSA) and one post-quantum (ML-DSA). This allows the certificate to be verified by both PQC-capable and legacy clients during the transition period. Several PKI vendors and Let's Encrypt are planning to issue hybrid certificates.
Frequently Asked Questions
Will I notice any performance impact when enabling PQC TLS?
Minimal for key exchange — the handshake adds a few hundred extra bytes and a small computational overhead (ML-KEM is fast). Certificates will add more bandwidth when post-quantum certificates become common (~3KB of signatures vs. ~100 bytes currently). For most applications, this is negligible. For extremely latency-sensitive applications or very low-bandwidth connections, some optimization may be needed.
How do I enable post-quantum TLS on my web server today?
For nginx/Apache with recent OpenSSL: add X25519Kyber768 to your ssl_ecdh_curve setting. For Cloudflare-proxied sites: it's automatic — PQC is enabled by default. For direct server configurations: use OpenSSL 3.x with liboqs provider, or BoringSSL, which has built-in ML-KEM support. The IETF hybrid TLS specification (draft-ietf-tls-hybrid-design) is the guide for proper implementation.
What about older clients that don't support PQC?
This is the beauty of hybrid TLS and algorithm negotiation. A client that doesn't support ML-KEM will simply negotiate X25519 (classical only) — the connection still works, just without quantum protection. PQC-capable clients get the hybrid protection. You never break backward compatibility. As PQC-capable clients become the majority, you can eventually make ML-KEM mandatory.
Frequently Asked Questions
What will I learn here?
This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.
How should I use this page?
Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.
What should I read next?
Use the navigation below to continue to the next lesson or explore related topics.