Es ist kaum zu glauben, aber TLS Server Name Indication (SNI) gibt es schon seit dreizehn Jahren. In der heutigen Zeit ist es ein Dinosaurier, der jedoch seltsamerweise wenig genutzt wird. Das ändert sich jedoch endlich, und in diesem Blog erkunden wir, wie die fortschrittlichen Load Balancer von edgeNEXUS diese Funktion unterstützen können. SNI löst eines der größten Probleme, die viele mit SSL/TLS/HTTPS haben: Die Notwendigkeit, jeder Domain oder Subdomain, die gesichert werden muss, eine kostbare IP-Adresse zuzuweisen. Dies ist notwendig, da SSL/TLS die Verbindung sichert, bevor wir die anfängliche HTTP-Anfrage des Clients prüfen können, die diese wertvollen Domänennamen-Details enthält.
Die einzige Möglichkeit, um sicherzustellen, dass wir das richtige Zertifikat bereitstellen, besteht darin, nur ein Zertifikat pro IP-Adresse bereitzustellen und DNS zu verwenden, um sicherzustellen, dass Anfragen an einen bestimmten Domänennamen an die IP-Adresse eines Hosts weitergeleitet werden, der das richtige Zertifikat für diese Domäne bereitstellt. In einem privaten Unternehmen könnten wir vielleicht dieselbe IP-Adresse, aber einen anderen Port verwenden, aber dann müssen wir sicherstellen, dass jeder weiß, dass er den nicht standardisierten Port verwenden muss. Bei öffentlichen, über das Internet zugänglichen Diensten ist dies nicht wirklich eine praktikable Option.
Wir könnten Wildcard-Zertifikate verwenden, die jede mögliche Subdomäne schützen (z.B. *.jetnexus.co.uk), aber niemand mag sie, am wenigsten die Sicherheitsexperten. Was auch immer Sie von den NO!-Männern und -Frauen aus der Welt der Informationssicherheit halten mögen, sie haben wahrscheinlich Recht. Es ist schwer, etwas zu vertrauen, das buchstäblich alles innerhalb einer Domäne repräsentiert. Wie viele Geräte speichern und wie viele Mitarbeiter haben Zugriff auf das verwendete Zertifikat und den Schlüssel?
Server-Alternativnamen-Zertifikate (SAN-Zertifikate) waren schon immer verfügbar, erfordern aber die Kenntnis jeder einzelnen zu schützenden Domäne zum Zeitpunkt der Erstellung. Wenn ein Domänenname entfernt oder hinzugefügt werden soll, muss das Zertifikat neu generiert und alle betroffenen Hosts damit aktualisiert werden.
Das ist die zunehmend schwierige Entscheidung, vor der wir alle immer wieder stehen (auch unsere Benutzer und Kunden): eine IP-Adresse verbrennen oder einen Kompromiss eingehen (in jeder Hinsicht). Eine zunehmend schwierige Entscheidung, denn IP-Adressen sind eine endliche Ressource, deren Verfügbarkeit täglich abnimmt und deren Wert täglich zunimmt. Zum Glück für uns gibt es für dieses seit langem bestehende Problem seit vielen Jahren eine Lösung. Sie bietet uns das Beste aus allen Welten und hatte bis vor kurzem kaum Auswirkungen.
SNI bietet eine Methode, mit der der Client dem Server (in unserem Fall einem jetNEXUS) den Domänennamen mitteilen kann, zu dem er eine Verbindung herstellt. Dies geschieht, indem ein Erweiterungsfeld im ersten TLS-Paket des Clients (ein Hallo) mit dem Domänennamen gefüllt wird. Dieses Feld wird „in the clear“ gesendet, so dass es gelesen werden kann, bevor der Server sein SSL/TLS-Zertifikat sendet. Dies gibt dem Server die Möglichkeit, das erwartete Zertifikat zu senden (vorausgesetzt, er hat es), egal wie viele ihm zur Verfügung gestellt wurden.
So kann ein einzelner virtueller Dienst (und eine IP-Adresse) mit so vielen SSL-Zertifikaten für so viele Domainnamen konfiguriert werden, wie Sie möchten. Jedes dieser Zertifikate kann ein eigenes, gültiges SSL-Zertifikat haben, das auf der Grundlage der vom Client bereitgestellten Daten korrekt und ohne Fehler bereitgestellt wird. Bedienen Sie www.jetnexus.com und www.loadbalance.co.uk über dieselbe IP-Adresse und stellen Sie für beide gültige Zertifikate bereit; keine Kompromisse, kein Ärger und keine Verschwendung von IP-Adressen.
Darüber hinaus können Sie die Liste der vom virtuellen Dienst unterstützten Domänen jederzeit mit wenigen Klicks in der grafischen Benutzeroberfläche ändern. Fügen Sie Zertifikate hinzu oder entfernen Sie sie, um die vom Virtuellen Dienst unterstützten Domains hinzuzufügen oder zu entfernen. Vergessen Sie nur nicht, gleichzeitig auch Ihre DNS zu aktualisieren. Wenn Sie für eine oder zwei hochwertige Domains unterschiedliche reale Server verwenden möchten, ist das kein Problem, denn eine schnelle flightPATH-Regel ist nur ein paar Minuten entfernt. Das Gleiche gilt für HTTP-Komprimierung, URL-Rewrites oder was immer Sie sonst noch brauchen. Ein einziger virtueller Dienst und eine einzige IP-Adresse für mehrere Domänen sind sehr wünschenswert, aber das muss nicht die einzigartige Behandlung einschränken, die Sie auf den Datenverkehr für verschiedene Domänen anwenden möchten.
Ich höre Sie: „Wo ist der Haken?“ Nun, früher gab es sicherlich einen und das ist der Grund, warum es SNI schon so lange gibt, aber erst jetzt in Load Balancing und anderen Produkten auftaucht. Der Grund? Die Client-Unterstützung. Die Langlebigkeit der unglaublich beliebten Kombination aus Windows XP und IE6, die SNI nicht unterstützt, hat die meisten davon abgehalten, es zu verwenden. Niemand möchte möglicherweise 10-20% seines Publikums ausschließen.
Heute sind wir jedoch viel glücklicher. Windows XP hat das Ende des Supports längst hinter sich, der IE6 wird im World Wide Web zu weniger als 1% genutzt und das kostenlose Upgrade auf Windows 10 wird schnell eingeführt. Wir können endlich sicher sein, dass die Implementierung von SNI keine Auswirkungen auf unsere Kunden und unser Geschäft haben wird. Der IE ab Version 7 (auf Vista oder höher) und fast alle außer den ältesten Versionen von Chrome, Firefox und Safari unterstützen SNI. Wenn Sie überprüfen möchten, ob Ihre spezifische Benutzerbasis unterstützt wird, gibt es auch dafür eine flightPATH-Regel.
Zur Frage der Sicherheit sei gesagt, dass der Kunde Informationen im Klartext übermittelt. Dies sind Informationen, die über die Leitung abgefangen werden können. Auch der Client führt eine DNS-Abfrage im Klartext durch, bevor er eine Verbindung herstellt. Das können wir nicht kontrollieren, so dass es kein Risiko darstellt, diese Informationen später ein zweites Mal preiszugeben. Vielleicht möchten Sie mit einer flightPATH-Regel überprüfen, ob der SNI-Domänenname mit dem im HTTP-Host-Header übereinstimmt, oder es ist Ihnen egal, denn jeder ist anders. Ist das ein Hinweis auf ein Sicherheitsproblem? Wie auch immer, der Client ist verbunden und die Verbindung ist sicher. Sofern Sie keine Sicherheitsrichtlinien auf der Grundlage des Domänennamens anwenden (und das sollten Sie nicht), ist alles in Ordnung.
Wenn Sie wirklich mehr Details wollen, werfen Sie einen Blick auf den ursprünglichen RFC3546(Abschnitt 3.1), den späteren RFC6066(Abschnitt 3) und, wenn Sie glauben, dass man ihm trauen kann: Server Name Indication auf Wikipedi. Wenn Sie Sicherheit auf Anwendungsebene benötigen, basiert die edgeNEXUS WAF auf branchenführender, gehärteter Application Firewall-Technologie. Die edgeNEXUS Application Firewall ist über den edgeNEXUS App Store erhältlich und nutzt die Container-Technologie der nächsten Generation. Sie bietet einen umfassenden Sicherheitsschutz, um die PCI-DSS- und OWASP-Anforderungen zu erfüllen. Wie bereits in früheren Blog-Beiträgen beschrieben, ist flightPATH eine dynamische, ereignisbasierte Regel-Engine, die von edgeNEXUS entwickelt wurde, um den IP-, HTTP- und HTTPS-Datenverkehr intelligent zu manipulieren und zu routen. Wenn Sie mehr über die flightPATH-Verkehrsverwaltung erfahren möchten, klicken Sie bitte hier, und wenn Sie wissen möchten, wie Sie die verfügbaren Regeln optimal nutzen können, lesen Sie bitte den edgeNEXUS User Guide.
Ein einziger virtueller Dienst (und eine IP-Adresse) kann mit so vielen SSL-Zertifikaten für so viele Domainnamen konfiguriert werden, wie Sie möchten, dass er bedient wird. Jedes dieser Zertifikate kann ein eigenes, gültiges SSL-Zertifikat haben, das auf der Grundlage der vom Kunden angegebenen Daten korrekt und fehlerfrei bereitgestellt wird.
