Dr. Sarah ChenWhy TLS Is the First Battleground
Post-quantum cryptography is being deployed in a specific order, driven by threat exposure rather than technical simplicity. TLS connections are getting post-quantum protection before transaction signatures, certificate chains, or on-chain data structures. The reason is the harvest-now/decrypt-later threat profile.
When you sign a blockchain transaction with ECDSA, the signature is immediately verifiable by anyone. A future quantum computer could derive your private key from your public key, but that only matters if your key is still in use. You can migrate to a new key before a cryptographically relevant quantum computer (CRQC) exists.
TLS is different. A TLS session key negotiated today using ECDH (Elliptic Curve Diffie-Hellman) protects network traffic for the duration of the session. An adversary recording that encrypted traffic today can store it and decrypt it retroactively once a CRQC is available. The data transmitted, credentials, transaction details, API calls, and private communications, will be exposed even if the private key material is never directly attacked. This is the harvest-now/decrypt-later threat applied to network traffic, and it requires protection now rather than at some future migration date.
The Hybrid Key Exchange Approach in TLS 1.3
The solution deployed in production browsers and servers is a hybrid key exchange that combines classical and post-quantum algorithms. The specific combination Chrome and Firefox deployed in 2024 is X25519+ML-KEM-768, sometimes written as X25519MLKEM768 in configuration contexts.
In this hybrid scheme, TLS key exchange proceeds as follows. The client generates both an X25519 (ECDH) key share and an ML-KEM-768 key share, and sends both in the ClientHello. The server generates its X25519 key share and performs ML-KEM-768 encapsulation against the client's public key, sending both results in the ServerHello. Both sides derive the final session key by combining the outputs of both key exchanges using a key derivation function. The session key is bound to both exchanges: an attacker must break both X25519 and ML-KEM-768 to recover the session key.
This is the correct security property for a transition period. Classical X25519 is computationally secure against all known classical attacks. ML-KEM-768 is secure against quantum attacks per NIST FIPS 203. The hybrid combination is strictly stronger than either algorithm alone: it cannot be broken by a purely classical attack (because ML-KEM would remain secure) and cannot be broken by a purely quantum attack (because X25519 provides additional hardness that a quantum attacker must also overcome, even if quantum-breakable, the combined KDF output adds classical security on top).
The IETF Standards Basis
The technical specification for post-quantum TLS is defined in IETF documents. The primary reference is the IETF hybrid key exchange draft, draft-ietf-tls-hybrid-design, which defines the framework for combining classical and post-quantum algorithms in TLS key exchange. RFC 9258, "Importing External Pre-Shared Keys (PSKs) for TLS 1.3," provides adjacent infrastructure for pre-shared key scenarios.
The specific X25519+ML-KEM-768 combination used by Chrome and Firefox is defined in a hybrid named group specification under the TLS working group. The IANA codepoint 0x11EC corresponds to X25519MLKEM768, the named group identifier that appears in TLS ClientHello extensions. Servers that support this named group will prefer it when the client offers it.
The naming transition from Kyber to ML-KEM deserves specific attention because it creates confusion in configuration documentation. Before NIST finalized FIPS 203 in August 2024, the algorithm was known as Kyber. Chrome and Firefox initially deployed X25519Kyber768Draft00 using the pre-standardization Kyber768 specification. After finalization, deployments transitioned to X25519MLKEM768 using the FIPS 203-compliant ML-KEM-768. These are interoperable at the security level but use different wire formats. Configuration documentation referencing "Kyber" may need to be updated to reference ML-KEM for post-standardization deployments.
Browser Adoption and Current Deployment Status
Chrome 124, released April 2024, enabled X25519MLKEM768 by default for all TLS connections. This made Chrome the first major browser to deploy post-quantum key exchange in a default-on configuration. Firefox followed with post-quantum key exchange support in Firefox 132, released October 2024. Both browsers use X25519MLKEM768 as the preferred key exchange method when the server supports it, falling back to X25519 alone if the server does not.
The practical effect is that a significant fraction of TLS connections from Chrome and Firefox users are already protected against harvest-now/decrypt-later attacks at the key exchange layer. The protection depends on server support: a server that only supports X25519 will negotiate an X25519-only key exchange even with a post-quantum-capable client. Server-side deployment is therefore the current bottleneck in broad post-quantum TLS adoption.
Server-Side Deployment: nginx, Cloudflare, and Infrastructure Changes
Server-side post-quantum TLS deployment requires a TLS library that implements ML-KEM and an application server or proxy that exposes it. As of mid-2026, the deployment landscape is as follows.
OpenSSL 3.5, released in 2025, includes production-quality ML-KEM support. nginx compiled against OpenSSL 3.5 with the appropriate configuration supports X25519MLKEM768. The configuration change is minimal: adding X25519MLKEM768 to the ssl_ecdh_curve directive (or the libssl equivalent) is sufficient for servers that already run TLS 1.3. No other application changes are required; the key exchange change is transparent to application code.
Cloudflare enabled post-quantum key exchange on its global edge network in late 2023, covering HTTPS connections to all sites using Cloudflare's TLS termination. This represents the single largest deployment of post-quantum TLS by connection count. For blockchain infrastructure behind Cloudflare, post-quantum transport protection for API endpoints is available without any application-side changes.
AWS, Azure, and GCP have announced post-quantum TLS support timelines, with availability varying by service and region. Load balancers and API gateways are generally ahead of raw compute instances in post-quantum TLS support because they represent managed services with centralized TLS stack updates.
Implications for Blockchain Node Networks
Blockchain nodes communicate with each other over peer-to-peer network connections that are separate from the HTTPS APIs used by clients. These P2P connections use their own handshake and encryption protocols. For Ethereum-family networks, the devp2p protocol handles peer connections; for Bitcoin-derived networks, the TCP-based P2P protocol handles it.
Post-quantum TLS deployed at the HTTPS layer does not automatically protect P2P node communications. Protecting P2P channels requires either adapting the P2P protocol to use TLS 1.3 with post-quantum key exchange or implementing equivalent hybrid key exchange natively in the P2P protocol. Several blockchain projects are actively working on this. The practical result is that P2P traffic between blockchain nodes remains exposed to harvest-now/decrypt-later attacks on network-level data even after HTTPS endpoints are protected.
For enterprise blockchain deployments using Hyperledger Fabric or similar permissioned platforms, the P2P channel between peer nodes uses gRPC over TLS. Upgrading the underlying TLS library to OpenSSL 3.5 and enabling post-quantum key exchange in gRPC configurations provides post-quantum protection for peer-to-peer communication on these networks. This is a deployable, tested improvement that can be implemented before application-layer signature migration is complete.
What This Means for Your Migration Planning
Post-quantum TLS deployment is the lowest-friction, highest-impact step available in 2026. It requires a TLS library upgrade and a configuration change. It protects against the most immediately exploitable harvest-now/decrypt-later threat vector. It does not require changes to application logic, transaction formats, or key management procedures. And it is already deployed at scale by two of the three major browsers.
Any blockchain or fintech platform that has not yet deployed post-quantum TLS for its HTTPS endpoints, APIs, and managed node communications has a straightforward improvement available. Completing this step in 2026 positions the platform for the more complex application-layer migration work that follows, and it addresses the threat that is most likely to be actively exploited in the near term. The NIST PQC standards that underpin this deployment are final and stable. There is no technical reason to wait.
