IETF: Verschlüsselte Server-Namen für TLS

Trotz zunehmender Verschlüsselung der Datenströme im Netz können staatliche und private Spione nach wie vor per Metadaten ausspähen. Klartext-Daten beim Verbindungsaufbau verraten nach wie vor, wer mit wem kommuniziert. Ein wichtiges Klartext-Label wollen einige Entwickler bei der Internet Engineering Task Force (IETF) jetzt verschlüsseln: die Server Name Indication (SNI). Allerdings formiert sich vor dem Treffen der TLS-Arbeitsgruppe Widerstand.

Nach den Enthüllungen von Ex-NSA-Mitarbeiter Edward Snowden hat die IETF angekündigt, Massenüberwachung durch Geheimdienste und private Spione technisch unmöglich zu machen oder zumindest erheblich zu verteuern. Ein wichtiger Schritt in diese Richtung war TLS 1.3, das bereits große Teile des Verbindungsaufbaus verschlüsselt – darunter das Zertifikat, das ja den Namen des angesprochenen Servers enthält. Als wichtigstes Klartext-Label bleibt damit noch SNI.

Wer ist gemeint?

SNI wurde ursprünglich geschaffen, damit ein angesprochener Server erfährt, mit wem der Client eigentlich reden will. Denn im Zeitalter von Web-Hosting, Cloud und Content Distribution Networks werden IP-Adressen häufig geteilt. Hinter der IP-Adresse unter der ein Server angesprochen wird, stecken oft viele Dienste. Zu diesen weist die unverschlüsselte SNI den Weg. Doch wurde die SNI in der Praxis auch zur Zensur von Seiten durch nationale Firewalls oder durch Kinderschutz- oder Arbeitsplatz-"Hygiene"-Filter genutzt. Oder auch dazu, Datenströmen unterschiedliche Qualitätsklassen zuzuweisen.

Über die Verschlüsselung von SNI macht sich die TLS Arbeitsgruppe der IETF daher schon geraume Zeit Gedanken. Angesichts geteilter IP-Adressen und der zunehmenden Verschlüsselung des Datenverkehrs der Metadatenschleuder DNS könnte SNI bald das beste verbliebene Signal zur Identifikation von Endpunkten liefern, schätzt Mozilla-Entwickler Eric Rescorla, einer der Hauptautoren von TLS und einer der Leiter des Bereichs Security bei der IETF.

Bislang fürchteten die Experten allerdings, dass eine Extra-Verschlüsselung von SNI wegen der damit einher gehenden Komplexität nur wenig Anwender findet. Das hätte zugleich bedeutet, dass die wenigen Nutzer durch den Einsatz auf sich aufmerksam machen. "Don‘t stick out" sei das Prinzip, an das man sich gehalten und eine generische SNI-Verschlüsselung daher erst einmal aufgeschoben habe, erklärt Rescorla.

Zündstoff für das Meeting

In einem neuen Entwurf will er sich dazu den Trend zur Konzentration von Diensten zunutze machen. Er gehe dabei davon aus, dass private Quellen hinter einem größeren Provider, einem CDN oder App-Server verborgen sind, der SNI-Verschlüsselung für alle anschalten könne. Wie bei der IP-Adresse weise die verschlüsselte SNI (ESNI) dann lediglich auf den Provider hin.

Damit das geht, müsste der Provider künftig einen öffentlichen Schlüssel publizieren. Dann könne ein anfragender Client den "server name" im ClientHello durch den "encrypted server name" ersetzen. Der öffentliche Schlüssel soll laut Rescorlas Vorschlag im DNS veröffentlicht werden, das dann hoffentlich per DNSSEC gesichert ist. Das erinnert sehr an DANE, mit dem Dienste-Anbieter via DNSEC ihre TLS-Zertifikate publizieren können, das jedoch bislang keine große Verbreitung gefunden hat.

Das Prinzip sei eigentlich ganz einfach, schreibt Rescorla; der Teufel stecke im Detail. Denn die zusätzliche Verschlüsselung ist eine neue Fehlerquelle. Firewalls oder Home Router, die ESNI nicht unterstützten, lassen die Verbindungen häufig platzen, zeigen Rescorlas erste Analysen. Die schon bei der Einführung von TLS 1.3 Nachschlüssel fordernden US-Unternehmensvertreter haben auch bereits Widerstand angekündigt. Sie beklagen, dass das Pendel bei der IETF wirklich langsam zu sehr in Richtung Datenschutz ausschlage. Die anstehende Arbeitsgruppensitzung der IETF in Montreal dürfte also spannend werden. (ju)