Chrome 124 breaks TLS handshake

[German]Google recently released version 124 of its Google Chrome browser. In addition to vulnerabilities, the developers have also made some changes to the TLS encryption (X25519Kyber768 key encapsulation for TLS). However, there is now feedback from users complaining that this change can break the TLS handshake to web servers. This also affects Chromium-based browsers such as Edge 124.

Chrome 124.0.6367.78/.79

I hadn't mentioned the update of the Chrome browser to version 124 in the blog. On April 24, 2024, Google released Chrome 124.0.6367.78/.79 for Windows and Mac and 124.0.6367.78 for Linux. The post here on the Google blog lists four security fixes for this version of the browser.

• [$16000][332546345] Critical CVE-2024-4058: Type Confusion in ANGLE. Reported by Toan (suto) Pham and Bao (zx) Pham of Qrious Secure on 2024-04-02
• [TBD][333182464] High CVE-2024-4059: Out of bounds read in V8 API. Reported by Eirik on 2024-04-08
• [TBD][333420620] High CVE-2024-4060: Use after free in Dawn. Reported by wgslfuzz on 2024-04-09

One of these vulnerabilities is listed as critical. The Chrome apps for Android and iOS have also been updated by the Chrome developers. The release notes for developers and here include the following reference to a new feature:

X25519Kyber768 key encapsulation for TLS

Protects current Chrome TLS traffic against future quantum cryptanalysis by deploying the Kyber768 quantum-resistant key agreement algorithm.

This is a hybrid X25519 and Kyber768 key agreement based on an IETF standard. This specification and launch is outside the scope of W3C. This key agreement will be launched as a TLS cipher, and should be transparent to users.

The developers have therefore tinkered with the TLS-X25519Kyber768 key encapsulation to protect the TLS-encrypted data streams against quantum cryptanalysis. But that probably went wrong.

Chrome 124 breaks TLS handshake

I came across this issue in two places. Firstly, Thorsten E. points out a problem with the TLS handshake under Google Chrome 124 in the following tweet, which was raised in this post on reddit.com.

To prevent others affected from wasting hours of troubleshooting, the poster writes, he documents a change in the Chrome 124 browser. It looks like the Google Chrome 124 changed a setting "TLS 1.3 Hybridized Kyber Support" from disabled to enabled by default. This disrupts the TLS handshake for servers, which then no longer know what to do with the additional data in the client hello message.

So anyone who suddenly mysteriously has a faulty web application and the contacted server sends a reset directly after the client hello could have something to do with this change. The poster's tip is: "Try disabling this setting. In our tests, IE mode also works, probably because this additional data is not transmitted in IE mode, while it is transmitted in normal Edge." The function can be enabled in Google Chrome 124 with the flag

chrome://flags/#enable-tls13-kyber

f you go through the reddit.com thread, users report that they have, for example, gotten FortiGate firewalls in firmware 7.4.2 and had to disable the web filter. The issue affects security applications, firewalls, network middleware and various network devices from multiple vendors (e.g. Fortinet, SonicWall, Palo Alto Networks, AWS). At the same time, I came across this article from my colleagues at Bleeping Computer, which also addressed the issue. The website tldr.fail has some more information on the topic of post-quantum secure cryptography.