Downgrade-Schutz sorgt für Probleme mit Enterprise-Geräten

Weiterhin gibt es ein Problem mit sogenannten TLS-Interception-Devices und einem Schutzmechanismus vor Downgrade-Angriffen. Im TLS-Handshake wird ein Zufallswert übertragen. Server, die TLS 1.3 unterstützen, sollen bei Verbindungen mit alten TLS-Versionen die letzten acht Bytes auf einen speziellen, im Standard definierten Wert setzen. Wenn ein Client diese Bytes sieht und selber eigentlich TLS 1.3 unterstützt, weiß er dadurch, dass beim Handshake etwas schiefgelaufen ist, weil eigentlich eine Verbindung mit TLS 1.3 hätte aufgebaut werden sollen.

Ein Problem tritt nun bei bestimmten Geräten auf, die TLS-Verbindungen aufbrechen und somit quasi als Man in the Middle agieren. Solche Geräte sind generell sehr umstritten, wenn sie korrekt implementiert sind, sollten sie aber zumindest nicht zu Verbindungsproblemen führen.

Einige Hersteller kamen auf die Idee, den Zufallswert des Servers einfach weiterzureichen, statt für die Verbindung zum Client einen eigenen, neuen Zufallswert zu erzeugen. Nun tritt folgendes Problem auf: Wenn das Gerät in der Mitte kein TLS 1.3 kann, Client und Server aber schon, sendet der Server das Downgrade-Protection-Signal und es kommt beim Client an. Der Client hat aber mit dem Gerät nur eine TLS-1.2-Verbindung aufgebaut und erkennt daher einen Downgrade-Angriff. Die Verbindung schlägt fehl.

Cisco bietet Update an, Palo Alto Networks noch nicht

Das Chrome-Team konnte zwei Hersteller identifizieren, die diesen Fehler machen: Cisco und Palo Alto Networks. Chrome hatte das Problem an Cisco bereits im Dezember 2017 gemeldet, im August wurde dann ein Update veröffentlicht. Nutzer von entsprechenden Cisco-Produkten sollten dieses Update schnell installieren - oder alternativ die TLS-Interception-Funktion ganz abschalten.

Palo Alto Networks hat bisher noch kein Update veröffentlicht, es soll Ende November erscheinen. Möglicherweise gibt es weitere Geräte mit ähnlichen Fehlern, die bisher nicht identifiziert wurden.

Chrome wird aufgrund dieser Probleme den Downgrade-Check zeitweise deaktivieren. Laut Benjamin gibt es zwar einen weiteren Check im Rahmen der Finished-Message, der auch vor Downgrade-Angriffen schützt, doch das Chrome-Team sieht den Check mit dem Server-Zufallswert trotzdem als wichtiges Sicherheitsfeature an. Mittelfristig will Chrome den Check daher wieder anschalten.

Versionsintoleranz, scheinbar intelligente Trafficanalyse und eine NSA-Hintertüre

Diese Probleme reihen sich ein in eine ganze Reihe von Bugs, die dafür gesorgt haben, dass die Auslieferung von TLS 1.3 erschwert wurde. So gibt es zahlreiche Geräte, die bei einer Verbindung mit einer ihnen nicht bekannten neuen TLS-Version schlicht die Verbindung abbrechen, statt eine Verbindung mit einer älteren TLS-Version aufzubauen. Diese sogenannte Versionsintoleranz hat dazu geführt, dass TLS 1.3 sich zunächst auch als TLS 1.2 meldet, die eigentliche Version wird dann in einer Erweiterung mitgeteilt.

Zudem sorgte kurioserweise eine vermutlich von der NSA entwickelte Erweiterung, die Teil einer groß angelegten Operation zur Kompromittierung eines Zufallszahlengenerators war, dafür, dass Verbindungen mit einigen Canon-Druckern fehlschlugen.

TLS-Interception-Geräte von Blue Coat und zahlreiche Middleboxen, die versuchen, TLS-Verbindungen scheinbar intelligent zu analysieren, kamen zudem nicht damit klar, dass TLS-1.3-Pakete deutlich anders aussehen als die Vorgänger. Daher hat man TLS 1.3 so umgebaut, dass es seinem Vorgänger 1.2 möglichst ähnlich sieht, und dafür teilweise Nonsens-Nachrichten ins Protokoll eingebaut, die schlicht ignoriert werden.

In all diesen Fällen handelt es sich um Fehler der jeweiligen Hersteller. Nichts davon wäre nötig gewesen, wenn alte TLS-Versionen korrekt implementiert worden wäre.