Tschüss ESNI! Hallo ECH!

Ein Großteil der Kommunikation im heutigen Internet ist verschlüsselt, damit ihr Inhalt nur für die Endpunkte – also Client und Server – verständlich ist. Doch dafür wird ein Schlüssel benötigt. Auf diesen müssen sich die Endpunkte einigen, und zwar ohne ihn dabei potenziellen Angreifern offenzulegen. Das am weitesten verbreitete Protokoll für diesen Schlüsselaustausch ist der Transport Layer Security (TLS)-Handshake.

In diesem Beitrag beschäftigen wir uns eingehender mit Encrypted ClientHello (ECH), einer neuen Erweiterung für TLS, die verspricht, den Datenschutz bei diesem kritischen Internetprotokoll erheblich zu verbessern. Gegenwärtig wird eine Reihe datenschutzrelevanter Parameter der TLS-Verbindung im Klartext ausgehandelt, sodass Beobachtern im Netzwerk eine Fülle von Metadaten zur Verfügung steht – unter anderem die Identität der Endpunkte und die Art und Weise, wie sie die Verbindung nutzen.

Mit ECH lässt sich der Handshake vollständig verschlüsseln, sodass diese Metadaten geheim gehalten werden. Entscheidend ist, dass damit eine im Internet seit langem bestehende Datenschutzlücke geschlossen wird, indem die Server Name Indication (SNI) vor unbefugten Blicken im Netzwerk abgeschirmt wird. Die Verschlüsselung des SNI-Geheimnisses ist wichtig, weil dies den eindeutigsten Hinweis darauf gibt, mit welchem Server ein Client kommuniziert. Womöglich noch wichtiger ist jedoch, dass ECH die Grundlage für künftige Sicherheitserweiterungen und Leistungsverbesserungen von TLS schafft. Gleichzeitig wird dafür sorgt, dass diese nur minimale Auswirkungen auf den Endnutzer-Datenschutz haben.

ECH ist das Ergebnis einer durch das IETF geförderten engen Zusammenarbeit zwischen Wissenschaftlern und führenden Technologieunternehmen, einschließlich Cloudflare, unseren Freunden bei Fastly und Mozilla (beide Firmen sind an die Koautoren des Standards angegliedert) und vielen anderen. Diese Funktion stellt eine bedeutende Verbesserung des TLS-Protokolls dar. Sie stützt sich auf allerneueste Technologien wie DNS-over-HTTPS, die erst jetzt ihre volle Wirkung entfalten. An sich ist das Protokoll noch nicht für den Einsatz im Internet bereit. Dieser Artikel ist als Wegweiser zu einer vollständigen Handshake-Verschlüsselung gedacht.

Die Geschichte von TLS ist die Geschichte des Internet. Mit unserer wachsenden Abhängigkeit vom Internet hat sich das Protokoll weiterentwickelt, um sich ständig ändernden Betriebsanforderungen, Anwendungsfällen und Bedrohungsmodellen gerecht zu werden. Client und Server tauschen nicht nur einen Schlüssel aus: Sie handeln eine Vielzahl von Merkmalen und Parametern aus: die genaue Methode des Schlüsselaustauschs, den Verschlüsselungsalgorithmus, wer authentifiziert wird und wie, welches Anwendungsschichtprotokoll nach dem Handshake verwendet werden soll und vieles mehr. Auf die eine oder andere Weise wirken sich all diese Parameter auf die Sicherheitseigenschaften des Kommunikationskanals aus.

SNI ist ein Paradebeispiel für einen Parameter, der Einfluss auf den Sicherheitsgrad des Kanals hat. Die SNI-Erweiterung wird vom Client verwendet, um dem Server mitzuteilen, welche Website er erreichen möchte. Für das moderne Internet ist dies unerlässlich, weil heutzutage üblicherweise viele Ursprungsserver hinter einem einzigen TLS-Betreiber angesiedelt sind. In diesem Kontext verwendet der Betreiber die SNI, um zu bestimmen, wer die Verbindung authentifiziert: Ohne diese SNI könnte der Betreiber nicht in Erfahrung bringen, welches TLS-Zertifikat er dem Client vorlegen soll. Das Problem besteht darin, dass die SNI dem Netzwerk die Identität des Ursprungsservers preisgibt, zu dem der Client eine Verbindung herstellen möchte. Daher können Unbefugte unter Umständen eine Menge Informationen über diesen Austausch ableiten. (Natürlich hat ein Beobachter im Netzwerk noch andere Möglichkeiten, um den Ursprungsserver zu identifizieren, beispielsweise mittels der IP-Adresse des Ursprungsservers. Aber aufgrund der Colocation mit anderen Ursprungsservern unter der gleichen IP-Adresse ist es viel schwieriger, aus dieser Information auf den Ursprungsserver zu schließen, als wenn man sich einfach nur die SNI anzusehen bräuchte).

Obwohl der Schutz der SNI den Anstoß für ECH gegeben hat, handelt es sich bei weitem nicht um den einzigen datenschutzrelevanten Handshake-Parameter, den Client und Server aushandeln. Ein weiterer ist die ALPN-Erweiterung. Mit dieser wird entschieden, welches Protokoll der Anwendungsschicht nach Aufbau der TLS-Verbindung zum Einsatz kommen soll. Der Client sendet die Liste der von ihm unterstützten Anwendungen – ob HTTPS, E-Mail, Instant Messaging oder die unzähligen anderen Anwendungen, die TLS zur Absicherung von Datenübertragungen verwendet. Der Server trifft dann aus dieser Liste seine Wahl und übermittelt diese an den Client. So geben Client und Server dem Netzwerk gegenüber einen eindeutigen Hinweis auf ihre Fähigkeiten und den möglichen Verwendungszweck der Verbindung preis.

Einige Funktionen sind so datenschutzrelevant, dass sich ihre Einbeziehung in den Handshake verbietet. Unter anderem ist die Idee aufgekommen, den regulären Schlüsselaustausch, der das Herzstück von TLS bildet, durch einen Passwort-authentifizierten Schlüsselaustausch (Password Authenticated Key Exchange – PAKE) zu ersetzen. Dadurch könnte Passwort-basierte Authentifizierung neben (oder anstelle von) Zertifikats-basierter Authentifizierung verwendet werden. Das würde TLS robuster machen und für ein breiteres Spektrum von Anwendungen öffnen. Das Datenschutzproblem stellt sich hier analog zur SNI: Server ordnen jedem Client typischerweise eine eindeutige Kennung zu (z. B. einen Nutzernamen oder eine E-Mail-Adresse), die zum Abrufen der Anmeldedaten des Client verwendet wird. Der Client muss diese Identität während des Handshake irgendwie an den Server übermitteln. Würden diese einer bestimmten Person zuzuordnenden Informationen im Klartext übertragen, wären sie für jeden Beobachter im Netzwerk leicht zugänglich.

Ein notwendiges Element für die Beseitigung all dieser Datenschutzlücken ist die Handshake-Verschlüsselung. Dabei werden nicht nur die Anwendungsdaten, sondern auch die Handshake-Nachrichten verschlüsselt. Das klingt einfach, doch bei dieser Lösung stellt sich eine andere Frage: Wie wählen Client und Server einen Schlüssel für die Verschlüsselung aus, wenn der Handshake doch selbst Mittel zum Austausch eines Schlüssels ist? Einige Parameter müssen natürlich im Klartext übertragen werden. ECH hat daher das Ziel, alle Handshake-Parameter zu verschlüsseln – mit Ausnahme derjenigen, die für den Abschluss des Schlüsselaustauschs unbedingt benötigt werden.

Zum besseren Verständnis von ECH und der zugrunde liegenden Entscheidungen bei der Ausgestaltung ist es hilfreich, sich ein wenig mit der Geschichte der Handshake-Verschlüsselung bei TLS zu befassen.

Bis zur jüngsten Version, TLS 1.3, verfügte TLS über keinerlei Handshake-Verschlüsselung. Im Anschluss an die Enthüllungen von Snowden im Jahr 2013 hat die IETF-Community begonnen, über Möglichkeiten nachzudenken, wie sich der Bedrohung des offenen Internet durch Massenüberwachung entgegenwirken ließe. Als 2014 die Standardisierung von TLS 1.3 begann, bestand eines der Entwicklungsziele darin, den größtmöglichen Teil des Handshake zu verschlüsseln. Leider gelingt die vollständige Handshake-Verschlüsselung mit dem abschließenden Standard nicht. So werden einige Parameter, darunter auch die SNI, noch immer unverschlüsselt übertragen. Warum das so ist, schauen wir uns nun genauer an.

Der Protokollablauf von TLS 1.3 ist in Abbildung 1 dargestellt. Die Handshake-Verschlüsselung beginnt, sobald Client und Server ein neues gemeinsames Geheimnis berechnen. Zu diesem Zweck sendet der Client einen Key Share in seiner ClientHello-Nachricht und der Server antwortet in seiner ServerHello-Nachricht mit seinem eigenen Key Share. Nach diesem Austausch können Client und Server ein gemeinsames Geheimnis ableiten. Jede nachfolgende Handshake-Nachricht wird mit dem Handshake-Verkehrsschlüssel verschlüsselt, der aus dem gemeinsamen Geheimnis abgeleitet wird. Die Anwendungsdaten werden mit einem anderen Schlüssel verschlüsselt, dem so genannten Anwendungsverkehrsschlüssel, der sich ebenfalls aus dem gemeinsamen Geheimnis ableitet. Diese abgeleiteten Schlüssel haben unterschiedliche Sicherheitseigenschaften: Um dies zu betonen, werden sie in unterschiedlichen Farben dargestellt.

Die erste Handshake-Nachricht, die verschlüsselt wird, ist die EncryptedExtensions-Nachricht des Servers. Zweck dieser Nachricht ist der Schutz der sensiblen Handshake-Parameter des Servers, einschließlich seiner ALPN-Erweiterung, die die aus der ALPN-Liste des Client ausgewählte Anwendung enthält. Die Schlüsselaustausch-Parameter werden unverschlüsselt in der ClientHello- und ServerHello-Nachricht gesendet.

Abbildung 1: Der TLS 1.3-Handshake.

Alle Handshake-Parameter des Client, ob vertraulich oder nicht, werden in der ClientHello-Nachricht übermittelt. Wenn Sie sich Abbildung 1 ansehen, fällt Ihnen vielleicht eine Möglichkeit ein, den Handshake so zu überarbeiten, dass einige davon verschlüsselt werden können, vielleicht zum Preis einer höheren Latenz (d. h. mehr Round-Trips durch das Netzwerk). Erweiterungen wie SNI schaffen allerdings eine Art von „Henne oder Ei“-Problem.

Der Client verschlüsselt nichts, bis er die Identität des Servers überprüft hat (das ist die Aufgabe der Nachrichten Certificate und CertificateVerify) und vom Server bestätigt wurde, dass dieser das gemeinsame Geheimnis kennt (die Aufgabe der Nachricht Finished). Diese Maßnahmen stellen sicher, dass der Schlüsselaustausch authentifiziert wird. So können MITM (Monster-in-the-middle)-Angriffe verhindert werden, bei denen sich der Gegner gegenüber dem Client auf eine Weise als Server ausgibt, die es ihm ermöglicht, vom Client gesendete Nachrichten zu entschlüsseln. Die SNI wird vom Server benötigt, um das Zertifikat auszuwählen. Sie muss daher übermittelt werden, bevor der Schlüsselaustausch authentifiziert werden kann.

Im Allgemeinen ist die Gewährleistung der Vertraulichkeit der für die Authentifizierung verwendeten Handshake-Parameter nur möglich, wenn Client und Server bereits über einen gemeinsamen Schlüssel zur Verschlüsselung verfügen. Aber woher könnte dieser Schlüssel kommen?

Vollständige Handshake-Verschlüsselung während der Anfänge von TLS 1.3. Interessanterweise ist einmal vorgeschlagen worden, die vollständige Verschlüsselung des Handshake zu einem Kernmerkmal von TLS 1.3 zu machen. In frühen Versionen des Protokolls (Entwurf Nr. 10, ca. 2015), bot der Server dem Client während des Handshake einen langlebigen öffentlichen Schlüssel an, den der Client bei nachfolgenden Handshakes zur Verschlüsselung verwendete. (Diese Ausgestaltung ist dem Protokoll OPTLS entlehnt, das sich wiederum aus dem ursprünglichen QUIC-Vorschlag ableitet.) Der Hauptzweck dieses Modus mit dem Namen „0-RTT“ bestand darin, dem Client die Möglichkeit zu geben, vor Durchführung eines Handshake mit der Übertragung von Anwendungsdaten zu beginnen. Darüber hinaus hätte der Client auf diese Weise seine ersten zu übertragenden Handshake-Nachrichten nach der ClientHello-Nachricht verschlüsseln können, einschließlich seiner eigenen EncryptedExtensions-Nachricht. Das hätte zum Schutz der vertraulichen Handshake-Parameter des Client verwendet werden können.

Letztendlich wurde diese Funktion nicht in den endgültigen Standard (RFC 8446, veröffentlicht im Jahr 2018) aufgenommen – in erster Linie, weil der erhöhte Grad der Komplexität schwerer wog als ihr Nutzen. Insbesondere schützt sie in keiner Weise den ersten Handshake, bei dem der Client den öffentlichen Schlüssel des Servers erfährt. Für die Serverauthentifizierung erforderliche Parameter wie SNI werden trotzdem unverschlüsselt übertragen.

Als Vorläufer anderer Handshake-Verschlüsselungsmechanismen wie ECH, die zum Schutz vertraulicher ClientHello-Parameter eine asymmetrische Verschlüsselung verwenden, kommt diesem Schema dennoch Bedeutung zu. Das Hauptproblem, das diese Mechanismen lösen müssen, ist die Schlüsselverteilung.

Der direkte Vorgänger von ECH war die Erweiterung Encrypted SNI (ESNI), mit der die Vertraulichkeit der SNI gewährleistet wird. Dazu verschlüsselte der Client seine SNI-Erweiterung mit dem öffentlichen Schlüssel des Servers und schickte den Geheimtext an den Server. Der Server versuchte, diesen mithilfe des geheimen Schlüssels zu entschlüsseln, der dem öffentlichen Schlüssel entspricht. War die Verschlüsselung erfolgreich, stellte der Server die Verbindung mit der entschlüsselten SNI her. Andernfalls wurde der Handshake einfach abgebrochen. Der High-Level-Flow dieses einfachen Protokolls wird in Abbildung 2 dargestellt.

Abbildung 2: Der TLS 1.3-Handshake mit der ESNI-Erweiterung. Er ist identisch mit dem TLS 1.3-Handshake, nur wurde die SNI-Erweiterung durch ESNI ersetzt.

Für die Schlüsselverteilung verließ sich ESNI auf ein anderes kritisches Protokoll: Domain Name Service (DNS). Um ESNI für die Verbindung mit einer Website zu verwenden, nutzte der Client seine Standard-A/AAAA-Abfragen für die Anfrage eines TXT Record mit dem öffentlichen ESNI-Schlüssel. Um beispielsweise den Schlüssel für crypto.dance zu erhalten, forderte der Client den TXT Record von _esni.crypto.dance an:

$ dig _esni.crypto.dance TXT +short
"/wGuNThxACQAHQAgXzyda0XSJRQWzDG7lk/r01r1ZQy+MdNxKg/mAqSnt0EAAhMBAQQAAAAAX67XsAAAAABftsCwAAA="

Das mittels base64 kodierte BLOB enthält einen öffentlichen ESNI-Schlüssel und zugehörige Parameter wie den Verschlüsselungsalgorithmus.

Aber welchen Sinn hat das Verschlüsseln der SNI, wenn der Servername über eine Klartext-DNS-Abfrage für Beobachter im Netzwerk erkennbar ist? Diese Art des Einsatzes von ESNI wurde durch die Einführung von DNS-over-HTTPS (DoH) möglich. Dieses Protokoll erlaubt die Verschlüsselung von DNS-Abfragen, die an Resolver gerichtet sind, welche den DoH-Dienst bereitstellen (ein Beispiel für einen solchen Dienst wäre 1.1.1.1). Ein weiteres wichtiges Merkmal von DoH besteht darin, dass es einen authentifizierten Kanal für die Übertragung des öffentlichen ESNI-Schlüssels vom DoH-Server zum Client bereitstellt. Dies verhindert Cache Poisoning-Angriffe, die vom lokalen Netzwerk des Client ausgehen: Ohne DoH könnte ein lokaler Angreifer den Client daran hindern, die ESNI-Erweiterung anzubieten, indem er einen leeren TXT Record zurückschickt. Alternativ könnte er den Client dazu zwingen, die ESNI-Erweiterung mit einem Schlüssel zu verwenden, über den er die Kontrolle hat.

Mit ESNI wurde zwar ein bedeutender Fortschritt erzielt, das Ziel einer vollständigen Handshake-Verschlüsselung wird damit jedoch nicht erreicht. Erstens ist die Lösung unvollständig, da sie nur die SNI-Erweiterung schützt. Zweitens ist sie anfällig für eine Handvoll raffinierter Angriffe. Diese sind zwar schwer umzusetzen, weisen jedoch auf theoretische Schwächen in der Protokollstruktur hin, die ausgemerzt werden müssen.

ESNI wurde im Jahr 2018 von Cloudflare eingesetzt und als Opt-in bei Firefox aktiviert. Dabei wurden einige der Probleme sichtbar, die mit einer Schlüsselverteilung per DNS verbunden sind. Cloudflare wechselt den ESNI-Schlüssel stündlich, um die Kollateralschäden für den Fall, dass ein Schlüssel kompromittiert wird, möglichst gering zu halten. DNS-Artefakte werden jedoch manchmal viel länger zwischengespeichert. In der Folge ist die Wahrscheinlichkeit, dass ein Client im Besitz eines veralteten öffentlichen Schlüssels ist, recht groß. Obwohl der ESNI-Dienst von Cloudflare dies bis zu einem gewissen Grad toleriert, muss jeder Schlüssel irgendwann seine Gültigkeit verlieren. Das ESNI-Protokoll hat die Frage offen gelassen, wie der Client vorgehen soll, wenn die Entschlüsselung fehlschlägt und er weder über das DNS noch auf andere Weise auf den aktuellen öffentlichen Schlüssel zugreifen kann.

Ein weiteres Problem bei einer Schlüsselverteilung mittels DNS besteht darin, dass mehrere Endpunkte zwar für denselben Ursprungsserver autoritativ sein können, jedoch unterschiedliche Fähigkeiten aufweisen. Beispielsweise kann eine Anfrage des A Record von „example.com“ eine von zwei verschiedenen IP-Adressen liefern, die jeweils von einem anderen CDN betrieben werden. Der TXT Record für „_esni.example.com“ würde den öffentlichen Schlüssel für eines dieser CDNs enthalten, aber sicherlich nicht für beide. Das DNS-Protokoll bietet keine Möglichkeit, Ressourceneinträge, die dem gleichen Endpunkt entsprechen, untrennbar miteinander zu verknüpfen. Insbesondere kann ein Client die ESNI-Erweiterung versehentlich einem Endpunkt anbieten, der sie nicht unterstützt, was den Handshake fehlschlagen lässt. Die Behebung dieses Problems erfordert Änderungen am DNS-Protokoll. (Weitere Informationen dazu finden Sie unten.)

Die Zukunft von ESNI. Im nächsten Abschnitt gehen wir auf die ECH-Spezifikation und auf die Frage ein, wie diese die Defizite von ESNI beseitigen kann. Trotz ihrer Grenzen bietet die Erweiterung jedoch beträchtliche praktische Vorzüge in Sachen Datenschutz. Cloudflare beabsichtigt, ESNI so lange zu unterstützen, bis ECH im regulären Betrieb eingesetzt werden kann.

ECH hat das Ziel, die gesamte ClientHello-Nachricht zu verschlüsseln und damit die bei TLS 1.3 und ESNI verbleibende Lücke zu schließen, indem alle datenschutzrelevanten Handshake-Parameter abgeschirmt werden. Ähnlich wie ESNI verwendet das Protokoll einen öffentlichen Schlüssel, der über das DNS verteilt und mittels DoH erlangt wird, zur Verschlüsselung während der ersten Übertragung des Client. ECH weist jedoch Verbesserungen bei der Schlüsselverteilung auf, die das Protokoll weniger anfällig für DNS-Cache-Unstimmigkeiten machen. Wenn die Verschlüsselung fehlschlägt, bricht der ESNI-Server die Verbindung ab. Demgegenüber versucht der ECH-Server in einem solchen Fall, den Handshake abzuschließen und dem Client einen öffentlichen Schlüssel zur Verfügung zu stellen, mit dem dieser erneut den Versuch unternehmen kann, eine Verbindung aufzubauen.

Aber wie kann der Server den Handshake abschließen, wenn er nicht in der Lage ist, die ClientHello-Nachricht zu entschlüsseln? Wie in Abbildung 3 dargestellt, umfasst das ECH-Protokoll in Wirklichkeit zwei ClientHello-Nachrichten: die wie üblich im Klartext gesendete ClientHelloOuter-Nachricht und die ClientHelloInner-Nachricht, die verschlüsselt und als Erweiterung der ClientHelloOuter-Nachricht übertragen wird. Der Server schließt den Handshake mit nur einer dieser ClientHello-Nachrichten ab. Bei erfolgreicher Entschlüsselung fährt er mit der ClientHelloInner-Nachricht fort, andernfalls mit der ClientHelloOuter-Nachricht.

Abbildung 3: Der TLS 1.3-Handshake mit ECH-Erweiterung.

Die ClientHelloInner-Nachricht setzt sich aus den Handshake-Parametern zusammen, die der Client für die Verbindung verwenden möchte. Dazu gehören vertrauliche Werte, wie die SNI des Ursprungsservers, den er erreichen will (im ECH-Jargon als Backend-Server bezeichnet), die ALPN-Liste etc. Bei der ClientHelloOuter-Nachricht handelt es sich zwar ebenfalls eine vollwertige ClientHello-Nachricht, sie wird aber nicht für die angestrebte Verbindung verwendet. Stattdessen wird der Handshake durch den ECH-Dienstleister (im Fachjargon Client-seitiger Server) selbst abgeschlossen, um dem Client zu signalisieren, dass sein beabsichtigter Zielort aufgrund eines Entschlüsselungsfehlers nicht erreicht werden konnte. In diesem Fall überträgt der Dienstanbieter auch den korrekten öffentlichen ECH-Schlüssel, mit dem der Client den Handshake wiederholen kann. Auf diese Weise wird die Konfiguration des Client „korrigiert“. (Dieser Mechanismus hat Ähnlichkeit mit der Verteilung des öffentlichen Schlüssels durch den Server für den „0-RTT-Modus“ während der Anfangszeiten von TLS 1.3).

Beide ClientHello-Nachrichten müssen mindestens die für einen serverauthentifizierten Schlüsselaustausch erforderlichen Handshake-Parameter enthalten. Während die ClientHelloInner-Nachricht die echte SNI beinhaltet, umfasst die ClientHelloOuter-Nachricht auch einen SNI-Wert, den der Client im Falle eines ECH-Entschlüsselungsfehlers verifizieren will (gemeint ist der dem Client zugewandte Server). Wird die Verbindung über die ClientHelloOuter-Nachricht hergestellt, wird erwartet, dass der Client die Verbindung sofort abbricht und mit dem vom Server bereitgestellten öffentlichen Schlüssel einen erneuten Handshake-Versuch unternimmt. Der Client muss in der ClientHelloOuter-Nachricht weder eine ALPN-Liste noch irgendeine andere Erweiterung angeben, die zur Steuerung des Verhaltens nach dem Handshake-verwendet wird. Alle diese Parameter sind in der verschlüsselten ClientHelloInner-Nachricht enthalten.

Durch diese Ausgestaltung werden – meiner Meinung nach auf sehr elegante Weise – die meisten bekannten Probleme früherer Mechanismen bei der sicheren Bereitstellung einer vollständigen Handshake-Verschlüsselung beseitigt. Wichtig ist, dass ECH nicht in einem Vakuum konzipiert wurde. Das Protokoll spiegelt die unterschiedlichen Perspektiven der IETF-Community wider und seine Entwicklung ist mit anderen für den Erfolg von ECH maßgeblichen IETF-Standards verknüpft.

Der erste ist eine wichtige neue DNS-Funktion, der HTTPS-Ressourceneintrag. Diese Art des Eintrags soll es auf hoher Ebene mehreren für denselben Domainnamen autoritativen HTTPS-Endpunkten ermöglichen, unterschiedliche Fähigkeiten für TLS kundzutun. So kann man bei der Schlüsselverteilung auf das DNS zurückgreifen, wodurch eines der Probleme gelöst wird, die bei der ursprünglichen ESNI-Einführung offengelegt wurden. Einen tieferen Einblick in diese neue Eintragsart und ihre allgemeinere Bedeutung für das Internet bietet der kürzlich veröffentlichte Blog-Beitrag zu diesem Thema von Alessandro Ghedini.

Der CFRG-Verschlüsselungsstandard Hybrid Public Key Encryption (HPKE) legt einen erweiterbaren Rahmen für den Aufbau von Verschlüsselungsschemata mit öffentlichem Schlüssel fest, die für eine Vielzahl von Anwendungen geeignet sind. Insbesondere werden bei ECH alle Einzelheiten des Handshake-Verschlüsselungsmechanismus an HPKE delegiert. Das Ergebnis ist eine wesentlich einfachere und leichter zu analysierende Spezifikation. (Übrigens zählt HPKE auch zu den Hauptbestandteilen von Oblivious DNS-over-HTTPS.)

Die aktuelle ECH-Spezifikation bildet den Höhepunkt einer mehrjährigen Zusammenarbeit. Gegenwärtig ist die Gesamtstruktur des Protokolls recht stabil. Tatsächlich wird der aktuelle. Entwurf der Spezifikation der erste Gegenstand von Interoperabilitätstests während der Implementierungen sein. Trotzdem müssen noch eine Reihe von Details geklärt werden. Werfen wir zum Abschluss dieses Beitrags noch einen kurzen Blick darauf, was die Zukunft bereithält.

Letztendlich soll mit ECH gewährleistet werden, dass TLS-Verbindungen zu verschiedenen Ursprungsservern hinter demselben ECH-Dienstleister nicht voneinander zu unterscheiden sind. Mit anderen Worten: Wenn Sie eine Verbindung zu einem Ursprungsserver hinter Cloudflare herstellen, sollte für niemanden, der sich im Netzwerk zwischen Ihnen und beispielsweise Cloudflare befindet, erkennbar sein, welchen Ursprungsserver Sie erreicht haben oder welche datenschutzrelevanten Handshake-Parameter Sie und der Ursprungsserver ausgehandelt haben. Erreicht man dieses Ziel, wird damit nicht nur der Datenschutz unmittelbar gestärkt, sondern auch der Weg für den Einsatz neuer Funktionen für TLS geebnet, ohne den Datenschutz zu schwächen.

Die Verschlüsselung der ClientHello-Nachricht ist ein wichtiger Schritt auf diesem Weg, es muss aber noch etwas mehr getan werden. Ein bislang noch nicht besprochener wichtiger Angriffsvektor ist die Traffic-Analyse. Gemeint ist damit das Erfassen und Analysieren von Eigenschaften des Kommunikationskanals, die einen Teil des Inhalts des Geheimtexts verraten, ohne dass bei diesem Vorgang das zugrunde liegende Verschlüsselungsschema geknackt wird. Beispielsweise könnte die Länge der verschlüsselten ClientHello-Nachricht genug Informationen über die SNI preisgeben, um dem Gegner eine gut begründete Vermutung hinsichtlich ihres Werts zu erlauben (besonders hoch ist das Risiko bei entweder besonders kurzen oder besonders langen Domainnamen). Es ist daher entscheidend, dass zwischen der Länge jedes Geheimtexts und den Werten der datenschutzrelevanten Parameter kein Zusammenhang besteht. Die aktuelle ECH-Spezifikation sieht einige Lösungen zur Schadensbegrenzung vor, diese greifen jedoch zu kurz. Daher ist die Verbesserung der Widerstandsfähigkeit der ECH gegenüber der Traffic-Analyse für die Zukunft ein wichtiges Arbeitsgebiet.

Offen ist auch noch die wichtige Frage, welche Auswirkungen ECH auf den Netzwerkbetrieb haben wird.

Aus dem Einsatz von TLS 1.3 wurde unter anderem die Lehre gezogen, dass die Aktualisierung eines zentralen Internetprotokolls ein unerwartetes Verhalten des Netzwerks hervorrufen kann. Cloudflare war einer der ersten führenden TLS-Betreiber, der TLS 1.3 in großem Maßstab eingesetzt hat. Als Browser wie Firefox und Chrome begonnen haben, die Verwendung von TLS versuchsweise zu ermöglichen, verzeichneten sie eine deutlich höhere Zahl von Verbindungsausfällen als bei TLS 1.2. Die Hauptursache für diese Ausfälle war die Verknöcherung des Netzwerks, d.h. die Tendenz von Middleboxen – Netzwerkgeräten zwischen Clients und Servern, die den Datenverkehr überwachen und manchmal abfangen –, Software zu schreiben, die bestimmte Erwartungen an das Aussehen und Verhalten von Traffic hat. Die Änderung des Protokolls, bevor Middleboxen die Gelegenheit zur Aktualisierung ihrer Software hatten, führte dazu, dass diese versuchten, nicht erkannte Pakete zu parsen. Das wiederum verursachte Software-Fehler, die in einigen Fällen einen vollständigen Verbindungsabbruch zur Folge hatten.

Dieses Problem war so weit verbreitet, dass man die Struktur von TLS 1.3 angepasst hat, um die Folgen der Netzwerk-Verknöcherung abzumildern, anstatt darauf zu warten, dass die Netzwerkbetreiber ihre Software aktualisieren. Man kam auf die findige Lösung, TLS 1.3 wie ein anderes Protokoll aussehen zu lassen, das von Middleboxen bekanntermaßen toleriert wird. Konkret wurden das Wire-Format und sogar die Inhalte der Handshake-Nachrichten so gestaltet, dass sie denen unter TLS 1.2 ähneln. Diese beiden Protokolle sind zwar natürlich nicht identisch,  sodass ein neugieriger Beobachter im Netzwerk sie immer noch voneinander unterscheiden kann. Doch sie ähneln sich in Aussehen und Verhalten stark genug, um sicherzustellen, dass die Mehrheit der existierenden Middleboxen sie nicht unterschiedlich behandelt. Empirisch hat sich gezeigt, dass durch diese Strategie die Zahl der Verbindungsfehler stark genug gesenkt werden konnte, um den Einsatz von TLS 1.3 praktikabel zu machen.

Es ist nochmals festzustellen, dass ECH eine wichtige Verbesserung von TLS darstellt, wobei die Gefahr der Netzwerkverknöcherung einen langen Schatten wirft. Die ClientHello-Nachricht enthält Parameter wie die SNI, die seit langer Zeit Teil des Handshake sind, und wir wissen noch nicht, welche Auswirkungen ihre Verschlüsselung haben wird. In Anbetracht der Verwendungsprobleme, die eine solche Verknöcherung hervorrufen könnte, wurde das ECH-Protokoll so ausgestaltet, dass es einem Standard-TLS 1.3.-Handshake so stark ähnelt wie möglich. Der beachtenswerteste Unterschied besteht in der ECH-Erweiterung selbst: Wenn Middleboxen sie ignorieren – was sie tun sollten, wenn sie den TLS 1.3-Standard einhalten –, wird der Handshake ansonsten in Aussehen und Verhalten ganz normal erscheinen.

Ob diese Strategie ausreicht, um einen großflächigen Einsatz von ECH zu gewährleisten, bleibt abzuwarten. Sollte dem so sein, ist darauf hinzuweisen, dass diese neue Funktion dazu beiträgt, die Auswirkungen zukünftiger TLS-Upgrades auf den Netzwerkbetrieb so gering wie möglich zu halten. Eine Verschlüsselung des gesamten Handshake reduziert die Gefahr einer Verknöcherung, weil dadurch weniger Protokollfunktionen sichtbar sind, auf deren Grundlage Software für eine Verknöcherung sorgen könnte. Unserer Meinung nach ist das dem Gesamtzustand des Internet zuträglich.

Der alte TLS-Handshake gibt (unbeabsichtigt) Informationen preis. Betriebsanforderungen von Client und Server haben es mit sich gebracht, dass datenschutzrelevante Parameter wie die SNI vollständig im Klartext ausgehandelt werden und so für Beobachter im Netzwerke sichtbar sind. Mit der ECH-Erweiterung soll diese Lücke geschlossen werden, indem eine Verschlüsselung des vollständigen Handshake möglich gemacht wird. Dies stellt eine bedeutende Verbesserung von TLS dar, die zur Wahrung des Datenschutzes für Endnutzer beitragen wird, während das Protokoll weiterentwickelt wird.

Der ECH-Standard entwickelt sich weiter. Während diese Arbeit fortgesetzt wird, sind wir bei Cloudflare entschlossen, sicherzustellen, dass diese wichtige Verbesserung von TLS es bis zur Anwendung im Internet schafft.