Zusammenfassung

  • SNI übermittelt den vorgesehenen DNS-Namen im TLS-ClientHello. So kann ein gemeinsam genutzter Endpunkt Zertifikat und Dienst auswählen, noch bevor verschlüsseltes HTTP eintrifft.
  • Der Name ist ein Selektionshinweis, kein Beweis für Identität oder Berechtigung. Seine frühe Position machte ihn beobachtbar; ECH trennt später einen öffentlichen äußeren von einem geschützten inneren Namen.

Der Server musste antworten, bevor er die Frage lesen konnte

Mehrere sichere Websites teilen sich eine Adresse. Der Client baut eine Verbindung auf, und der Server soll nun das Zertifikat der richtigen Website vorlegen. Welche Website gemeint ist, steht in der HTTP-Anfrage. Doch diese Anfrage darf erst nach dem TLS-Handshake verschlüsselt übertragen werden. Der Server soll also die passende Identität zeigen, bevor er die dafür entscheidende Frage lesen kann.

Die RFC 2246 ordnete bei TLS 1.0 Authentisierung und Schlüsselaushandlung vor den geschützten Anwendungsdaten an. Für Vertraulichkeit war das folgerichtig; für namensbasiertes virtuelles Hosting fehlte damit im entscheidenden Moment ein Auswahlmerkmal.

Die RFC 3546 führte 2003 Server Name Indication ein. Der Client nennt den gewünschten Server bereits im ClientHello. Der gemeinsame TLS-Endpunkt kann diesen frühen Namen nutzen, um Zertifikat, Sicherheitsparameter und den zuständigen Dienst zu bestimmen.

SNI löste folglich kein Namensproblem, sondern ein Reihenfolgeproblem. Der Name war vorhanden, aber eine Protokollschicht zu spät.

Eine Adresse war nicht länger gleichbedeutend mit einer Identität

HTTP konnte mehrere Hosts an einer Adresse unterscheiden, sobald die Anfrage lesbar war. TLS verlangte vorher eine kryptographische Identität. Ohne SNI blieben eigene Adressen, Zertifikate mit vielen Namen oder eine Standardkonfiguration, die für einen Teil der Verbindungen falsch war.

Damit wurden Adressplanung, Zertifikatslebenszyklus und Hosting-Topologie unnötig eng gekoppelt. SNI fügte der Adresse eine feinere Auswahl hinzu. Routing bringt die Verbindung weiterhin zum Frontend; der Servername entscheidet dort, welcher TLS-Kontext antwortet.

Diese Entkopplung wurde zu einer Grundlage für sicheres Shared Hosting, CDNs, Reverse Proxies und Cloud-Gateways. Sie machte die IP-Adresse nicht bedeutungslos. Sie machte lediglich deutlich, dass eine Netzadresse mehrere Anwendungsidentitäten erreichen kann.

Auswahl ist keine Vollmacht

Die RFC 6066 konsolidierte die Erweiterung. server_name trägt eine Namensliste; host_name bezeichnet den DNS-Namen. Erkennt ein Server den Namen nicht, kann er mit unrecognized_name abbrechen oder gemäß seiner lokalen Konfiguration fortfahren.

Gerade diese Wahl zeigt, dass SNI keine Autorität begründet. Ein Client wird nicht berechtigt, weil er einen Namen sendet. DNS wird dadurch nicht vertrauenswürdig, und ein ausgewähltes Zertifikat wird nicht automatisch gültig. Der Client muss das Zertifikat prüfen; der Anwendungsdienst muss Rechte prüfen; die spätere HTTP-Autorität muss zum Sicherheitskontext passen.

SNI ist die Aufschrift am äußeren Umschlag, nicht die Unterschrift im Dokument. Sie lenkt die Sendung an die richtige Stelle. Ob Inhalt, Absender und Befugnis stimmen, wird mit anderen Mitteln entschieden.

Der nützliche Zeitpunkt lag vor dem Schutz

Der erste ClientHello erreicht den Server, bevor aus dem Handshake Schlüssel entstehen. Würde der Name bereits mit diesen Schlüsseln verschlüsselt, müsste der Server die zur Entschlüsselung passende Konfiguration auswählen, ohne den Auswahlwert zu kennen. Das wäre zirkulär.

Der ursprüngliche SNI-Wert blieb deshalb im Klartext. Beobachter auf dem Pfad konnten zwar nicht die verschlüsselte URL oder den Inhalt lesen, aber häufig die Zieldomain. Die RFC 8744 beschreibt sowohl dieses Datenschutzproblem als auch die betrieblichen Verfahren, die sich um sichtbares SNI entwickelten.

TLS 1.3 verschlüsselt nach RFC 8446 mehr Teile des Handshakes nach dem ServerHello. Den ersten ClientHello kann es nicht rückwirkend mit noch nicht vereinbarten Schlüsseln verbergen. Die Grenze blieb bestehen.

Sichtbarkeit erzeugte Abhängigkeit

Hosting-Plattformen routeten nach SNI. Überwachungssysteme gruppierten Verbindungen danach. Firewalls und Richtlinienkomponenten trafen Entscheidungen. Was als notwendiger Selektor begann, wurde zur Schnittstelle für Akteure entlang des Pfades.

Dadurch wurde Verschlüsselung zu mehr als einer Feldänderung. Das Frontend benötigt weiterhin eine minimale öffentliche Information, um den ECH-fähigen Dienst zu erreichen. Zugleich verlieren Zwischenstellen einen Wert, auf dessen Sichtbarkeit sie ihre Abläufe gestützt haben.

Die technische Schuld liegt nicht nur in alter Software. Sie liegt auch in den Anreizen, eine zufällig verfügbare Information dauerhaft als Kontrollfläche zu behandeln.

ECH teilt öffentlichen Weg und privates Ziel

Die RFC 9849 spezifiziert Encrypted ClientHello. Der Client baut einen inneren ClientHello mit den sensiblen Angaben und verschlüsselt ihn in einen äußeren ClientHello. Dessen öffentlicher Name führt zu einem ECH-fähigen Anbieter; der eigentliche Ursprungsname bleibt innen geschützt.

IP-Adresse und äußerer Name bleiben sichtbar. ECH verspricht daher keine Metadatenlosigkeit. Es reduziert vielmehr die Genauigkeit der Information, die vor der Datenschutzgrenze erforderlich ist. Ein gemeinsamer öffentlicher Name kann viele private Ursprünge erreichen.

Akzeptanz, Ablehnung und Wiederholungsparameter werden ausdrücklich behandelt. Der Client bestätigt ECH über den geschützten Handshake. Schlägt die Entschlüsselung fehl, darf der äußere Name nicht stillschweigend zum angeforderten Ursprung umgedeutet werden.

Die neue Antwort auf das alte Ordnungsproblem lautet: Veröffentliche nur den Namen, der bis zur schützenden Infrastruktur nötig ist, und enthülle das genaue Ziel erst dahinter.

Der Zeitpunkt eines Feldes verteilt Macht

SNI brachte die Ökonomie des namensbasierten Hostings mit der Authentisierungsreihenfolge von TLS zusammen. Viele HTTPS-Identitäten konnten sich eine Adresse teilen, ohne alle denselben Zertifikatskontext zu verwenden.

SNI selbst authentisierte den Namen nie, erteilte keine Anwendungsrechte und verbarg das Ziel nicht. Nutzen und Offenlegung folgten aus derselben frühen Platzierung. ECH verschiebt die Grenze, ohne jede öffentliche Route abzuschaffen.

Die historische Lehre ist präzise: Nicht nur der Inhalt eines Protokollfeldes zählt, sondern der Zeitpunkt, zu dem es verfügbar sein muss. Wer es vor dem Schutz benötigt, schafft zugleich eine Beobachtungsmöglichkeit. Eine spätere Korrektur braucht ein minimales öffentliches Auswahlmerkmal und die Disziplin, es nicht mit dem privaten Ziel zu verwechseln.

Quellen und Grenzen der Evidenz

Die Protokollgrundlage bilden RFC 2246, RFC 3546, RFC 6066, RFC 8446, RFC 8744 und RFC 9849. Aussagen zu Hosting-Kosten, Überwachungsanreizen und Abhängigkeiten sind Folgerungen aus Nachrichtenfolge und Sichtbarkeit, keine Messungen eines einzelnen Betreibers.