Original-URL des Artikels: https://www.golem.de/news/ietf-wie-tls-abgehoert-werden-koennte-1707-129040.html    Veröffentlicht: 20.07.2017 14:00    Kurz-URL: https://glm.io/129040

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.

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.

Beherzte Diskussion ohne Lösung

Auf die Vorstellung des Entwurfs auf der Sitzung sowie seiner Motivation folgte ein Vortrag, der eine lange Liste technischer sowie prinzipieller Probleme damit aufführt. In dem zugrunde liegenden ausformulierten Dokument wird immer wieder darauf hingewiesen, dass der konkrete Vorschlag TLS kaputt macht und derartige Vorschläge auch in der Vergangenheit immer wieder von der TLS-Arbeitsgruppe verworfen worden sind.

In der anschließenden Diskussion gab es wie zu erwarten sehr viele Wortmeldungen von Unterstützern und Gegnern des Vorschlags. Mark Nottingham, der Vorsitzende der HTTP-Arbeitsgruppe, bezeichnet das Aufreihen in einer Schlange am Mikrofon auf Twitter gar als Beginn des TLS-Fight-99.

In seiner eigenen Wortmeldung weist Nottingham daraufhin, dass der Entwurf mit den "statischen Schlüsseln" wie erwähnt eben wieder nur ein erneuter Versuch der Bankenlobby sei, die Verschlüsselung kaputtzumachen, und die IETF den Vorschlag nicht weiter diskutieren solle. Ähnliche Versuche bei der Standardisierung von HTTP/2, die darauf hinwirkten, auf eine Verschlüsselung zu verzichten, habe seine Arbeitsgruppe größtenteils verhindert, die TLS-Arbeitsgruppe solle diesem Beispiel folgen, so Nottingham.

Ein in der Diskussion vorgebrachter Vorschlag eines Red-Hat-Entwicklers sieht sogar vor, die Spezifikation von TLS 1.3 so zu ändern, dass der Server ständig neue Schlüssel für Sitzungen erzeugen muss. Der diskutierte Vorschlag der "statischen Schlüssel" wäre damit nicht mehr haltbar.

Unterstützt wird der Entwurf dagegen von Mitarbeitern großer Unternehmen, die offenbar alle ähnliche Probleme haben. Dazu gehören unter anderem Cisco oder auch "Finanzinstitute", die von deren Vertretern in der öffentlichen Diskussion allerdings nicht weiter namentlich genannt werden.

Neben völliger Opposition und totaler Unterstützung des Entwurfs gibt es auch einige wenige moderate Zwischentöne, die Verständnis für die geschilderten Probleme der Unternehmen äußern, diese aber auch auffordern, ihr Deployment zu überdenken und nach anderen Lösungswegen zu suchen, als TLS zu zerstören.

Im Gespräch mit Golem.de sagte dazu einer der Beteiligten, der anonym bleiben möchte, dass vor allem die Suche nach alternativen Lösungswegen den Unternehmen wohl schlicht zu viel Geld koste und das Zerstören von TLS günstiger umzusetzen sei.

IETF-Prinzipien stehen zur Diskussion

Derartige Überlegungen, die eher moralische und gesellschaftspolitische Bedeutung haben, sind trotz des sehr technischen Charakters der IETF auch innerhalb der Organisation wichtig bei der Entscheidungsfindung. So gibt es etwa eine Anleitung der IETF, Protokolle auf mögliche Probleme für die Privatsphäre der Nutzer hin zu überprüfen. Eine der Co-Autorin dieser Anleitung ist die aktuelle IETF-Vorsitzende Alissa Cooper.

Darüber hinaus gibt es in der IRTF, der auf Forschung ausgelegten Schwesterorganisation der IETF, eine Arbeitsgruppe für die Untersuchung von Protokollen auf ihren Auswirkungen auf die universellen Menschenrechte. Der Co-Vorsitzenden dieser Arbeitsgruppe, der studierte Philosoph, Journalist und Software-Entwickler Niels ten Oever kommentiert die Diskussion der TLS-Arbeitsgruppe auf Twitter mit einer Sammlung sarkastischer Memes, mit denen sich ten Oever klar gegen den diskutierten Entwurf ausspricht.

Ist das Abhören?

Zusätzlich zu den Arbeiten zur Privatsphäre und den Menschenrechten gibt es eine weitere Richtlinie der IETF mit informativem Charakter, die beschreibt, dass die Organisation keinerlei Anforderungen an die Abhörmöglichkeiten von Protokollen als Teil ihres Standardisierungsprozesses machen darf.

Die Vorsitzenden der TLS-Arbeitsgruppe wählen am Ende der Sitzung deshalb zusätzlich zu der Frage, ob der Entwurf weiter betrachtet werden soll, die Formulierung (PDF): "Ist das Abhören?" Das anschließende Stimmungsbild der Anwesenden auf diese Frage, das bei der IETF traditionell durch Humming, Brummen, ausgedrückt wird, ist wie zu erwarten klar gespalten. Das Brummen beider Seiten ist ungefähr gleich laut.

Die TLS-Arbeitsgruppe wird sich also wohl weiter mit dem Vorschlag beschäftigen. Doch was das genau heißen soll, ist für den ACLU-Vertreter Gillmor nicht ganz klar. Denn für ihn steht fest: "Solange wir uns damit beschäftigen, werde ich solche Vorschläge entschieden zurückweisen".  (sg)


Verwandte Artikel:
IETF: Netzwerker wollen Quic-Pakete tracken   
(21.07.2017, https://glm.io/129072 )
Verschlüsselung: TLS 1.3 ist so gut wie fertig   
(16.02.2018, https://glm.io/132828 )
Dual EC: Wie Cisco, Avast und die NSA TLS 1.3 behindern   
(19.12.2017, https://glm.io/131758 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )
Trustico/Digicert: Chaos um 23.000 Zertifikate und private Schlüssel   
(01.03.2018, https://glm.io/133077 )

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