Some Google Chrome users reported about problems connecting to sites, servers and firewalls that began after the release of Chrome 124 last week. This version of the browser features the new X25519Kyber768 quantum-resistant encapsulation engine enabled by default.
Google begins testing a new quantum-resistant TLS key encapsulation mechanism in August last year, and in the latest version of Chrome activated it for all browser users. The new version of Chrome uses the Kyber768 key agreement algorithm for TLS 1.3 and QUIC connections to protect Chrome's TLS traffic from future post-quantum attacks.
Advertisement
“After several months of compatibility and performance experiments, we are launching hybrid post-quantum TLS key exchange for desktop in Chrome 124,” wrote Chrome Security Team specialists. “This will protect user traffic from “store now, decrypt later” attacks, in which a future quantum computer will be able to decrypt encrypted traffic recorded today.”
“Store now, decrypt later” attacks involve attackers collecting encrypted data and storing it for future use, until new decryption methods such as quantum computers become available (or encryption keys become available).
To protect against such attacks in the future, companies (including Apple, Signal, and Google) have already begun adding quantum-resistant encryption to their stack to prevent such tactics from being used.
However, since the release of Google Chrome 124 and Microsoft Edge 124, some web applications, firewalls, and servers drop connections after the ClientHello TLS handshake. The issue also affects security hardware, firewalls, network middleware, and other network devices from various vendors (e.g., Fortinet, SonicWall, Palo Alto Networks, AWS).
“This appears to break the TLS handshake for servers that don't know what to do with the extra data in the client hello message,” says one affected admin.
“Same issue since version 124 Edge, something seems to be going wrong with SSL decryption on my PaloAlto,” another admin wrote.
It appears that these failures are not due to a bug in Chrome, but to the fact that web servers cannot implement TLS correctly and are unable to process the increased ClientHello messages required for quantum-resistant protection. They end up rejecting connections using the quantum-resistant Kyber768 algorithm instead of moving to classical cryptography if X25519Kyber768 is not supported.
Advertisement
Edition Bleeping Computer notes that a website has already been created to collect and disseminate information about this problem tldr.fail.
Thus, site administrators are encouraged to test their servers by manually activating the new feature in Google Chrome 124 using the chrome://flags/#enable-tls13-kyber flag. Once the feature is enabled, administrators can connect to their servers and check if this is triggering an “ERR_CONNECTION_RESET” error.
Affected Chrome users can resolve the issue by going to chrome://flags/#enable-tls13-kyber and disabling TLS 1.3 hybridized Kyber support in the browser.
Administrators can also disable this feature using policy PostQuantumKeyAgreementEnabled via Software -> Policies -> Google -> Chrome or by contacting vendors to obtain updates for hardware that is not post-quantum ready.
Microsoft has already published detailed instructions to manage this feature using Edge Group Policies.
However, journalists note that in the long term, post-quantum protection will be necessary for TLS, and Chrome's corporate policy to disable this functionality will be removed in the future.
“Devices that do not implement TLS correctly may malfunction when faced with the new option. For example, they may drop the connection in response to unrecognized options or larger messages, Google says. — This policy is a temporary measure and will be removed in future versions of Google Chrome. It can be turned on so you can check for problems, and it can also be turned off while they are being resolved.”