Original-URL des Artikels: https://www.golem.de/news/verschluesselung-tls-1-3-mit-startschwierigkeiten-1810-137097.html    Veröffentlicht: 13.10.2018 11:17    Kurz-URL: https://glm.io/137097

Verschlüsselung

TLS 1.3 mit Startschwierigkeiten

Obwohl bei der Entwicklung von TLS 1.3 versucht wurde, Probleme mit bestehenden fehlerhaften Geräten zu vermeiden, gibt es beim Start erneut Schwierigkeiten. Verantwortlich dafür: Vorab-Versionen von OpenSSL und Geräte von Cisco und Palo Alto Networks.

Es ist eine scheinbar unendliche Geschichte: Fehlerhaft implementierte Geräte im Internet sorgen dafür, dass die Verwendung der neuen TLS-Version 1.3 blockiert wird. Einem Bericht von Chrome-Entwickler David Benjamin zufolge gibt es jetzt weitere Probleme. Chrome will mit der kommenden Version 70 TLS 1.3 aktivieren.

Einige Testversionen von OpenSSL bieten fehlerhafterweise eine Entwurfsversion von TLS 1.3 an. Bugs in Geräten von Cisco und Palo Alto Networks sorgen außerdem dafür, dass ein Schutzmechanismus vor Downgradeangriffen vorläufig nicht genutzt werden kann.

Testversionen von OpenSSL 1.1.1 sollten dringend aktualisiert werden

Eigentlich war vorgesehen, dass alle Implementierungen, die testweise die unfertigen Versionen von TLS 1.3 anbieten, speziell reservierte eigene Versionsnummern verwenden. Denn TLS 1.3 ist über mehrere Jahre entwickelt und dabei immer wieder stark verändert worden, insgesamt gab es 28 Entwurfsversionen. Ein Versuch, mit unterschiedlichen Entwurfsversionen oder zwischen der finalen Version und Vorabversionen eine Verbindung aufzubauen, scheitert daher in aller Regel.

In Testversionen von OpenSSL 1.1.1-pre6 und früher gab es allerdings einen Bug: OpenSSL akzeptiert auch die finale Versionsnummer von TLS 1.3 und versucht, damit eine Verbindung mit der damaligen Vorabversion aufzubauen. Das Problem: Offenbar haben einige diese OpenSSL-Testversion auf ihren Servern installiert und seitdem nicht mehr aktualisiert.

Wer seinen Server mit einer Testversion von OpenSSL 1.1.1 betreibt, sollte daher unbedingt umgehend auf die finale Version umstellen, die im September veröffentlicht wurde. Alternativ kann man laut Benjamin auch die Unterstützung von TLS-1.3-Drafts deaktivieren und nur Verbindungen mit dem älteren TLS 1.2 zulassen. Andernfalls muss man bald mit Verbindungsfehlern rechnen: Das Chrome-Team plant nicht, aufgrund dieses Problems die Aktivierung von TLS 1.3 zu verzögern.



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.  (hab)


Verwandte Artikel:
Dual EC: Wie Cisco, Avast und die NSA TLS 1.3 behindern   
(19.12.2017, https://glm.io/131758 )
HTTPS: Noch immer viele Symantec-Zertifikate aktiv   
(12.10.2018, https://glm.io/137093 )
MTA-STS: Neuer Standard sichert Verschlüsselung zwischen Mailservern   
(28.09.2018, https://glm.io/136853 )
Container: Kubernetes 1.12 bringt TLS-Bootstrapping   
(28.09.2018, https://glm.io/136857 )
Enigmail/Pep: Klartext-Mails trotz angeblicher Verschlüsselung   
(04.10.2018, https://glm.io/136931 )

© 1997–2020 Golem.de, https://www.golem.de/