Middleboxen: TLS 1.3 soll sich als TLS 1.2 verkleiden

TLS 1.3 kämpft mit Problemen, da viele Middleboxen Verbindungen mit unbekannten Protokollen blockieren. Um das zu verhindern, sollen einige Änderungen dafür sorgen, dass das neue Protokoll wie sein Vorgänger TLS 1.2 aussieht.

Artikel veröffentlicht am 8. November 2017, 11:08 Uhr, Hanno Böck

TLS 1.3 soll maskiert werden - damit es wie das ältere TLS 1.2 aussieht. (Bild: Mykl Roventine/Wikimedia Commons/CC-BY 2.0)

Die kommende Version 1.3 des TLS-Verschlüsselungsprotokolls bringt viele Verbesserungen. Zahlreiche unsichere Mechanismen werden entsorgt und ein neuer Handshake sorgt für bessere Performance, da man sich beim Verbindungsaufbau mindestens einen Roundtrip spart. Doch obwohl TLS 1.3 schon seit Monaten praktisch fertig ist, wurde es bisher nicht final verabschiedet. Der Grund dafür: Bei Tests wurde festgestellt, dass ungewöhnlich viele Verbindungsprobleme mit TLS 1.3 auftreten.

Laut Messungen der Entwickler von Firefox und Chrome schlagen zwischen 1,5 und 3 Prozent der Verbindungen fehl. Schuld daran sind wohl Middleboxen, die versuchen, "intelligent" den Traffic zu analysieren. Allerdings sind die dazu bislang öffentlich bekannten Informationen nur spärlich.

Fehlerhafte Middleboxen sorgen für Verbindungsabbrüche

Offenbar gibt es aber eine ganze Reihe von Geräten, die den Traffic auch analysieren. Traffic von bekannten Protokollen - etwa TLS 1.2 - wird weitergeleitet, aber unbekannter Traffic wird blockiert. Genaue Details, um welche Geräte es sich dabei handelt, sind bisher nicht bekannt. Der einzig bislang öffentlich bekannte Fall sind Geräte von Bluecoat, die mittels Man-in-the-Middle-Angriffen TLS-Datentraffic in Enterprise-Umgebungen mitlesen. Allerdings handelt es sich wohl um deutlich mehr Geräte und in vielen Fällen auch nicht um Man-in-the-Middle-Boxen, sondern um gewöhnliche Router, die Datentraffic eigentlich nur weiterleiten sollten.

Auf der TLS-Mailingliste wurde jetzt ein Vorschlag präsentiert, wie man TLS 1.3 so umbauen könnte, dass es TLS 1.2 ähnlicher wird. Damit sollen die Probleme vermieden und die Fehlerrate gesenkt werden. So sollen die Datenpakete grundsätzlich mit der Versionsnummer von TLS 1.2 (die aus historischen Gründen 3.3 lautet) versendet werden. Außerdem sollen Felder, die in TLS 1.2 nicht mehr genutzt werden, wieder in den Handshake aufgenommen werden, darunter die Kompressionsmethode und eine Session-ID.

Weiterhin soll möglichst früh im Handshake die sogenannte ChangeCipherSpec-Nachricht verschickt werden. Diese CCS-Nachricht diente in TLS 1.2 dazu, den Wechsel von der unverschlüsselten zur verschlüsselten Kommunikation zu signalisieren.

Handshake wurde bereits wegen defekter Server umgebaut

Die Idee dabei: Wenn eine Middlebox eine CCS-Nachricht sieht, muss sie davon ausgehen, dass alle Nachrichten danach verschlüsselt sind - und somit abgesehen von den Headern sowieso nicht analysiert werden können.

Es ist bei weitem nicht das erste Mal, dass solche Entscheidungen getroffen wurden, um Kompatibilität mit faktisch defekten bestehenden Geräten herzustellen.

So wurde der Handshake von TLS 1.3 bereits so umgebaut, dass ein Client scheinbar eine TLS-1.2-Verbindung mit einem Server aufbaut. Dass der Client auch TLS 1.3 unterstützt, wird mit Hilfe einer Erweiterung signalisiert. Der Grund für diese Änderung waren keine Middleboxen, sondern Server, die bei Verbindungsversuchen mit nicht unterstützten TLS-Versionen den Verbindungsaufbau komplett verweigern.

Korrekt arbeitende TLS-1.2-Server müssten bei einem Verbindungsversuch mit einer höheren Version eigentlich lediglich mit der entsprechend niedrigeren Version antworten. Doch zahlreiche Hersteller, darunter Cisco, IBM und Citrix, waren nicht in der Lage, das korrekt zu implementieren.

Früher hatten Browser, um solche Probleme zu umgehen, etwas gemacht, das noch viel problematischer ist: Sie hatten bei Verbindungsproblemen mit neuen TLS-Versionen schlicht einen neuen Verbindungsversuch mit einer älteren TLS-Version unternommen. Das führte dann dazu, dass sämtliche Sicherheitsverbesserungen der neueren TLS-Versionen praktisch nutzlos waren - da ein Angreifer immer durch Verbindungsabbrüche ein Downgrade erzwingen kann.

Frühere Workarounds führten zu Poodle-Angriff

Der Poodle-Angriff zeigte 2014, dass es sich bei diesen Downgrades um ein gravierendes Sicherheitsproblem handelt. Bei Poodle handelte es sich um eine Lücke im Protokoll SSL Version 3. Eigentlich ein uraltes Protokoll, das 2014 niemand mehr verwendet haben sollte. Doch dank der Downgrades konnte man Browser dazu bewegen, eine Verbindung mit dem verwundbaren Uraltprotokoll aufzubauen.

Die jetzt vorgeschlagenen Änderungen an TLS 1.3 sind im Vergleich zu den früheren Versionsdowngrades relativ harmlos. Die kryptographischen Eigenschaften von TLS 1.3, die in vieler Hinsicht ein großer Fortschritt sind, werden dadurch nicht geschwächt. Trotzdem ist das alles aus Sicherheitsgründen alles andere als wünschenswert, da es zusätzliche Komplexität einführt.

Doch für die Browserhersteller ist es aktuell wohl nicht akzeptabel, bei einem signifikanten Teil der Nutzer für Verbindungsabbrüche zu sorgen - auch wenn daran eindeutig die fehlerhaften Middleboxen schuld sind.