L\u00e4ngst war die TLS-Arbeitsgruppensitzung auf dem 99. IETF-Meeting in Prag zu Ende (Vortrag als PDF<\/a>), als Kritiker und Bef\u00fcrworter immer noch leidenschaftlich diskutierten: \u00dcber den Vorschlag, der das kommende Verschl\u00fcsselungsprotokoll TLS 1.3 zerst\u00f6ren w\u00fcrde \u2013 so sehen es zumindest die Kritiker.<\/p>\n 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\u00fcr TLS 1.3 eingesetzt werden soll und das Einsetzen des Verschl\u00fcsselungsprotokolls in Rechenzentren beschreibt. Die erste Entwurfsversion<\/a> war zu reinen Informationszwecken gedacht. Die aktuelle<\/a> jedoch soll als offizieller Internet-Standard ver\u00f6ffentlicht werden.<\/p>\n Im oben verlinkten Vortrag ist zu lesen, dass die mittels TLS 1.3 eingef\u00fchrten Pl\u00e4ne es f\u00fcr Betreiber riesiger Rechenzentren erschweren w\u00fcrden, auf Fehlersuche zu gehen und diese zu beheben. Die verl\u00e4ngerten Zeiten f\u00fcr die Fehlersuche und -behebung w\u00fcrden einem DDOS-Angriff gleichen, hei\u00dft es im Vortrag. Als Beispiel k\u00f6nnte der Traffic auf Firewall-Applikationen, Load-Balancern oder weiteren Fronting-Servern, die dem Serverendpunkt der TLS-Verbindung vorangehen, durch die Verschl\u00fcsselung bei einem Fehler unzureichend analysiert werden.<\/p>\n Dieses Problem soll nicht etwa auf Basis der Dienste-Architektur oder \u00e4hnliches gel\u00f6st werden, sondern direkt auf der Ebene des TLS-Protokolls. Daf\u00fcr wird ein \u201estatischer Diffie-Hellman-Schl\u00fcssel\u201c vorgeschlagen. Dieser wird auf dem TLS- oder auf einem zentralen Key-Management-Server erzeugt und dann im Rechenzentrum weiterverteilt.<\/p>\n Anstelle des eigentlichen vom Server generierten Schl\u00fcssels wird ein \u201estatischer Schl\u00fcssel\u201c gemeinsam mit zuf\u00e4lligen Nonce-Werten zum Aufbauen der Verbindungen verwendet. So k\u00f6nnten Betreiber dieser Rechenzentren den \u201estatischen Schl\u00fcssel\u201c daf\u00fcr verwenden, um den internen Traffic zur weiterf\u00fchrenden Analyse beim Fehlersuchen zu entschl\u00fcsseln.<\/p>\n Die Kritiker dieses Vorschlags sind \u00fcberzeugt, dass dieses Prinzip Perfect Forward Secrecy (PFS)<\/a> aushebelt. Kurz erkl\u00e4rt: PFS verhindert durch einen Sitzungsschl\u00fcssel das nachtr\u00e4gliche Entschl\u00fcsseln. Selbst wenn also der Serverschl\u00fcssel als Zertifikateteil kompromittiert wird, bleibt die Verschl\u00fcsselung gesch\u00fctzt. Selbst wenn Angreifer an den privaten Schl\u00fcssel kommen, k\u00f6nnen Verbindungen aus der Vergangenheit nicht mehr entschl\u00fcsselt werden.<\/p>\n Das Umsetzen von PFS ist nun jedoch eines der Hauptziele von TLS in der Version 1.3. Damit dieses Prinzip erhalten bleiben kann, m\u00fcssen die Schl\u00fcssel je Sitzung neu generiert werden. Dies ist beim beschriebenen Verwenden von statischen Schl\u00fcsseln jedoch nicht konsequent m\u00f6glich.<\/p>\n So entstand in Prag erstmals ein Unentschieden von Kritikern und Bef\u00fcrwortern. Mit diesem Unentschieden hat die IETF gerade noch so den Standard zum \u00dcberwachen von TLS-gesichertem Netzwerkverkehr abgelehnt<\/a>. TLS 1.3 ist die sicherste Protokollversion, die es je gab. Die c’t erkl\u00e4rte j\u00fcngst<\/a>, was TLS 1.3 bereith\u00e4lt.<\/p>\n Die komplette IETF-Arbeitsgruppe hat jegliche \u00c4nderungen abgelehnt, die die Sicherheit im Standard TLS 1.3 reduzieren k\u00f6nnte. Einige IETF-Mitglieder jedoch kamen auf eine Idee: Statt Konzerne mit dieser Problematik allein zu lassen, lie\u00dfe sich eine Anleitung \u00fcber den „Einsatz von statischen Diffie-Hellman-Schl\u00fcsseln in Rechenzentren“ erstellen.<\/p>\n Denn um nichts anderes geht es letztlich: Insbesondere Banken, aber auch andere Gro\u00dfkonzerne sind per Gesetz dazu verpflichtet, den eigenen<\/strong> Netzwerkverkehr im eigenen<\/strong> Rechenzentrums-Netz zu \u00fcberwachen. Das soll helfen, Manipulationen durch Mitarbeiter aufdecken zu k\u00f6nnen.<\/p>\n Aus dieser Verpflichtung heraus, ergibt es Sinn, dass Krypto-Experten Konzernen erkl\u00e4ren, wie sie eigentlich w\u00fcnschenswerte Sicherheitsfunktionen, die ihnen jedoch selbst im Wege sind, sinnvoll aushebeln. Man hat die Sicherheit unangetastet gelassen, fand jedoch L\u00f6sungen f\u00fcr die Einschr\u00e4nkungen in gro\u00dfen Rechenzentren.<\/p>\n So hat man sich nach der hitzig gef\u00fchrten Diskussion daf\u00fcr entschieden, Abh\u00f6rma\u00dfnahmen nicht im Standard festzuschreiben. Und auch das ist sinnvoll: stehen erst mal Abh\u00f6raktionen f\u00fcr bestimmte Branchen als Standard fest, k\u00f6nnten staatliche Rufe nach denselben Abh\u00f6rm\u00f6glichkeiten T\u00fcr und Tor ge\u00f6ffnet werden. Mit ihrem \u2013 zugegeben: sehr knappem Voting dagegen hat die IETF dem einen Riegel vorgeschoben.<\/p>\nProblem soll direkt auf Protokollebene gel\u00f6st werden<\/h3>\n
PFS funktioniert so nicht<\/h3>\n
\u00dcberwachung wird abgelehnt<\/h3>\n
Eine andere L\u00f6sung muss her<\/h3>\n