SNI – Server Name Indication

Abkürzung: SNI

SNI ist eine Erweiterung des TLS-Handshakes und löst ein Problem, das aus der Reihenfolge der Schichten entsteht. Ohne sie gäbe es kein virtuelles Hosting mit HTTPS.

Warum SNI nötig wurde

Bei HTTP steht der gewünschte Hostname im Host-Header. Ein Server kann damit beliebig viele Websites unter einer IP-Adresse bedienen — er liest den Header und liefert die passende aus.

Bei HTTPS greift das nicht, denn die Reihenfolge ist ungünstig: Der Host-Header steckt in der HTTP-Anfrage, und die kommt erst nach dem TLS-Handshake. Im Handshake muss der Server aber bereits sein Zertifikat vorlegen — und welches das richtige ist, weiß er noch nicht.

Vor SNI blieb daher nur, je Hostname eine eigene IP-Adresse zu betreiben. Bei knappem IPv4-Adressraum war das der eigentliche Grund, warum HTTPS lange als teuer galt.

Wie es funktioniert

Der Client schreibt den Hostnamen in die Erweiterung server_name seines ClientHello. Der Server liest ihn, wählt das passende Zertifikat und setzt den Handshake damit fort.

Schickt ein Client keine SNI, muss der Server irgendeine Entscheidung treffen — üblicherweise liefert er das Zertifikat des als Standard konfigurierten virtuellen Hosts. Das Ergebnis ist eine Zertifikatswarnung über einen falschen Namen, obwohl Konfiguration und Zertifikat beide in Ordnung sind.

Umgekehrt müssen SNI und Host-Header zusammenpassen. Weichen sie ab, antworten manche Server mit Statuscode 421, andere liefern den falschen virtuellen Host aus. Praktisch stößt man darauf beim Testen gegen eine bestimmte IP:

curl --resolve example.net:443:203.0.113.10 https://example.net/

Hier bleibt die SNI korrekt, weil curl den Namen weiterhin kennt und nur die Auflösung umgeht. Wer stattdessen die IP in die URL schreibt, bekommt ein anderes Verhalten.

Das Datenschutzproblem

TLS 1.3 verschlüsselt fast den ganzen Handshake, einschließlich des Serverzertifikats. Die SNI gehört nicht dazu — sie muss im Klartext stehen, weil der Server ohne sie nicht weiß, welchen Schlüssel er verwenden soll.

Damit bleibt genau die Angabe sichtbar, die am meisten verrät: welche Seite aufgerufen wird. Wer den Verkehr mitschneidet, sieht nicht den Pfad und nicht den Inhalt, aber den Domainnamen. Zusammen mit der ebenfalls unverschlüsselten DNS-Abfrage ergibt das ein vollständiges Bild der besuchten Seiten.

Genutzt wird das in beide Richtungen: zur Verkehrsanalyse in Unternehmensnetzen und zur Sperrung einzelner Seiten durch Netzbetreiber, die den Handshake anhand der SNI abbrechen.

Encrypted Client Hello

Die Antwort darauf ist seit 2026 als RFC 9849 standardisiert, im Status Proposed Standard. ECH verschlüsselt nicht nur die SNI, sondern das gesamte ClientHello unter einem öffentlichen Schlüssel des Servers — und schützt damit auch die Liste der angebotenen Anwendungsprotokolle aus der ALPN-Erweiterung.

Den öffentlichen Schlüssel holt der Client vorab aus dem DNS. Nach außen sieht ein Beobachter nur noch einen Handshake zu einem gemeinsamen Außennamen, hinter dem beliebig viele Angebote liegen können. Je mehr Angebote dieselbe äußere Konfiguration nutzen, desto größer die Menge, in der ein einzelner Aufruf untergeht.

Der Haken ist die Abhängigkeit vom DNS: Wer den Schlüssel über eine unverschlüsselte DNS-Abfrage holt, verrät den Namen dort. ECH wirkt deshalb nur zusammen mit verschlüsseltem DNS.