ETLS: ETSI veröffentlicht unsichere TLS-Variante
Die europäische Standardisierungsorganisation ETSI hat eine Variante von TLS spezifiziert, die eine Überwachungsschnittstelle und schwächere Sicherheitseigenschaften hat. Bei der IETF war man zuvor mit ähnlichen Vorstößen erfolglos.

Eine Variante von TLS mit weniger Sicherheit? Dass eine solche notwendig ist, glaubt offenbar die europäische Standardisierungsorganisation ETSI. Mit Enterprise TLS oder kurz ETLS spezifiziert sie eine Variante des neuen Verschlüsselungsstandards TLS 1.3, die auf Forward Secrecy verzichtet und eine Überwachung des Datenverkehrs ermöglicht. Welche Auswirkungen das auf die Sicherheit des Protokolls hat, ist unklar.
Der Hintergrund des ganzen: In älteren TLS-Protokollversionen war es üblich, Verschlüsselungsmodi einzusetzen, bei denen der Datenverkehr mit einem immer gleich bleibenden RSA-Schlüssel abgesichert wurde. Doch optional gab es bereits Modi mit sogenannter Forward Secrecy. Hierbei wird der Schlüssel des Servers nur noch genutzt, um den Handshake zu signieren, die eigentliche Verschlüsselung findet mit einem Sitzungsschlüssel statt, der mit dem Diffie-Hellman-Verfahren ausgehandelt wird. Von Diffie Hellman gibt es dabei eine klassische Variante und eine neuere auf Basis elliptischer Kurven.
TLS 1.3 nutzt immer Forward Secrecy
Bei TLS 1.3 wurde frühzeitig beschlossen, den klassischen RSA-Modus komplett zu entfernen. Aus Sicht der Sicherheit ein Vorteil: Bei den moderneren Modi kann auch ein Angreifer, der den Datenverkehr aufzeichnet und später in den Besitz des Serverschlüssels gelangt, den Datenverkehr nicht entschlüsseln. Dies wird als Forward Secrecy bezeichnet.
Genau diese Eigenschaft ist aber nach Ansicht mancher ein Problem. Im September 2016 meldete sich ein Vertreter des Bankenlobbyverbandes BITS bei der TLS-Arbeitsgruppe und beklagte sich, dass die Entfernung des RSA-Modus Probleme für die Netzwerküberwachung in internen Netzen mit sich bringe. Denn bisher war es möglich, eine TLS-Verbindung aufzubauen und passiv den Datenverkehr mitzulesen. Dafür benötigt man den privaten Schlüssel des Servers. Mit TLS 1.3 ist ein solches Szenario nicht mehr möglich.
In der TLS-Arbeitsgruppe fanden diese Einwände jedoch keine offenen Ohren. Die vorherrschende Ansicht dort war, dass es das erklärte Ziel von TLS ist, die Überwachung so schwer wie möglich zu machen. Es folgten zahlreiche Versuche von Industrievertretern, bei der IETF eine TLS-Variante mit Überwachungsschnittstelle zu spezifzieren, doch die konnten sich dort nicht durchsetzen.
Nun wurde eine entsprechende Variante über den Umweg der ETSI spezifiziert. Die Idee von ETLS ist im Grunde relativ simpel: Ein Server nutzt zwar weiterhin Diffie Hellman, er verwendet aber immer denselben temporären Diffie-Hellman-Schlüssel. Dieser bleibt dann über einen längeren Zeitraum identisch. Mit dieser Variante kann ein Gerät, das den Datenverkehr mitschneidet, diesen entschlüsseln, wenn es Kenntnis des temporären Schlüssels hat.
Auch ein valider TLS-1.3-Client kann mit solch einem ETLS-Server weiterhin kommunizieren, denn an den Protokollnachrichten ändert sich ansonsten nichts. Der Client könnte allerdings erkennen, dass der Server immer denselben temporären Diffie-Hellman-Schlüssel verwendet.
Die Frage bleibt: Ist eine solche TLS-Variante mit Überwachungsschnittstelle überhaupt nötig? Theoretisch wäre es auch denkbar, dass entweder der Server oder der Client den jeweiligen Sitzungsschlüssel bei jeder Verbindung an die entsprechende Middlebox weiterleiten. Damit könnte man dem Wunsch nach einer Überwachung des Datenverkehrs nachkommen, wenn zumindest einer der Kommunikationsteilnehmer aktiv daran beteiligt ist.
Doch eine solche Lösung sei untauglich, schreibt die ETSI im ETLS-Standard. Es sei zu schwierig zu gewährleisten, dass der Schlüssel immer rechtzeitig übermittelt wird und dieser Ansatz skaliere nicht für die Bedürfnisse der Betreiber von Rechenzentren.
ETLS kommt ohne Sicherheitsanalyse
Die ETSI bewirbt ihr verändertes TLS-Protokoll damit, dass es von der Industrie für die Industrie entwickelt wurde. Wozu die ETSI wenig sagt, ist die Sicherheit des neuen Protokolls. Der Abschnitt Security in der Protokollspezifikation ist lediglich eine halbe Seite lang.
Darin wird erklärt, dass ETLS keine Forward Secrecy gewährleistet. Das ist soweit trivial und ergibt sich fast automatisch aus der Protokollspezifikation. Bemerkenswert ist aber, dass ETLS offenbar keiner detaillierten Sicherheitsanalyse unterzogen wurde. So findet sich kein einziger Verweis auf irgendwelche wissenschaftlichen Arbeiten oder Sicherheitsanalysen, die das Protokolldesign untersuchen, im Standard.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Die Sicherheit an sich ist nicht futsch. Der reine Transport der Daten ist auch weiterhin...
Jaein. Für eTLS muss die Gegenseite AKTIV mitspielen und den Mittelboxen entsprechende...
Das kann der Browserhersteller nicht viel machen, da eine ETLS-Verbindung nicht leicht zu...
Nope - der hat nix in der Digitalen Welt zu sagen. Glaube kaum das Google oder Mozilla da...