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.