Einleitung
Virtuelles Hosting ist die Praxis, mehrere Websites auf der Website zu bedienen gleicher Server. Obwohl dies heutzutage die Norm ist, war dies in den frühen Tagen von HTTP (Versionen vor 1.1) nicht möglich.
Ursprünglich konnte ein Server nur mehrere Websites auf demselben Computer (dh unter derselben IP-Adresse) hosten, sofern jeder Website ein dedizierter Port zugewiesen wurde. Dies war keine ideale Lösung, da Browser standardmäßig portieren 80 für HTTP, sofern der Benutzer kein anderes angibt. Infolgedessen entschieden sich die meisten Websitebesitzer für einen dedizierten Server, um das Risiko zu vermeiden, dass sich Benutzer nicht an die richtige Portnummer erinnern und auf einer anderen Website landen.
Als jedoch mehr Benutzer dem Web beitraten und mehr Netzwerkgeräte online angezeigt wurden, nahm die Anzahl der verfügbaren IP-Adressen mit alarmierender Geschwindigkeit ab. Diese erwartete Erschöpfung, bekannt als Erschöpfung des IPv4-Adressbereichshat die Industrie dazu gebracht, verschiedene Gegenmaßnahmen zu entwerfen und umzusetzen, wie z IPv6 (IPv4-Nachfolger), der unterstützen kann mehr Adressen als wir jemals brauchen werden. Obwohl IPv6 eine praktikable Lösung ist, wurde es leider nur langsam eingeführt. Gemäß Googles IPv6-StatistikenZum Zeitpunkt dieses Schreibens werden nur etwa 25% der Internetgeräte über IPv6 bereitgestellt.
Virtuelles Hosting wurde auch als frühzeitige Minderung des Erschöpfungsproblems mit der Einführung des implementiert Host Header in HTTP 1.1. Browser, die über HTTP 1.1 kommunizierten, konnten nun eine Verbindung zum Port eines Servers herstellen 80 und geben Sie den Domainnamen an (z www.ssl.com) der Website, die sie in der besuchen wollten Host Header. Unabhängig davon, wie viele Websites ein Server auf demselben Port gehostet hat, kann er diese Informationen verwenden, um die richtige Website zu identifizieren und deren Inhalt zurückzugeben.
HTTPS und virtuelles Hosting
Zahlreiche veröffentlichte Berichte über Netzwerkschwachstellen und Angriffe auf Webbenutzer haben die Branche jedoch dazu motiviert Wechseln Sie von unsicherem HTTP zu seinem sichereren alternativen HTTPS. Die breite Akzeptanz von HTTPS hat die allgemeine Benutzersicherheit verbessert. Die zusätzlichen Verbesserungen haben jedoch auch die allgemeine Komplexität der Webkommunikation erhöht.
Im Prinzip ist HTTPS HTTP ziemlich ähnlich, mit der Ausnahme, dass die HTTPS-Kommunikation zwischen Browsern und Servern verschlüsselt ist. Kurz gesagt, HTTPS erfordert, dass Server Browsern ein gültiges SSL-Zertifikat zur Verfügung stellen, das von einer öffentlich vertrauenswürdigen Person ausgestellt wurde Zertifizierungsstelle (CA), wie z SSL.com. Ein Browser kann dann den im Zertifikat enthaltenen öffentlichen Schlüssel verwenden, um Richten Sie einen verschlüsselten Kommunikationskanal mit dem Server ein. Darüber hinaus wird ein Zertifikat für einen bestimmten Domainnamen ausgestellt, das der Browser auf Übereinstimmung mit der Domain überprüft, die der Benutzer besuchen möchte. Unabhängig davon, wie viele Websites der Server hostet, erwarten Browser, dass sie ein gültiges SSL-Zertifikat für die von ihnen angeforderte Website finden.
Der aufmerksame Leser kann das Problem bereits erkennen: Der Browser benötigt das Zertifikat der richtigen Website, um den verschlüsselten Kanal einzurichten und das zu senden Host Header, während der Server die benötigt Host Header, um das Zertifikat der richtigen Site zu finden. Dies ist ein klassisches Henne-Ei-Problem.
Es ist offensichtlich, dass virtuelles Hosting, wie es für HTTP konzipiert wurde, für HTTPS nicht funktioniert, da die Sicherheitskontrollen verhindern, dass Browser das senden Host Informationen an den Server übergeben. Da das IPv4-Erschöpfungsproblem immer noch ungelöst ist und die Branche zunehmend Cloud-Technologien einsetzt (die einen Lastausgleich und mehrere Failover-Backend-Server erfordern), ist virtuelles Hosting immer noch eine Notwendigkeit.
Was ist mit Multi-Domain-Zertifikaten?
Eine vorgeschlagene Lösung für dieses Problem ist die Verwendung von Multi-Domain oder SAN-Zertifikate. Ein einzelnes SAN-Zertifikat kann Hunderte verschiedener Domänennamen sichern, und Browser beschweren sich nicht, wenn sie den Domänennamen, den sie besuchen möchten, in der Domänenliste des SAN-Zertifikats finden. Nachdem der verschlüsselte Kanal konfiguriert wurde, kann der Browser den senden Host Header an den Server und fahren Sie wie in jedem anderen Fall fort. Dies ist eine großartige Idee, die eine bereits vorhandene und verfügbare Technologie nutzt, aber dieselben Mechanismen, die die Sicherheit von SAN-Zertifikaten gewährleisten, haben auch einige potenziell unerwünschte Nebenwirkungen mit sich gebracht:
SAN-Zertifikate sind ein hervorragendes Tool zum Sichern mehrerer Domänen, die derselben Entität gehören (Person, Unternehmen oder Organisation). Die Verwendung beim gemeinsamen Hosting ist jedoch etwas unpraktisch. Immer wenn eine neue Domäne zum Zertifikat hinzugefügt oder daraus entfernt werden kann, muss von der Zertifizierungsstelle ein neues Zertifikat mit der neuesten Liste von Domänen ausgestellt und auf allen Domänen erneut bereitgestellt werden.
Darüber hinaus können SAN-Zertifikate nur als ausgestellt werden Organisation validiert (OV) oder erweitert validiert (EV) if alle Domänen gehören derselben Organisation an. Diese Validierungsstufen beziehen sich auf die Menge und Art der von der Zertifizierungsstelle überprüften Informationen des potenziellen Zertifikatsinhabers bevor Sie ihnen das Zertifikat ausstellen. Es hat sich gezeigt, dass je höher die Validierungsstufe ist, desto mehr Vertrauen die Benutzer in die Website setzen und das Vertrauen der Benutzer die Markenbekanntheit und die Conversion-Raten beeinflussen kann.
Schließlich ist es in gemeinsam genutzten Webhosting-Umgebungen durchaus üblich, dass ein Unternehmen einen Server mit anderen Unternehmen oder Organisationen (auch mit seinen Konkurrenten) teilt. Da die Domänen in SAN-Zertifikaten öffentlich aufgeführt sind, zögern Geschäftsinhaber möglicherweise, dasselbe Zertifikat mit Drittunternehmen zu teilen.
Obwohl SAN-Zertifikate leistungsstarke und vielseitige Tools mit unzähligen Anwendungen sind, haben diese Probleme die IETF - das Leitungsgremium für Internetstandards - dazu motiviert, nach besser geeigneten Ansätzen für das spezifische Problem virtuell gehosteter HTTPS-Websites zu suchen.
Anzeige des Servernamens zur Rettung
Die Lösung wurde in Form der implementiert Servername-Angabe (SNI) Erweiterung der TLS Protokoll (der Teil von HTTPS, der sich mit Verschlüsselung befasst).
Mit SNI können Browser den Domänennamen angeben, zu dem sie während des SNI eine Verbindung herstellen möchten TLS Handschlag (die anfängliche Zertifikatsaushandlung mit dem Server). Infolgedessen können Websites ihre eigenen SSL-Zertifikate verwenden, während sie noch auf einer gemeinsam genutzten IP-Adresse und einem gemeinsam genutzten Port gehostet werden, da HTTPS-Server die SNI-Informationen verwenden können, um die entsprechende Zertifikatkette zu identifizieren, die zum Herstellen der Verbindung erforderlich ist.
Wenn der verschlüsselte Kommunikationskanal konfiguriert wurde, kann der Browser anschließend den Domainnamen der Website in die Liste aufnehmen Host Header und fahren Sie wie gewohnt fort. Im Wesentlichen hat SNI dieselbe Funktion wie HTTP Host Header während der Erstellung der verschlüsselten Verbindung.
Mit diesem einfachen Trick konnten Server schließlich mehrere HTTPS-Websites auf demselben Port hosten. Wie bei den meisten Internet-Technologien weist SNI jedoch einige Einschränkungen auf.
Bedenken hinsichtlich der SNI-Unterstützung
Obwohl SNI seit seiner ersten Entwicklung im Jahr 1999 ziemlich ausgereift ist, gibt es immer noch einige ältere Browser (IE unter Windows XP) und Betriebssysteme (Android-Versionen <= 2.3), die dies nicht unterstützen. Eine umfassende Liste der Browser und Betriebssysteme, die SNI unterstützen, finden Sie unter dieser Tisch.
Obwohl die Marktanteile von Browsern, die SNI nicht unterstützen (und im weiteren Sinne das Auftreten dieses Ereignisses), im Vergleich zu modernen Browsern winzig sind, greift ein Browser, wenn er SNI nicht erkennt, auf das Standard-SSL-Zertifikat zurück und erstellt möglicherweise ein Fehler bei der Nichtübereinstimmung des allgemeinen Namens.
Viele Unternehmen wie Google implementieren SNI für die Kunden, die es unterstützen, und greifen in den seltenen Fällen, in denen dies nicht der Fall ist, auf SAN-Zertifikate zurück. Natürlich wird dieses Problem voraussichtlich abnehmen, da immer mehr Benutzer und Geschäftsinhaber ihre Systeme auf moderne Technologien aktualisieren.
Bedenken hinsichtlich des Datenschutzes von SNI
Die aktuelle stabile Version von TLS (Version 1.2) überträgt den ersten Teil des Handshakes und damit die SNI-Informationen unverschlüsselt. Folglich kann ein Netzwerkangreifer das Webprotokoll eines Benutzers ermitteln, obwohl die Webkommunikation selbst vollständig verschlüsselt ist.
Verschiedene Cloud-Dienstanbieter wie Amazon oder Google haben eine (schmutzige) Problemumgehung zugelassen, die als bekannt ist Domain-Fronting. Durch das Domain-Fronting kann die Offenlegung des Webprotokolls verhindert werden, da SNI-Informationen durch Verwendung des Hostnamens des Cloud-Anbieters im Internet verschleiert werden TLS Aushandlung und die Zielsite im HTTP-Header. Diese Methode ist jedoch nicht mehr praktikabel, da Google und Amazon dies öffentlich erklärt haben Deaktivierte Unterstützung für Domain-Fronting in ihren Diensten ab April 2018.
Glücklicherweise wurde eine systemischere Lösung als vorgeschlagen Versuchsentwurf Detaillierung der Verschlüsselter SNI (ESNI) Erweiterung für die neueste TLS Version, 1.3. ESNI verschlüsselt SNI-Informationen und mindert so alle Datenschutzbedenken. Unglücklicherweise, TLS 1.3 ist in der Branche noch nicht weit verbreitet, obwohl es noch nicht weit verbreitet ist TLS 1.3 wird langsam zum De-facto-Netzwerksicherheitsprotokoll. Halten Sie Ausschau nach zukünftigen Artikeln von uns über den Status von ESNI und den Datenschutz von HTTPS und TLS.
Zusammenfassung
Zusammenfassend können Sie mit SNI Millionen von HTTPS-Websites auf einem einzigen Server hosten. Abhängig von Ihrem Einzelfall funktioniert ein SAN-Zertifikat jedoch möglicherweise besser für Sie. Die Datenschutzbedenken in Bezug auf SNI bestehen weiterhin, es gibt jedoch auch eine mögliche Lösung für ESNI. In jedem Fall können Sie mit einer oder einer Kombination dieser beiden Methoden mit minimalem Aufwand problemlos virtuelles Hosting für alle Ihre Websites implementieren.
Wenn Sie weitere Fragen zu SNI haben oder nicht wissen, wie Sie zwischen SANs und SNI wählen sollen, beantworten wir gerne alle Fragen unserer Kunden zu SNI PKI Bedürfnisse. Schreiben Sie uns einfach eine E-Mail an support@ssl.com und ein Experte wird Ihnen helfen.
