IETF: Wie TLS abgehört werden könnte
Der Vorschlag für eine TLS-Erweiterung macht TLS effektiv kaputt, sagen dessen Kritiker. Befürworter begründen die Idee mit Enterprise-Szenarien im Rechenzentrum. Streit ist vorprogrammiert und zeigt sich deutlich beim Treffen der TLS-Arbeitsgruppe.

Noch eine Stunde nach dem offiziellen Ende der TLS-Arbeitsgruppensitzung auf dem IETF Meeting 99 in Prag diskutiert Daniel Kahn Gillmor mit vielen anderen über einen Vorschlag, der das Verschlüsselungsprotokoll TLS 1.3 kaputt machen könnte. Das zumindest ist die Meinung von Gillmor, der sich für die US-Bürgerrechtsorganisation ACLU in den Standardisierungsgremien und Arbeitsgruppen der IETF für die Wahrung von Privatsphäre und Menschenrechten aller Internetnutzer einsetzt.
- IETF: Wie TLS abgehört werden könnte
- Beherzte Diskussion ohne Lösung
Dass es zu derart langen und durchaus auch hitzigen Diskussionen zu dem Thema kommt, ist bei der auf Konsensentscheidungen ausgelegten IETF zwar eher ungewöhnlich, war aber in dem konkreten Fall abzusehen. Auch deshalb haben die Vorsitzenden der TLS-Arbeitsgruppe im Vorfeld der Diskussion mehrfach darum gebeten, sich doch bitte zivilisiert und professionell zu verhalten.
Statische Schlüssel zur Analyse
Grundlage für die Diskussion ist nicht nur der Zeitpunkt - immerhin ist die lange Phase der Standardisierung von TLS 1.3 schon so gut wie abgeschlossen - sondern vor allem der Inhalt eines Entwurfs, der als Erweiterung zu TLS 1.3 gedacht ist und den Einsatz des Protokolls in Rechenzentren beschreiben soll. Während die erste Version des Entwurfs noch als rein informativ gedacht war, soll die aktuelle Version der Unterstützung zufolge als Internet-Standard verabschiedet werden.
Motivation für den Entwurf ist laut dem Vortrag (PDF), dass die mit TLS 1.3 zwingend eingeführten Konzepte es Betreibern sehr großer Rechenzentren und Anwendungen wie etwa Google angeblich erschweren, Fehler zu finden und zu beheben. Die dadurch verlängerte Zeit der Fehlersuche und Lösung komme gar einem DDOS-Angriff gleich, heißt im Vortrag zu dem Entwurf.
So könnte etwa der Traffic auf Load-Balancern, Firewall-Applikationen oder anderen Fronting-Servern, die vor dem eigentlichen Serverendpunkt der TLS-Verbindung liegen, aufgrund der Verschlüsselung im Falle eines Fehlers nicht ausreichend analysiert werden.
Statt diese Problem etwa auf Ebene des Deployments oder der Dienste-Architektur zu lösen, soll dem Entwurf zufolge das Problem direkt auf der Protokollebene von TLS gelöst werden. Vorgeschlagen wird dafür ein "statischer Diffie-Hellman-Schlüssel", der auf dem TLS-Server erzeugt wird oder auf einem zentralen Key-Management-Server und anschließend im Rechenzentren weiterverteilt werden kann.
Statt dem eigentlich von TLS vorgesehenen pro Sitzung vom Server erzeugten Schlüssel soll für den Handshake der "statische Schlüssel" gemeinsam mit einem zufälligen Nonce-Wert zum Aufbau der Verbindung genutzt werden. Die Betreiber der Rechenzentren könnten den "statischen Schlüssel" dann verwenden, um intern Traffic zur weitergehenden Analyse bei der Fehlersuche zu entschlüsseln.
Angriff auf Perfect Forward Secrecy
Nach Meinung der Gegner dieses Vorschlags wird damit aber das Prinzip der Perfect Forward Secrecy (PFS) unterlaufen. Hierbei wird die Verschlüsselung selbst dann noch geschützt, wenn der langfristige Serverschlüssel, der Teil des Zertifikats ist, kompromittiert wird. Selbst wenn ein Angreifer nachträglich den Server hackt oder auf andere Weise an den geheimen Schlüssel kommt, ermöglicht das nicht das Entschlüsseln von Verbindungen aus der Vergangenheit.
Damit diese Prinzip funktioniert, müssen die Schlüssel pro Sitzung neu generiert werden, was bei der beschriebenen Verwendung der statischen Schlüssel eben nicht konsequent der Fall ist, auch wenn dies zumindest aus Sicht des Clients der Fall wäre. Die Umsetzung von PFS ist eines der Hauptziele von TLS 1.3.
Ein Versuch der Bankenlobby, das PFS-Prinzip in TLS 1.3 durch die Wiedereinführung des RSA-Handshakes zu umgehen, hatte die TLS-Arbeitsgruppe im Herbst vergangenen Jahres noch sehr klar verhindert. Der aktuelle Entwurf mit den "statischen Schlüsseln" nimmt laut Entwurf explizit Bezug auf die RSA-Handshakes und versucht, das damit umgesetzte Monitoring auf die Technik von TLS 1.3 zu übertragen.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Beherzte Diskussion ohne Lösung |
- 1
- 2
"ich seh den standard erfüllt, sobald zwei unterschiedliche implementierungen miteinander...
DNS ist eine Grundsäule des Internets, meinst du vielleicht eher DRM? ;) Webstandards...
irgendwie sinnlos, über so ein detail nachzudenken, das sich nur innerhalb der...
"Und da es hier um spezielle Bereiche geht, sollte die Entscheidung beim Dienstbetreiber...