Hinweis: Sie werden vielleicht feststellen, dass wir hier den technisch korrekten Begriff TLS-Zertifikat anstelle von SSL verwenden, da TLS-Protokolle, die Nachfolger von SSL, eigentlich heute verwendet werden. Weitere Erklärungen finden Sie in unserem Post über TLS vs. SSL.
Mit der Server Name Indication (SNI) kann ein Server mehrere TLS-Zertifikate für mehrere 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. So weiß der Server, welche Website angezeigt werden soll, wenn Shared IPs verwendet werden. 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?"
Sehen wir uns das Problem einmal 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 (dem 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.
Wir haben also folgendes 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 es 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, die zum Herstellen der Verbindung erforderlich sind. 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.
Sie fragen sich vielleicht, warum dies so wichtig ist. Warum 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. Aber es gibt weltweit bereits mehr als 4 Milliarden internetverbundene Computer. Daher stehen wir vor einem Mangel an IPv4-Adressen. Das Internetprotokoll Version 6 (IPv6) sollte dieses Problem beheben, da es Billionen von Adressen bietet. Aber es gibt 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. Daher sind wir der vollständigen Unterstützung von IPv6 sehr nahe gekommen. Für die wenigen verbleibenden Systeme, die noch Shared IPs benötigen, muss möglicherweise ein dualer Ansatz gewählt werden: SNI für IPv4 für die wenigen älteren Browser und eindeutige IPs für alle Domains via IPv6 für den Rest.
Wie SNI bei IPv4-Knappheit helfen kann
Mit SNI kann der Server mehrere TLS-Zertifikate für mehrere Websites sicher hosten, alles unter einer einzigen IP-Adresse.
So benötigt und verwendet man weniger IP-Adressen, was dazu beiträgt, dass noch IP-Adressen verfügbar sind. Obwohl wir irgendwann evtl. keine IPv4-Adressen mehr haben, hat sich der Prozess verlangsamt, wodurch Benutzer mehr Zeit erhalten, auf kompatible Browser, Router und Server zu updaten.
SNI macht es auch viel einfacher, mehrere Websites zu konfigurieren und zu verwalten, da sie alle auf die gleiche IP-Adresse verweisen können. 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.
Gibt es Nachteile bei SNI?
Es ist klar, dass SNI eine großartige Lösung für Shared IPs ist, dennoch gibt es einen kleinen verbleibenden Nachteil. Dieser betrifft nur einen sehr kleinen Teil der Internetbenutzer - diejenigen, die ältere Browser oder Betriebssysteme verwenden.
SNI wird in älteren Browsern und Webservern nicht unterstützt. Moderne Browser (üblicherweise weniger als 6 Jahre alt) können alle gut mit SNI umgehen. Aber die zwei größten alten Browser, die mit SNI zu kämpfen haben, sind 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 von ca. 0,3% der Android-Nutzerverwendet wurde). Wenn der alte Browser oder das Betriebssystem SNI nicht unterstützt, wählt der Handshake das Standardzertifikat, was zu einem Common Name Konflikt führen kann.
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. Aber das bedeutet auch, dass ein kleiner Prozentsatz der Web-User aktuell Schwierigkeiten hat, eine HTTPS-Website zu empfangen, wenn sie über SNI geliefert wird.
Es gibt hier eine vollständige Liste der Browser und Versionen, die SNI unterstützen und nicht unterstützen.
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 (mehr dazu im Folgenden).
Ein weiterer erwähnenswerter Aspekt von SNI ist, dass die Verbindung in TLS 1.2 unverschlüsselt beginnt, was Clients Zensur und Überwachung aussetzt. TLS 1.3 hat dieses Problem gelöst, wird aber noch nicht vollständig unterstützt. Stellen Sie daher sicher, dass Sie bereit sind, zu TLS 1.3 zu wechseln, sobald es weit verbreitet ist.
Diese Schwierigkeiten sind sicherlich nicht genug, um die Vorteile von SNI herabzusetzen. Wir empfehlen Ihnen, SNI zu verwenden, wo immer Sie können.
Unterschiede zwischen SNI und SANs
Ein Multi-Domain-Zertifikat (manchmal auch SAN-Zertifikat genannt) ist eine weitere Möglichkeit, mit der Erschöpfung von IPv4 zu verfahren. Multi-Domain TLS-Zertifikate haben nicht die Nachteile der Kompatibilität 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 verwenden wir dann nicht einfach Multi-Domain-Zertifikate?
Bei einem Multi-Domain-Zertifikat müssen alle Domains zu dem einen Zertifikat hinzugefügt werden. Diese Domains werden als Subject Alternative Names oder SANs gelistet. Wenn ein SAN hinzugefügt oder entfernt werden muss oder ein Zertifikat widerrufen oder erneuert werden muss, muss das Zertifikat für alle Domains ersetzt und neu bereitgestellt werden. Es ist auch 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 dad Unternehmen möglicherweise nicht ganz erfreut, ein Zertifikat mit seinem Wettbewerber zu teilen.
Dadurch wird das Zertifikat auch größer und je mehr Namen hinzugefügt werden, desto umfänglicher wird es. Da wir gerade über Kilobyte sprechen: Diese Informationen müssen heruntergeladen werden, bevor irgendetwas anderes auf den Websites heruntergeladen werden kann. Im Wesentlichen hindert es, je nach Qualität der Internetverbindung, die Website für eine oder mehrere Millisekunden daran, geladen zu werden. 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 wichtiger Nachteil ist, dass Multi-Domain-Zertifikate keine OV- (Organization Validated) oder EV- (Extended Validation) SANs unterstützen können, 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 auch 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 verwenden?
Im Endeffekt erreichen SNI- und Multi-Domain-Zertifikate dasselbe - nämlich die Anzahl der benötigten IPv4-Adressen zu reduzieren - Sie erreichen dies auf umgekehrte Weise:
SNI bedeutet, dass Sie eindeutige Zertifikate für jede Domain (d. h. viele Zertifikate) haben können und diese Domains teilen die gleiche IP. Bei Multi-Domain-Zertifikaten hingegen verwenden Sie einfach ein Zertifikat für viele Domains, was wiederum eine IP für viele Domains bedeutet.
Es wird deutlich, dass sowohl für SNI als auch für Multi-Domain-Zertifikate Platz ist - entweder allein oder in Kombination. Mit diesen Lösungen können Sie weiterhin Zertifikate für Kunden hosten, ohne sich um dedizierte IP-Adressen oder Kompatibilität Gedanken machen zu müssen.
Wenn Sie mit GlobalSign über eine für Sie richtige Lösung sprechen möchten, kontaktieren Sie uns noch heute.
