IETF: Von der TLS-Überwachung zur Massenüberwachung?

IETF Überwachung: Passives Netzwerk-Monitoring soll ermöglicht werden

Längst war die TLS-Arbeitsgruppensitzung auf dem 99. IETF-Meeting in Prag zu Ende (Vortrag als PDF), als Kritiker und Befürworter immer noch leidenschaftlich diskutierten: Über den Vorschlag, der das kommende Verschlüsselungsprotokoll TLS 1.3 zerstören würde – so sehen es zumindest die Kritiker.

Dass die Diskussion so hitzig wurde, ist nicht nur dem Zeitpunkt zu verdanken. Immerhin ist die lange Standardisierungsphase von TLS 1.3 fast schon abgeschlossen. Vor allem inhaltlich wurde ein Entwurf diskutiert, der als Erweiterung für TLS 1.3 eingesetzt werden soll und das Einsetzen des Verschlüsselungsprotokolls in Rechenzentren beschreibt. Die erste Entwurfsversion war zu reinen Informationszwecken gedacht. Die aktuelle jedoch soll als offizieller Internet-Standard veröffentlicht werden.

Im oben verlinkten Vortrag ist zu lesen, dass die mittels TLS 1.3 eingeführten Pläne es für Betreiber riesiger Rechenzentren erschweren würden, auf Fehlersuche zu gehen und diese zu beheben. Die verlängerten Zeiten für die Fehlersuche und -behebung würden einem DDOS-Angriff gleichen, heißt es im Vortrag. Als Beispiel könnte der Traffic auf Firewall-Applikationen, Load-Balancern oder weiteren Fronting-Servern, die dem Serverendpunkt der TLS-Verbindung vorangehen, durch die Verschlüsselung bei einem Fehler unzureichend analysiert werden.

Problem soll direkt auf Protokollebene gelöst werden

Dieses Problem soll nicht etwa auf Basis der Dienste-Architektur oder ähnliches gelöst werden, sondern direkt auf der Ebene des TLS-Protokolls. Dafür wird ein „statischer Diffie-Hellman-Schlüssel“ vorgeschlagen. Dieser wird auf dem TLS- oder auf einem zentralen Key-Management-Server erzeugt und dann im Rechenzentrum weiterverteilt.

Anstelle des eigentlichen vom Server generierten Schlüssels wird ein „statischer Schlüssel“ gemeinsam mit zufälligen Nonce-Werten zum Aufbauen der Verbindungen verwendet. So könnten Betreiber dieser Rechenzentren den „statischen Schlüssel“ dafür verwenden, um den internen Traffic zur weiterführenden Analyse beim Fehlersuchen zu entschlüsseln.

PFS funktioniert so nicht

Die Kritiker dieses Vorschlags sind überzeugt, dass dieses Prinzip Perfect Forward Secrecy (PFS) aushebelt. Kurz erklärt: PFS verhindert durch einen Sitzungsschlüssel das nachträgliche Entschlüsseln. Selbst wenn also der Serverschlüssel als Zertifikateteil kompromittiert wird, bleibt die Verschlüsselung geschützt. Selbst wenn Angreifer an den privaten Schlüssel kommen, können Verbindungen aus der Vergangenheit nicht mehr entschlüsselt werden.

Das Umsetzen von PFS ist nun jedoch eines der Hauptziele von TLS in der Version 1.3. Damit dieses Prinzip erhalten bleiben kann, müssen die Schlüssel je Sitzung neu generiert werden. Dies ist beim beschriebenen Verwenden von statischen Schlüsseln jedoch nicht konsequent möglich.

Überwachung wird abgelehnt

So entstand in Prag erstmals ein Unentschieden von Kritikern und Befürwortern. Mit diesem Unentschieden hat die IETF gerade noch so den Standard zum Überwachen von TLS-gesichertem Netzwerkverkehr abgelehnt. TLS 1.3 ist die sicherste Protokollversion, die es je gab. Die c’t erklärte jüngst, was TLS 1.3 bereithält.

Die komplette IETF-Arbeitsgruppe hat jegliche Änderungen abgelehnt, die die Sicherheit im Standard TLS 1.3 reduzieren könnte. Einige IETF-Mitglieder jedoch kamen auf eine Idee: Statt Konzerne mit dieser Problematik allein zu lassen, ließe sich eine Anleitung über den „Einsatz von statischen Diffie-Hellman-Schlüsseln in Rechenzentren“ erstellen.

Denn um nichts anderes geht es letztlich: Insbesondere Banken, aber auch andere Großkonzerne sind per Gesetz dazu verpflichtet, den eigenen Netzwerkverkehr im eigenen Rechenzentrums-Netz zu überwachen. Das soll helfen, Manipulationen durch Mitarbeiter aufdecken zu können.

Eine andere Lösung muss her

Aus dieser Verpflichtung heraus, ergibt es Sinn, dass Krypto-Experten Konzernen erklären, wie sie eigentlich wünschenswerte Sicherheitsfunktionen, die ihnen jedoch selbst im Wege sind, sinnvoll aushebeln. Man hat die Sicherheit unangetastet gelassen, fand jedoch Lösungen für die Einschränkungen in großen Rechenzentren.

So hat man sich nach der hitzig geführten Diskussion dafür entschieden, Abhörmaßnahmen nicht im Standard festzuschreiben. Und auch das ist sinnvoll: stehen erst mal Abhöraktionen für bestimmte Branchen als Standard fest, könnten staatliche Rufe nach denselben Abhörmöglichkeiten Tür und Tor geöffnet werden. Mit ihrem – zugegeben: sehr knappem Voting dagegen hat die IETF dem einen Riegel vorgeschoben.