Was ist Server Name Indication (SNI)?

Mit der Server Name Indication (SNI) kann ein Server mehrere TLS-Zertifikate für verschiedene Websites unter einer einzigen IP-Adresse sicher hosten. SNI fügt den Hostnamen des Servers (Website) im TLS-Handshake als Erweiterung in die CLIENT HALLO-Nachricht ein.

Wenn Shared IPs verwendet werden, weiß der Server so welche Website angezeigt werden soll. In der Regel sind Unternehmen, die Shared IPs auf einem Server verwenden, Hosting-Anbieter. Sie stehen täglich vor dem Problem: “Wie bringe ich meinen Server dazu, das richtige Zertifikat auszuwählen und zu präsentieren?”

Anzeige

Sehen wir uns das Problem genauer an. Auf einer HTTP-Site verwendet ein Server HTTP HOST-Header, um festzustellen, welche HTTP-Website er präsentieren soll. Wenn man allerdings TLS (das Protokoll hinter HTTPS) verwendet, muss die sichere Sitzung erstellt werden, bevor man überhaupt die HTTP-Sitzung einrichten kann. Bis dahin steht kein Host Header zur Verfügung. Das Dilemma: Bei HTTPS kann der TLS-Handshake im Browser ohne ein TLS-Zertifikat überhaupt nicht abgeschlossen werden. Aber der Server weiß nicht, welches Zertifikat er präsentieren soll, weil er nicht auf den Host Header zugreifen kann.

Was ist SNI und wie trägt sie zur Lösung des Problems bei?

Server Name Indication (SNI) ist eine Erweiterung des TLS-Protokolls. Der Client gibt an, mit welchem Hostnamen er eine Verbindung herstellen möchte, indem er die SNI-Erweiterung im TLS-Handshake verwendet. Auf diese Weise kann ein Server (z. B. Apache, Nginx oder ein Load Balancer wie HAProxy) den entsprechenden privaten Schlüssel und die Zertifikatkette aus einer Liste oder Datenbank auswählen. Gleichzeitig hostet er alle Zertifikate auf einer einzigen IP-Adresse.

Wenn SNI verwendet wird, enthält der TLS-Handshake den Hostnamen des Servers, wodurch HTTPS-Websites eindeutige TLS-Zertifikate erhalten. Selbst dann, wenn sie sich auf einer Shared IP-Adresse befinden.

Mit der Server Name Indication (SNI) kann ein Server mehrere TLS-Zertifikate für verschiedene Websites unter einer einzigen IP-Adresse sicher hosten. SNI fügt den Hostnamen des Servers (Website) im TLS-Handshake als Erweiterung in die CLIENT HALLO-Nachricht ein.

Bildquelle: GlobalSign

Warum aber ist das so wichtig? Wieso brauchen wir überhaupt eine Möglichkeit, eindeutige Zertifikate für Shared IPs zu unterstützen?

Das Dilemma der IPv4-Knappheit

Das Internet Protocol Version 4 (IPv4) hat ungefähr 4 Milliarden IP-Adressen. Nur gibt es weltweit bereits mehr als 4 Milliarden internetverbundene Computer. Daher stehen wir nun endgültig vor einem Mangel an IPv4-Adressen. Das Internetprotokoll Version 6 (IPv6) sollte dieses Problem beheben, da es Billionen von Adressen bietet. Es existieren aber immer noch einige Netzwerkgeräte, die IPv6 nicht unterstützen. Es wird geschätzt, dass 90% der gängigen Betriebssysteme für Mobiltelefone, PCs und Server IPv6 unterstützen können. Wir sind also einer vollständigen IPv6-Unterstützung schon ziemlich nahe. Für die wenigen verbleibenden Systeme, die noch Shared IPs benötigen, muss man möglicherweise einen dualen Ansatz wählen: SNI für IPv4 (für die wenigen älteren Browser) und eindeutige IPs für alle Domains via IPv6 für den Rest.

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.

Wie SNI bei IPv4-Knappheit hilft

Mit SNI kann der Server mehrere TLS-Zertifikate für verschiedene Websites sicher hosten, alle unter einer einzigen IP-Adresse. So benötigt und verwendet man weniger IP-Adressen, was dazu beiträgt, dass weiterhin IP-Adressen verfügbar sind. Irgendwann werden IPv4-Adressen zwar aufgebraucht sein, insgesamt hat sich der Prozess aber verlangsamt. Dadurch haben Benutzer mehr Zeit, auf kompatible Browser, Router und Server zu updaten. SNI macht es zudem viel einfacher, mehrere Websites zu konfigurieren und zu verwalten, da sie alle auf die gleiche IP-Adresse verweisen. Das hat zusätzlich den Vorteil, dass das einfache Scannen einer IP-Adresse nicht das Zertifikat enthüllt, was wiederum zur allgemeinen Sicherheit beiträgt.

Nachteile von SNI

SNI ist eine gute Lösung für Shared IPs. Dennoch gibt es einen kleinen verbleibenden Nachteil. Dieser betrifft nur vergleichsweise wenige Internetbenutzer – nämlich diejenigen, die ältere Browser oder Betriebssysteme verwenden.

SNI wird nämlich von älteren Browsern und Webservern nicht unterstützt. Moderne Browser (üblicherweise weniger als 6 Jahre alt) können alle gut mit SNI umgehen. Die beiden größten Browser, die mit SNI zu kämpfen haben, sind der Internet Explorer unter Windows XP (oder älter, von dem geschätzt wird, dass ihn 3,18% der User im April 2018 für den Zugriff auf Websites verwendet haben) und Android 2.3 und älter (das noch von zirka 0,3% der Android-Nutzer verwendet wird). Wenn dieser Browser oder das betreffende Betriebssystem SNI nicht unterstützen, wählt der Handshake das Standardzertifikat, und das kann zu einem Common Name-Konflikt führen. Mit dem sukzessiven Verschwinden von XP und Android-Versionen vor 2.3 werden die Kompatibilitätsprobleme abnehmen. Es ist gut, zu wissen, dass Windows XP TLS 1.1 oder TLS 1.2 nicht unterstützt und mit den kommenden PCI-Anforderungen werden Benutzer viele Websites ohnehin nicht mehr besuchen können. Die Nutzung dieser Browser ist weiterhin rückläufig. Nur heißt das zugleich, dass ein kleiner Prozentsatz der Web-User aktuell Schwierigkeiten hat, eine HTTPS-Website zu empfangen, wenn sie über SNI geliefert wird.

Eine Möglichkeit, das Problem zu umgehen, ist es Multi-Domain TLS als Standardzertifikat zu verwenden. Dann lassen sich alle Domains auf der Shared IP in einem Zertifikat auflisten.

Ein weiterer erwähnenswerter Aspekt von SNI ist, dass die Verbindung in TLS 1.2 unverschlüsselt beginnt, was Clients möglicher Zensur und Überwachung aussetzt. TLS 1.3 löst dieses Problem, wird aber noch nicht vollständig unterstützt. Man sollte sich also vorbereiten auf TLS 1.3 umzusteigen, sobald es weiter verbreitet ist. Trotz dieser Nachteile überwiegen die Vorteile von SNI und wo möglich, sollte man es auch einsetzen.

Unterschiede zwischen SNI und SANs

Ein Multi-Domain-Zertifikat (auch SAN-Zertifikat genannt) ist eine weitere Möglichkeit, mit dem weitgehend ausgeschöpften IPv4-Reservoir umzugehen. Multi-Domain TLS-Zertifikate haben nicht den Nachteil der Kompatibilitätsprobleme mit Browsern oder Servern wie SNI. Sie funktionieren wie jedes andere TLS-Zertifikat und decken bis zu 200 Domains in einem einzigen Zertifikat ab. SNI wiederum kann problemlos Millionen von Domains unter derselben IP-Adresse hosten.

Warum dann nicht einfach Multi-Domain-Zertifikate verwenden?

Bei einem Multi-Domain-Zertifikat müssen alle Domains zu diesem einen Zertifikat hinzugefügt werden. Diese Domains werden als Subject Alternative Names oder SANs gelistet. Will man ein SAN hinzufügen oder entfernen oder ein Zertifikat widerrufen oder erneuern, muss das Zertifikat für alle Domains ersetzt und neu bereitgestellt werden. Dann ist sichtbar, wer das gleiche Zertifikat teilt. Wenn ein Unternehmen seine Zertifikate beispielsweise von einem Hosting-Unternehmen erhält, das Multi-Domain-Zertifikate für seine Kunden verwendet, ist das Unternehmen vielleicht nicht ganz so erfreut, wenn es feststellt, dass es sein Zertifikat mit einem Wettbewerber teilt.

Und je mehr Namen hinzugefügt werden, desto umfänglicher wird das Zertifikat. Da wir gerade über Kilobyte sprechen: Diese Informationen müssen heruntergeladen werden, bevor irgendetwas anderes auf den Websites heruntergeladen werden kann. Im Wesentlichen verhindert das für eine oder mehrere Millisekunden, dass die Seite geladen wird. Das sind keine großen Verzögerungen. Aber wenn der Kampf um das Google-Ranking sehr eng ist, können selbst ein paar Millisekunden bei der Ladegeschwindigkeit einer Seite entscheidend sein.

Ein weiterer gewichtiger Nachteil ist, dass Multi-Domain-Zertifikate keine OV- (Organization Validated) oder EV- (Extended Validation) SANs unterstützen, wenn sie von Unternehmen gemeinsam genutzt werden. Im oben genannten Szenario des Hosting-Unternehmens mit Domains von mehreren Unternehmen, die unter einem Zertifikat als SANs aufgeführt sind, hätten diese Domains zum Beispiel die DV (Domain Validated) Stufe. Diese Validierungsstufen beziehen sich auf die Menge an Informationen, die vor der Ausstellung des Zertifikats verifiziert werden. DV bedeutet, dass der Inhaber der Website die administrative Kontrolle über die Domain nachgewiesen hat, während OV und EV zusätzliche Informationen über die Identität des Websiteinhabers (z. B. gesetzliche und betriebliche Existenz) verifizieren.

Bekannte Benutzer von Multi-Domain-Zertifikaten sind z. B. Cloudflare und Google. Google verwendet sie nur für ältere Clients, die SNI nicht unterstützen.

Was tun? SNI- oder Multi-Domain-Zertifikate?

Im Endeffekt erreichen SNI- und Multi-Domain-Zertifikate dasselbe – nämlich die Anzahl der benötigten IPv4-Adressen zu reduzieren. Nur gehen sie dabei umgekehrt vor: SNI bedeutet, Sie bekommen eindeutige Zertifikate für jede Domain (d. h. viele Zertifikate) und diese Domains teilen die gleiche IP. Bei Multi-Domain-Zertifikaten hingegen verwenden Sie ein Zertifikat für viele Domains, was wiederum eine IP für viele Domains bedeutet.

Fazit

Es ist Platz für beide, sowohl SNI als auch Multi-Domain-Zertifikate haben ihre Berechtigung entweder separat oder kombiniert miteinander. So lassen sich weiterhin Zertifikate für Kunden hosten, ohne sich um dedizierte IP-Adressen oder Kompatibilität Gedanken machen zu müssen.

Paul van Brouwershaven, GlobalSign

www.globalsign.com/de-de
 

Anzeige

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.