Heute haben wir die Unterstützung verschlüsselter SNI angekündigt, eine Erweiterung des TLS 1.3-Protokolls, die die Privatsphäre von Internetbenutzern besser schützt, indem sie verhindert, dass On-Path-Beobachter (einschließlich ISPs, Café-Besitzer und Firewalls) die Server Name Indication-Erweiterung (SNI) für TLS abfangen und verwenden, um zu ermitteln, welche Webseiten die Benutzer besuchen.
Verschlüsselte SNI (encrypted SNI – ESNI) wird es zusammen mit anderen bereits von Cloudflare kostenlos angebotenen Internet-Sicherheitsfunktionen schwieriger machen, Inhalte zu zensieren und Benutzer im Internet zu verfolgen. Lesen Sie weiter, um zu erfahren, wie es funktioniert.
SNWarum?
Die Erweiterung Server Name Indication (SNI) für TLS wurde ursprünglich im Jahr 2003 standardisiert und ermöglicht es Servern, mehrere TLS-fähige Webseiten auf demselben Satz von IP-Adressen zu hosten, indem sie von den Clients verlangt, während des ersten TLS-Handshakes anzugeben, mit welcher Website sie sich verbinden möchten. Ohne SNI wüsste der Server beispielsweise nicht, welches Zertifikat er dem Client liefern oder welche Konfiguration für die Verbindung gelten soll.
Der Client fügt der ClientHello-Nachricht die SNI-Erweiterung hinzu, die den Hostnamen der Seite enthält, mit der er sich verbinden möchte. Er sendet ClientHello während des TLS-Handshakes an den Server. Leider wird die ClientHello-Nachricht unverschlüsselt gesendet, da Client und Server zu diesem Zeitpunkt noch keinen gemeinsamen Verschlüsselungsschlüssel nutzen.
TLS 1.3 with Unencrypted SNI
TLS 1.3 mit unverschlüsselter SNI
Das bedeutet, dass ein On-Path-Beobachter (z. B. ein ISP, ein Café-Besitzer oder eine Firewall) die ClientHello-Nachricht als Klartext abfangen und ermitteln kann, mit welcher Webseite der Client eine Verbindung herstellen will. Dadurch kann der Beobachter verfolgen, welche Websites ein Benutzer besucht.
Aber mit SNI-Verschlüsselung verschlüsselt der Client die SNI, obwohl der Rest von ClientHello als Klartext gesendet wird.
TLS 1.3 with Encrypted SNI
TLS 1.3 mit verschlüsselter SNI
Wie kommt es, dass die ursprüngliche SNI vorher nicht verschlüsselt werden konnte, es jetzt aber möglich ist? Und woher kommt der Verschlüsselungsschlüssel, wenn Client und Server noch keinen ausgehandelt haben?
Woher kommt die Henne, wenn sie vor dem Ei da sein muss?
Wie bei vielen anderen Internet-Features lautet die Antwort einfach „DNS“.
Der Server veröffentlicht einen öffentlichen Schlüssel auf einem bekannten DNS-Eintrag, der vom Client vor dem Herstellen einer Verbindung abgerufen werden kann (wie bereits für A, AAAA und andere Einträge). Der Client ersetzt dann die SNI-Erweiterung im ClientHello durch eine „verschlüsselte SNI“-Erweiterung. Bei dieser handelt es sich um die ursprüngliche SNI-Erweiterung, die aber mit einem symmetrischen Verschlüsselungsschlüssel verschlüsselt wird, der wie unten beschrieben mithilfe des öffentlichen Schlüssels des Servers abgeleitet wurde. Der Server, dem der private Schlüssel gehört und der ebenfalls in der Lage ist, den symmetrischen Verschlüsselungsschlüssel abzuleiten, kann dann die Erweiterung entschlüsseln und somit die Verbindung beenden (oder an einen Back-End-Server weiterleiten). Da nur der Client und der Server, mit dem er eine Verbindung herstellt, den Verschlüsselungsschlüssel ableiten können, kann die verschlüsselte SNI nicht von Dritten entschlüsselt und angerufen werden.
Es ist wichtig zu beachten, dass es sich um eine Erweiterung für TLS Version 1.3 und höher handelt, die nicht mit früheren Versionen des Protokolls funktioniert. Der Grund ist ganz einfach: Eine der Änderungen,die mit TLS 1.3 (nicht ohne Probleme) eingeführt wurden, bedeutete, dass die vom Server gesendete Zertifikatsnachricht in den verschlüsselten Teil des TLS-Handshakes verschoben wurde (vor 1.3 wurde sie als Klartext gesendet). Ohne diese grundlegende Änderung des Protokolls wäre ein Angreifer immer noch in der Lage, die Identität des Servers zu bestimmen, indem er einfach während der Übertragung das gesendete Klartextzertifikat beobachtet.
Der zugrunde liegende kryptografische Vorgang verwendet den Diffie-Hellman-Schlüsselaustauschalgorithmus, der es Client und Server ermöglicht, einen gemeinsamen Verschlüsselungsschlüssel über einen nicht vertrauenswürdigen Kanal zu generieren. Der Verschlüsselungsschlüssel für die verschlüsselte SNI wird dabei auf der Clientseite berechnet, indem der öffentliche Schlüssel des Servers (der eigentlich der öffentliche Teil eines halbstatischen Diffie-Hellman-Schlüsselaustausches ist) und der private Teil eines ephemeral (flüchtigen) Diffie-Hellman-Austausches verwendet werden, wobei letzterer vom Client selbst generiert und sofort nach dem Senden des ClientHello an den Server verworfen wird. Außerdem werden aus Sicherheitsgründen auch zusätzliche Daten (z. B. einige der kryptografischen Parameter, die der Client als Teil seiner ClientHello-Nachricht sendet) in den kryptografischen Prozess eingebracht.
Die ESNI-Erweiterung des Clients beinhaltet dann nicht nur die tatsächlich verschlüsselten SNI-Bit, sondern auch den öffentlichen Schlüsselanteil des Clients, die Verschlüsselungssuite, die er zur Verschlüsselung verwendet hat, und den Digest des ESNI-DNS-Eintrags des Servers. Auf der anderen Seite verwendet der Server seinen eigenen privaten Schlüsselanteil und den öffentlichen Anteils des Clients, um den Verschlüsselungsschlüssel zu generieren und die Erweiterung zu entschlüsseln.
Obwohl dies übermäßig kompliziert erscheinen mag, stellt es sicher, dass der Verschlüsselungsschlüssel kryptografisch an die spezifische TLS-Sitzung gebunden ist, für die er generiert wurde, und nicht über mehrere Verbindungen wiederverwendet werden kann. Dadurch wird verhindert, dass ein Angreifer die vom Client gesendete verschlüsselte Erweiterung einfach abfängt und in einer separaten Sitzung mit dem Server wiederverwendet, um die Identität der Webseite zu ermitteln, mit der der Benutzer eine Verbindung herstellen wollte (dies wird als „Cut-and-Paste“-Angriff bezeichnet).
Ein unerlaubter Zugriff auf den privaten Schlüssel des Servers würde jedoch alle symmetrischen ESNI-Schlüssel gefährden, die von ihm generiert wurden (und Beobachtern ermöglichen, zuvor gesammelte verschlüsselte Daten zu entschlüsseln). Aus diesem Grund wechselt die Implementierung der SDI-Verschlüsselung von Cloudflare die Serverschlüssel stündlich, wodurch zukünftiger Schutz gewährleistet wird. Gleichzeitig werden die Schlüssel der letzten Stunden weiterhin aufbewahrt, um DNS-Caching und Replikationsverzögerungen zu ermöglichen, sodass Clients mit leicht veralteten Schlüsseln ESNI weiterhin problemlos verwenden können (schließlich werden jedoch alle Schlüssel verworfen und vergessen).
Moment mal, DNS? Wirklich?
Der aufmerksame Leser hat sicherlich erkannt, dass die einfache Verwendung des DNS (das standardmäßig unverschlüsselt ist) die gesamte verschlüsselte SNI-Idee völlig sinnlos machen würde: Ein On-Path-Beobachter wäre in der Lage zu ermitteln, zu welcher Website der Client eine Verbindung herstellt, indem er einfach die vom Client selbst gesendeten Klartext-DNS-Abfragen beobachtet, unabhängig davon, ob verschlüsselte SNI verwendet wurde oder nicht.
Aber seit der Einführung von DNS-Funktionen wie DNS-over-TLS (DoT) und DNS-over-HTTPS (DoH) und von öffentlichen DNS-Resolvern, die ihren Benutzern diese Funktionen zur Verfügung stellen (wie Cloudflares eigener 1.1.1.1), können DNS-Abfragen nun verschlüsselt und vor den neugierigen Augen von Zensoren und Trackern gleichermaßen geschützt werden.
Obwohl (trotz böser Resolver) den Antworten von DoT/DoH-DNS-Resolvern bis zu einem gewissen Grad vertraut werden kann, ist es einem entschlossenen Angreifer dennoch möglich, den Cache des Resolvers zu vergiften, indem er dessen Kommunikation mit dem autoritativen DNS-Server unterbricht und bösartige Daten injiziert. Das heißt, es sei denn, sowohl der autoritative Server als auch der Resolver unterstützen DNSSEC[1]. Übrigens können die autoritativen DNS-Server von Cloudflare Antworten signieren, die an Resolver zurückgegeben werden, und der 1.1.1.1.-Resolver kann sie überprüfen.
Was ist mit der IP-Adresse?
Während sowohl DNS-Abfragen als auch die SNI-Erweiterungen für TLS jetzt vor On-Path-Angreifern geschützt werden können, ist es eventuell dennoch möglich zu ermitteln, welche Webseiten von Benutzern besucht werden, indem man einfach die Ziel-IP-Adressen des Datenverkehrs, der von den Geräten der Benutzer ausgeht, betrachtet. Einige unserer Kunden sind bis zu einem gewissen Grad dadurch geschützt, dass viele Cloudflare-Domains die gleichen Adresssätze haben, aber dies reicht nicht aus und es ist noch mehr Arbeit erforderlich, um die Endbenutzer in größerem Umfang zu schützen. Bleiben Sie dran, um in Zukunft weitere Updates von Cloudflare zu diesem Thema zu erhalten.
Wo melde ich mich an?
Verschlüsselte SNI ist jetzt für alle Cloudflare-Zonen, die unsere Nameserver nutzen, kostenlos aktiviert, sodass Sie nichts tun müssen, um sie auf Ihrer Cloudflare-Webseite zu aktivieren. Was Browser anbetrifft, haben uns unsere Freunde von Firefox mitgeteilt, dass sie vorhaben, Unterstützung für verschlüsselte SNI in dieser Woche zu Firefox Nightly hinzufügen (beachten Sie, dass sich die Spezifikationen für verschlüsselte SNI noch in der Entwicklung befinden und sie daher noch nicht stabil ist).
Unter encryptedsni.com können Sie überprüfen, wie sicher Ihr Surferlebnis ist. Verwenden Sie ein sicheres DNS? Validiert Ihr Resolver DNSSEC-Signaturen? Unterstützt Ihr Browser TLS 1.3? Hat Ihr Browser die SNI verschlüsselt? Wenn die Antwort auf all diese Fragen „ja“ lautet, dann können Sie ruhig schlafen mit dem Wissen, dass Sie beim Surfen vor neugierigen Blicken geschützt sind.
Fazit
Verschlüsselte SNI schließt zusammen mit TLS 1.3, DNSSEC und DoT/DoH eine der wenigen verbliebenen Lücken, die Überwachung und Zensur im Internet ermöglichen. Um zu einem überwachungsfreien Internet zu gelangen, ist noch mehr Arbeit erforderlich, aber wir nähern uns (langsam) an.
[1]: Es ist wichtig zu erwähnen, dass DNSSEC durch BGP-Routen-Hijacking zwischen einem DNS-Resolver und dem TLD-Server deaktiviert werden könnte. Letzte Woche haben wir unser Engagement für RPKI angekündigt, und wenn DNS-Resolver und TLDs ebenfalls RPKI implementieren, wird diese Art von Hijacking viel schwieriger sein.
Abonnieren Sie den Blog und Sie erhalten tägliche Updates zu allen unseren Mitteilungen der Geburtstagswoche.