# Chrome Turns On Post-Quantum Encryption in TLS by Default: What Changes and What Can Break
Table of Contents
For a few versions now, the Chrome browser has been protecting secure connections with a new piece of cryptography, designed to resist future quantum computers. It’s on by default, so most people don’t have to do anything and won’t notice a thing. For anyone who runs servers and networks, though, there’s an important detail: this change has surfaced latent bugs in some poorly implemented network devices, which means a few connections stop working after the browser updates. It’s worth understanding what changed, why, and what to check.
The news in brief
Chrome enabled a “hybrid” quantum-resistant key exchange by default on desktop computers starting with version 124, released in spring 2024. Key exchange is the first step of every secure connection: the moment when the browser and the site agree on a shared secret key, which is then used to encrypt the rest of the conversation. All of this happens inside TLS, the protocol behind https and the padlock in the address bar.
The change needs nothing from the user: if the site supports it, the connection starts out protected; if it doesn’t, the old method is used. No one has to install or configure anything.
The threat it addresses: “harvest now, decrypt later”
To see why this matters, start with a threat that has an unsettling name: harvest now, decrypt later. The idea is simple and unpleasant. Today, traffic on the Internet is encrypted: the data travelling between your device and the site is made unreadable to anyone who intercepts it, and that protection holds because current computers don’t have the power to break it in any reasonable time.
Quantum computers - a still-developing technology based on principles different from ordinary computers - could one day break much of the cryptography we use now. Nobody knows for sure whether or when that will happen. The problem, however, is already here: whoever intercepts encrypted traffic today can record and archive it, waiting to decrypt it later. Data that stays sensitive for many years - medical records, trade secrets, confidential communications - is therefore at risk right now, even though the machine capable of opening it doesn’t yet exist. Securing key exchange is exactly what takes the value out of that pre-emptive harvesting.
How it works: a hybrid key exchange
In practice, the old cryptography wasn’t thrown away and replaced with the new one. A hybrid approach is used: a classic, battle-tested algorithm is combined with a post-quantum one. The connection stays protected as long as at least one of the two holds. So if a weakness were found in the new algorithm - not impossible, since it’s recent - the traditional one would still protect you; and the other way around, the new part protects against a quantum attack. Belt and braces.
The scheme Chrome turned on is called X25519Kyber768. The name is a mouthful, but it says what’s inside: X25519 is the classic algorithm used for years for key exchange, while Kyber768 is the post-quantum part. At the time of the announcement, Kyber was still a draft of the standard later published by the US agency NIST under the name ML-KEM, the same agency that later picked HQC as a backup algorithm so as not to depend on a single mathematical approach. So it isn’t one vendor’s experiment, but an algorithm the industry is converging on. In later Chrome versions the scheme was updated to the finalized standard.
The side effect: the ClientHello gets bigger
Here’s the part that concerns sysadmins directly. The post-quantum key takes up much more space than the classic one. This inflates the ClientHello, the first message the browser sends to introduce itself to the server at the start of the connection. In that message, the browser lists what it can do, including the keys it offers for the exchange, the same envelope another recent extension, Encrypted Client Hello, tries to encrypt so eavesdroppers can’t read its contents.
With the post-quantum part added, this first message becomes large enough that it no longer fits in a single network packet, so it gets split into two. That isn’t free: according to Google’s announcement, the extra size adds roughly a 4% increase in median latency to all of Chrome’s TLS handshakes on desktop. It’s a small cost, but a real one, and it’s one reason the change reached the desktop first, where connections are usually faster.
Why some devices break
The latency cost was expected. What wasn’t expected is that turning this on by default exposed pre-existing bugs in several products that sit “in the middle” of connections. In the jargon these are called middleboxes: firewalls, proxies, load balancers, and especially TLS inspection systems - devices that peek at or filter encrypted traffic in transit, very common on corporate networks.
In theory, a change like this shouldn’t break anything. TLS is designed to be extensible: if a device runs into an option it doesn’t recognize, the rule is to ignore it and carry on with the ones it does. Offering post-quantum key exchange is therefore backwards-compatible, and standards-compliant systems keep working with no changes. The trouble is that not everything is standards-compliant. Some devices assumed the ClientHello would be small and arrive in a single packet, or handled unexpectedly sized messages poorly. As long as every ClientHello was small, the flaw stayed hidden. The moment the message grew and split across two packets, those devices started rejecting or truncating the connection.
The point to keep in mind: this is not a bug in Chrome, nor in post-quantum cryptography. It’s a pre-existing flaw in a network device that the change simply made visible. Google confirmed that the rollout revealed a number of such bugs in third-party products.
What server operators should check
The typical symptom is clear: after a Chrome update, some users can no longer reach a site or service, while a different browser or version works fine. If that happens, here’s how to proceed.
- Suspect the path, not the browser. The problem is almost never the client or the final server, but something in between: a proxy, a firewall doing TLS inspection, a load balancer, a perimeter security appliance.
- Isolate the cause. Chrome provides an enterprise policy,
PostQuantumKeyAgreementEnabled, that lets you temporarily turn off post-quantum key exchange. If disabling it makes the problem go away, the diagnosis is confirmed: some device can’t handle the larger ClientHello. - Patch the offending device. The correct fix is to ask the vendor for an updated version that handles large messages properly. Disabling via policy is meant as a temporary workaround, to buy time for the fix, not as a permanent state.
- Don’t put it off. Post-quantum key exchange isn’t going away - it’s becoming the norm, so much so that more than half of global web traffic is already post-quantum encrypted. A device that breaks with Chrome today will break tomorrow with other browsers and updated clients. Better to fix it now.
In short
For most people there’s nothing to do: keep the browser and operating system updated, and the protection arrives on its own. For anyone running infrastructure the message is twofold. On one hand it’s good news, because traffic is starting to be protected against a concrete, if still future, threat. On the other it’s a reminder: network gear that inspects or filters TLS needs to be kept updated and standards-compliant, because every evolution of the protocol, from ever-shorter certificate lifetimes to the cryptography of the key exchange itself, can expose shortcuts taken in the past. This is the first wave, not the last.
