×
Post-Quantum Key Exchange in Web Browsers: Testing ML-KEM in Chromium and Firefox

1. The Reality of Quantum-Safe Browser Handshakes

Following the finalization of NIST's FIPS 203 standard, major web browser engines (Google Chrome/Chromium and Mozilla Firefox) enabled hybrid post-quantum key exchange algorithms by default in 2024 and 2025. This milestone protects daily enterprise web browsing sessions from "Harvest Now, Decrypt Later" state-sponsored surveillance operations.

2. The X25519MLKEM768 Hybrid Cipher Suite

The standard hybrid key exchange mechanism combines classical X25519 with ML-KEM-768 (formerly Kyber768). In TLS 1.3, the client sends both key shares inside the ClientHello handshake. The web server encapsulates a shared secret using both algorithms, combining the outputs with a Key Derivation Function (HKDF). An attacker would need to break both classical discrete logarithms and quantum lattice problems to intercept traffic.

3. Network Middlebox and MTU Fragmentation Challenges

The primary technical hurdle in deploying PQC is payload size: classical X25519 public keys are only 32 bytes; ML-KEM-768 public keys are 1,184 bytes. Larger ClientHello packets frequently exceed the standard 1,500-byte Maximum Transmission Unit (MTU), causing TCP packet fragmentation. In poorly configured corporate networks, legacy middleboxes and deep-packet inspection firewalls drop fragmented handshakes, causing silent connection timeouts.

4. Server Configuration Best Practices

Enterprise infrastructure teams must update edge reverse proxies (Cloudflare, NGINX 1.27+, HAProxy 3.0+) and OpenSSL 3.3+ to support the standardized codepoint (0x11ec). Monitor TCP retransmission rates and ClientHello failures across internal subnets to ensure legacy corporate firewalls do not block modern hybrid handshakes.