Hybrid TLS in Practice: X25519MLKEM768 Explained

Hybrid key exchange is the practical route to post-quantum security on the web today. Rather than betting everything on one new algorithm, it runs a classical key exchange and a post-quantum one side by side and combines the results. The most widely deployed combination is X25519MLKEM768: elliptic-curve Diffie-Hellman on Curve25519 paired with ML-KEM-768.

Why hybrid instead of ML-KEM alone

Two risks pull in opposite directions. Classical algorithms are well understood but would fall to a large quantum computer. ML-KEM resists quantum attacks, but it is much newer, and implementation or mathematical weaknesses could still surface. A hybrid keeps security if either component remains unbroken: an attacker must break both X25519 and ML-KEM to recover the session key. Standards bodies including NIST support hybrid use during the transition period.

How it works in TLS 1.3

TLS 1.3 negotiates a "named group" for key exchange. A hybrid group is simply a new named group whose key share is the concatenation of two key shares:

1. The client's ClientHello includes a key share for X25519MLKEM768: an X25519 public key (32 bytes) followed by an ML-KEM-768 encapsulation key (1,184 bytes).
2. The server replies with its X25519 public key plus an ML-KEM ciphertext (1,088 bytes).
3. Each side derives two shared secrets, one from X25519 and one from ML-KEM, and concatenates them.
4. The concatenated secret goes into the normal TLS 1.3 key schedule.

Nothing else in TLS changes. Certificates, record encryption and the rest of the handshake are unchanged. Note that the certificate signature is still classical, which is acceptable for this purpose: an attacker cannot retroactively forge a signature on a past session, so the confidentiality benefit holds. Authentication migration is a later, separate step.

What it costs

Roughly 1.1 to 1.2 KB is added in each direction. The ClientHello can now exceed a typical single-packet size, so it may span two TCP segments or QUIC packets. Early rollouts found some middleboxes and firewalls that could not parse a fragmented ClientHello. This is the main operational risk, and the reason to test through real network paths.

CPU cost is small: ML-KEM is fast, so the extra work per handshake is modest next to the bandwidth increase.

Who supports it

Hybrid ML-KEM groups are available in current releases of the major browsers and in widely used libraries and platforms, including OpenSSL 3.5 and later, BoringSSL, AWS-LC and recent Go versions, and many CDNs and cloud load balancers expose it as a setting or policy. Support changes quickly, so confirm with each vendor's documentation rather than assuming. In most deployments, once both ends support it, it is simply negotiated.

Enabling and verifying

For a server using OpenSSL 3.5 or later, you can express group preferences in configuration. A minimal check from the client side:

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i "group\|Negotiated"

Also verify in real traffic. Packet captures show the ClientHello's supported_groups and key_share extensions, and many CDNs report the negotiated group in logs. Record this in your metrics so you can track the percentage of connections that are post-quantum protected.

Rollout advice

• Terminate at the edge first. Enable the group on your CDN or load balancer before touching internal services.
• Stage with real clients. Test from corporate networks, mobile carriers and legacy proxies, since middleboxes vary.
• Keep fallback. Clients without hybrid support will negotiate X25519 automatically; do not disable that until telemetry says it is safe.
• Watch handshake error rates and p95 latency before and after each change.
• Mind inspection devices. TLS-inspecting proxies must support the new group or they may block or downgrade connections.

What hybrid does not solve

Server certificates and client authentication are still classical, so you have not yet migrated signatures. Data already recorded under classical-only key exchange stays exposed. Hybrid protects sessions from the day it is enabled, which is why enabling it early on long-lived-data endpoints matters (see Harvest Now, Decrypt Later).