[English]Google hat kürzlich seinen Google Chrome-Browser in der Version 124 veröffentlicht. Neben Schwachstellen haben die Entwickler auch etwas an der TLS-Verschlüsselung (X25519Kyber768-Schlüsselkapselung für TLS) geändert. Inzwischen gibt es aber Rückmeldungen von Nutzern, die sich darüber beklagen, dass diese Änderung das TLS-Handshake zu Webservern kaputt machen kann. Das betrifft auch auf Chromium basierende Browser wie den Edge 124.
Chrome 124.0.6367.78/.79
Ich hatte das Update des Chrome-Browsers auf die Version 124 nicht im Blog angesprochen. Zum 24. April 2024 hatte Google den Chrome 124.0.6367.78/.79 für Windows und Mac sowie 124.0.6367.78 für Linux freigegeben. Der Beitrag hier im Google Blog listet vier Sicherheitsfixes für diese Version des Browsers auf.
- [$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
Eine dieser Schwachstellen wird als kritisch aufgeführt. Auch die Chrome-Apps für Android und iOS wurden durch die Chrome-Entwickler aktualisiert. In den Release-Notes für Entwickler und hier findet sich u.a. folgender Hinweis auf eine Neuerung:
X25519Kyber768-Schlüsselkapselung für TLS
Schützt aktuellen Chrome TLS-Traffic vor zukünftigen Quantenkryptoanalysen, indem der quantenbeständige Schlüsselvereinbarungsalgorithmus Kyber768 bereitgestellt wird.
Dies ist eine hybride X25519- und Kyber768-Schlüsselvereinbarung, die auf einem IETF-Standard basiert. Diese Spezifikation und die Einführung liegen außerhalb des Geltungsbereichs von W3C. Diese Schlüsselvereinbarung wird als TLS-Chiffre eingeführt und sollte für Nutzer transparent sein.
Die Entwickler haben also an der TLS-X25519Kyber768-Schlüsselkapselung geschraubt, um die TLS-verschlüsselten Datenströme gegen Quantenkryptoanalysen zu schützen. Das ist aber wohl schief gegangen.
Chrome 124 macht TLS-Handshake kaputt
Mir ist das Thema gleich an zwei Stellen unter die Augen gekommen. Einmal weist Thorsten E. in nachfolgendem Tweet auf ein Problem mit dem TLS-Handshake unter Google Chrome 124 hin, welches auf reddit.com in diesem Beitrag aufgeworfen wurde.
Damit nicht andere Betroffene Stunden der Fehlersuche vergeuden, schreibt der Poster, dokumentiert er eine Änderung im Chrome 124-Browser. Es sieht so aus, dass der Google Chrome 124 eine Einstellung „TLS 1.3 Hybridized Kyber Support“ von deaktiviert auf aktiviert als Standard geändert. Dadurch wird das TLS-Handshake für Server gestört, die dann nicht mehr nicht wissen, was sie mit den zusätzlichen Daten in der Client-Hallo-Nachricht anfangen sollen.
Wer also plötzlich auf mysteriöse Weise eine fehlerhafte Webanwendung hat, und der kontaktierte Server direkt nach dem Client-Hallo einen Reset sendet, könnte dies mit dieser Änderung zu tun haben. Der Tipp des Posters lautet: „Versuchen Sie, diese Einstellung zu deaktivieren. In unseren Tests funktioniert der IE-Modus ebenfalls, wahrscheinlich weil diese zusätzlichen Daten im IE-Modus nicht übertragen werden, während sie im normalen Edge übertragen werden.“ Die Funktion lässt sich in Google Chrome 124 mit dem Flag
chrome://flags/#enable-tls13-kyber
manuell aktivieren. Geht man den reddit.com-Thread durch, berichten Nutzer, dass sie beispielsweise mit FortiGate-Firewalls in der Firmware 7.4.2 bekommen haben und den Web-Filter deaktivieren musste. Das Problem betrifft Sicherheitsanwendungen, Firewalls, Netzwerk-Middleware und verschiedene Netzwerkgeräte von mehreren Herstellern (z. B. Fortinet, SonicWall, Palo Alto Networks, AWS). Parallel dazu bin ich bei den Kollegen von Bleeping Computer auf diesen Artikel gestoßen, der den Sachverhalt ebenfalls thematisiert hat. Die Webseite tldr.fail hält noch einige Hinweise zum Thema post-quantum-sichere Kryptographie bereit.
Also ich habe mit 124.0.6367.92 keine Probleme, weder auf IIS noch Apache. Ich glaube eher die ganzen Middelwarekisten die TLS aufbrechen haben damit Probleme.
Bitte an die jungen Fachinformatiker in Ausbildung, die hier ebenfalls mitlesen, denken und korrekte Bezeichnungen verwenden. Sie denken wohl an Proxies und Firewalls, diese sind aber keine Middleware (1), auch wenn sie sich gewissermassen in der Mitte zwischen Client und Server befinden.
(1) de.wikipedia.org/wiki/Middleware#Typische_Middlewareprodukte
Im Artikel steht Netzwerkmiddleware, ja „Firewalls“ die halt TLS aufbrechen, denke die Leute wissen was gemeint ist.
Zyxel hatte das auch mal aber mit TLS 1.3. Deren „Lösung“ war einfach alle TLS 1.3-Verbindungen zu killen bis sie dann später mal ein Update nachgeschoben hatten welches das dann kann.
Ja, es scheint nicht Chrome der „Schuldige“ an diesem Problem zu sein, sondern viele der den Datenstrom inspizierenden Middleware-Kisten. Ich denke, man sollte Google hier eher loben – ohne die Konfigurationsänderung in der neuen Browser-Version würde sich hier gar nix bewegen.
Jetzt kommen die Anbieter wenigstens unter Druck, den Standard zu implementieren. Das kann auf keinen Fall schaden, zumal es ja einen Workaround gibt. Jetzt sind aber die Käufer der Middleware in der Pflicht, die Anbieter zur Reparatur der nicht standardkonformen Firmwares zu drängen.
Mit aktiver SSL Inspektion Firewall hatten wir nach dem Edge Chrome Update auch einige Webseiten die ein Problem hatten. Dann Per GPO für Edge und Chrome deaktiviert hat Abhilfe geschaffen.
Hallo Hans.
Welche GPO hast du dann angewendet?
Jep.
Proxy macht Troubles mit v124 und TLS
Das Problem ist imho kein Problem der Browser, sondern von veralteten oder schlecht konfigurierten Webservern. Wir werden also primär Updates bei Fortinet etc sehen, und maximal temporäre Workarounds für Chrome/Edge.
https://windowsreport.com/chrome-124-and-edge-124-cant-handle-tls-connections-due-to-quantum-resistant-encryption-key/
Daher schon gut, dass Chrome dass forciert hat. Damit werden einige Firmen aus dem Dornröschenschlaf geweckt.