Google Chrome

Some ​Google Chrome users report having issues connecting to websites, servers, and firewalls after Chrome 124 was released last week with the new quantum-resistant X25519Kyber768 encapsulation mechanism enabled by default.

Google started testing the post-quantum secure TLS key encapsulation mechanism in August and has now enabled it in the latest Chrome version for all users.

The new version utilizes the Kyber768 quantum-resistant key agreement algorithm for TLS 1.3 and QUIC connections to protect Chrome TLS traffic against quantum cryptanalysis.

"After several months of experimentation for compatibility and performance impacts, we're launching a hybrid postquantum TLS key exchange to desktop platforms in Chrome 124," the Chrome Security Team explains.

"This protects users' traffic from so-called 'store now decrypt later' attacks, in which a future quantum computer could decrypt encrypted traffic recorded today."

Store now, decrypt later attacks are when attackers collect encrypted data and store it for the future when there may be new decryption methods, such as using quantum computers or encryption keys become available.

To protect against future attacks, companies have already started to add quantum-resistant encryption to their network stack to prevent these types of decryption strategies from working in the future. Some companies that have already introduced quantum-resistant algorithms include AppleSignaland Google.

However, as system admins have shared online since Google Chrome 124 and Microsoft Edge 124 started rolling out on desktop platforms last week, some web applications, firewalls, and servers will drop connections after the ClientHello TLS handshake.

The issue also affects security appliances, firewalls, networking middleware, and various network devices from multiple vendors (e.g., Fortinet, SonicWall, Palo Alto Networks, AWS).

"This appears to break the TLS handshake for servers that do not know what to do with the extra data in the client hello message," one admin said.

"Same problem here since version 124 of Edge, it seems to go wrong with the SSL decryption of my palo alto," said another admin.

These errors are not caused by a bug in Google Chrome but instead caused by web servers failing to properly implement Transport Layer Security (TLS) and not being able to handle larger ClientHello messages for post-quantum cryptography.

This causes them to reject connections that use the Kyber768 quantum-resistant key agreement algorithm rather than switching to classic cryptography if they don't support X25519Kyber768.

A website named tldr.fail was created to share additional information on how large post-quantum ClientHello messages can break connections in buggy web servers, with details on how developers can fix the bug.

Website admins can also test their own servers by manually enabling the feature in Google Chrome 124 using the chrome://flags/#enable-tls13-kyber flag. Once enabled, admins can connect to their servers and see if the connection causes an "ERR_CONNECTION_RESET" error.

How to fix connection issues

Affected Google Chrome users (who are also seeing "Error 525: SSL handshake failed" errors) can mitigate the issue by going to chrome://flags/#enable-tls13-kyber and disabling the TLS 1.3 hybridized Kyber support in Chrome.

Administrators can also disable it by toggling off the PostQuantumKeyAgreementEnabled enterprise policy under Software > Policies > Google > Chrome or contacting the vendors to get an update for servers or middleboxes on their networks that aren't post-quantum-ready.

Microsoft has also released information on how to control this feature via the Edge group policies.

However, it's important to note that long-term, post-quantum secure ciphers will be required in TLS, and the Chrome enterprise policy allowing disabling it will be removed in the future.

"Devices that do not correctly implement TLS may malfunction when offered the new option. For example, they may disconnect in response to unrecognized options or the resulting larger messages," Google says.

"This policy is a temporary measure and will be removed in future versions of Google Chrome. It may be Enabled to allow you to test for issues, and may be Disabled while issues are being resolved."

Related Articles:

Chrome Enterprise gets Premium security but you have to pay for it

Google fixes one more Chrome zero-day exploited at Pwn2Own

New Chrome feature aims to stop hackers from using stolen cookies

Google fixes Chrome zero-days exploited at Pwn2Own 2024

Google fixes fifth Chrome zero-day exploited in attacks this year