BIPI
BIPI

Quantum-Safe TLS: What Enabling X25519+Kyber Actually Looks Like

Cybersecurity

Chrome and Cloudflare already negotiate hybrid post-quantum TLS for a meaningful share of traffic. The migration question for enterprises is no longer if, but which workloads first and how to handle the handshake bloat.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 1, 2024 · 7 min read

#quantum#tls#cryptography#pqc

We ran a hybrid post-quantum TLS pilot on a fintech client's customer API in February. The brief was simple: turn on X25519Kyber768 between their CDN and origin, watch what breaks. Three things broke. We learned more from those three than from six months of vendor briefings.

Chrome enabled the hybrid by default in version 124 back in 2024. Cloudflare reports roughly a third of inbound TLS 1.3 connections now negotiate it. The cryptographic case is settled. The operational case is where most security teams are still guessing.

What actually changes on the wire

The hybrid key exchange concatenates a classical X25519 share with a Kyber768 share. Server picks both, client verifies both, session key is derived from a KDF over the combined secret. If Kyber falls tomorrow, X25519 still protects you. If a CRQC arrives in 2032, the Kyber share carries the load.

The visible cost is handshake size. Kyber768 public keys are 1,184 bytes, ciphertexts 1,088. Your ClientHello jumps from around 500 bytes to roughly 1,700. That pushes you past the typical 1,500-byte MTU on the first flight, which means TCP segmentation, which means at least one extra round trip on lossy networks.

1.7KB
ClientHello size with hybrid PQC
+4ms
median handshake latency on fiber
33%
of Cloudflare TLS 1.3 traffic uses hybrid

Where the pilot broke

First break: a load balancer in front of the origin had a hardcoded 1,400-byte buffer for TLS records and silently truncated the ClientHello. Connections succeeded for one client and failed for another depending on extension ordering. The fix was a firmware update we had to schedule six weeks out.

Second break: a packet inspection appliance treated the oversized ClientHello as an anomaly and dropped it. The vendor had a signature update available but we had not deployed it. Two weeks of firewall change-control paperwork.

Third break: an internal service mesh used a TLS library that did not understand the new named group. It downgraded silently to X25519 alone. We only caught it because we had instrumented handshake telemetry. Most teams will not.

When to start your migration

Harvest-now-decrypt-later is the threat model that matters. If you carry data with a confidentiality lifetime past 2032, the clock has been ticking since 2018. Banking transactions, medical records, source code, anything with a long secret tail.

  • Inventory every TLS-terminating device. Load balancers, WAFs, IDS, service meshes, internal proxies.
  • Check vendor support for X25519MLKEM768 (the IETF name) or X25519Kyber768Draft00 (the legacy name).
  • Enable on a single low-risk service first and instrument handshake telemetry. Look for downgrades.
  • Plan for the handshake size impact on UDP-based QUIC paths. The picture is messier there.

What we tell clients today

Start with public-facing endpoints behind a modern CDN. Cloudflare, Fastly and Akamai already speak hybrid PQC. The CDN absorbs the complexity, your origin keeps speaking classical TLS for now. Use 2026 to inventory, 2027 to enable on internal mTLS where you control both ends, 2028 to start retiring pure-classical paths.

The teams that will struggle in 2027 are not the ones who started late. They are the ones who waited for a single forced cutover. Hybrid lets you migrate gradually. Use that.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.