TLS: Mozilla, Cloudflare und Apple wollen verschlüsselte SNI

Mit der TLS-Erweiterung SNI können beliebig viele Webseiten samt eigenen Zertifikaten auf einer IP gehostet werden. Dabei könnte jedoch der Name der Domain von Dritten belauscht werden. Ein Vorschlag der IETF sieht nun vor, SNI zu verschlüsseln.

Artikel veröffentlicht am 16. Juli 2018, 12:51 Uhr, Sebastian Grüner

TLS soll SNI künftig auch verschlüsselt unterstützen. (Bild: Pixabay/CC0 1.0)

Obwohl Version 1.3 der Netzverschlüsselung TLS fast alle Teile des Verbindungsaufbaus beim Handshake verschlüsselt, gebe es für Angreifer, die die Verbindung belauschen können, immer noch einige Wege, den Domainnamen zu bestimmen, mit dem sich ein Nutzer verbinden will. Diese Problembeschreibung stammt aus einem aktuellen Entwurf der Internet Engineering Task Force (IETF), der dieses Problem lösen soll, indem die TLS-Erweiterung SNI verschlüsselt wird. Unterstützt und vorangetrieben werden die Arbeiten von Mozilla, Fastly, Cloudflare und Apple.

SNI steht für Server Name Indication und ist erstmals 2003 als Standard veröffentlicht worden. Mit Hilfe von SNI soll erreicht werden, dass beliebig viele HTTPS-Webseiten samt eigenen Zertifikaten auf einer IP-Adresse gehostet werden können. Dazu ist der Parameter server_name eingeführt worden, der vom Client beim Verbindungsaufbau an den Server übertragen wird. Mit dieser Information kann der Server das korrekte Zertifikat der angefragten Webseiten auswählen und so eine Verbindung aufbauen.

Servername bisher unverschlüsselt

Der Parameter server_name wird bisher jedoch unverschlüsselt übertragen, so dass sich vom Angreifer vergleichsweise leicht darauf schließen lässt, welche Webseiten ein Nutzer besucht. Die TLS-Arbeitsgruppe der IETF hat sich bereits mehrfach mit diesem Problem beschäftigt, bisher jedoch noch keine allgemeingültige Lösung als Standard erarbeiten können.

In dem aktuellen Entwurf heißt es zu dem vermutlich größten Problem mit den bisherigen Bemühungen um einen SNI-Schutz: "Wenn nur private Dienste eine SNI-Verschlüsselung verwenden, dann ist die SNI-Verschlüsselung ein Zeichen dafür, dass sich ein Client mit eben einem solchen Dienst verbindet. Aus diesem Grund konzentrieren sich viele neuere Arbeiten darauf, die Tatsache zu verbergen, dass SNI geschützt wird. Leider hat das oft unerwünschte Leistungseinbußen, eine unvollständige Abdeckung oder beides zum Ergebnis."

Das nun vorgestellte Design verfolge jedoch einen anderen Ansatz. Es wird davon ausgegangen, dass sich private Dienste hinter einem Anbieter wie einem CDN oder App-Server befinden oder diese Dienste vom Anbieter verborgen werden. Die Anbieter können so die SNI-Verschlüsselung (ESNI) für alle Domains aktivieren.

SNI-Verschlüsselung dank DNS

Der Entwurf sieht vor, dass die Dienste- und Server-Anbieter die öffentlichen Schlüssel für ESNI für sämtliche eigene Domains selbst per DNS veröffentlichen. Andere Wege der Veröffentlichung seien aber ebenfalls möglich. Falls Clients der privaten Server spezialisierte Anwendungen seien - statt Browser -, könnten die öffentlichen Schlüssel etwa von solch einer Anwendung vorkonfiguriert ausgeliefert werden.

Zur Veröffentlichung der Schlüssel per DNS sieht der Entwurf einen neuen TXT-Record vor, in dem die Schlüssel gesammelt bereitgestellt werden. TLS-Clients erhalten die Schlüssel dann also direkt über eine DNS-Abfrage. Zum Absichern der DNS-Abfrage selbst verweist der Entwurf auf Techniken wie etwa DNS über HTTPS (DoH). ESNI wäre ohne derartige Techniken auch nur wenig hilfreich, heißt es in dem Entwurf.

Die Beteiligten wollen den Vorschlag auf dem IETF Meeting 102 diskutieren, das zurzeit in Montreal stattfindet. Nick Sullivan, Head of Cryptography bei Cloudflare, schreibt darüber hinaus auf Twitter, dass es bereits Implementierungen des Entwurfs für BoringSSL, NSS und Picotls gebe sowie dazugehörigen Testserver.