Anzeige des Servernamens - Server Name Indication

Server Name Indication ( SNI ) ist eine Erweiterung des Computernetzwerkprotokolls Transport Layer Security (TLS) , durch die ein Client zu Beginn des Handshaking-Prozesses angibt, mit welchem Hostnamen er eine Verbindung herzustellen versucht. Dadurch kann ein Server eines von mehreren möglichen Zertifikaten auf derselben IP-Adresse und TCP-Portnummer präsentieren und somit mehrere sichere ( HTTPS ) Websites (oder jeden anderen Dienst über TLS) von derselben IP-Adresse bedienen, ohne dass alle diese Sites benötigt werden dasselbe Zertifikat verwenden. Es ist das konzeptionelle Äquivalent zu HTTP/1.1 namensbasiertem virtuellem Hosting , jedoch für HTTPS. Dadurch kann ein Proxy auch während des TLS/SSL-Handshakes Client-Datenverkehr an den richtigen Server weiterleiten. Der gewünschte Hostname ist in der ursprünglichen SNI-Erweiterung nicht verschlüsselt, sodass ein Lauscher sehen kann, welche Site angefordert wird.

Hintergrund des Problems

Vor SNI hatte der Client beim Herstellen einer TLS-Verbindung keine Möglichkeit, anzugeben, zu welcher Site er eine Verbindung herstellen möchte. Wenn ein physischer Server mehrere Sites hostet, kann der Server daher nicht wissen, welches Zertifikat im TLS-Protokoll verwendet werden soll. Genauer gesagt fordert der Client beim Herstellen einer TLS-Verbindung ein digitales Zertifikat vom Webserver an. Sobald der Server das Zertifikat sendet, überprüft der Client es und vergleicht den Namen, zu dem er versucht hat, eine Verbindung herzustellen, mit den Namen, die im Zertifikat enthalten sind. Wenn eine Übereinstimmung auftritt, wird die Verbindung normal fortgesetzt. Wenn keine Übereinstimmung gefunden wird, wird der Benutzer möglicherweise über die Diskrepanz gewarnt und die Verbindung kann abgebrochen werden, da die Nichtübereinstimmung auf einen versuchten Man-in-the-Middle-Angriff hinweisen kann . Einige Anwendungen ermöglichen es dem Benutzer jedoch, die Warnung zu umgehen, um mit der Verbindung fortzufahren, wobei der Benutzer die Verantwortung dafür übernimmt, dem Zertifikat und damit auch der Verbindung zu vertrauen.

Es kann jedoch schwierig sein – oder sogar unmöglich, weil im Voraus eine vollständige Liste aller Namen fehlt –, ein einziges Zertifikat zu erhalten, das alle Namen abdeckt, für die ein Server verantwortlich ist. Ein Server, der für mehrere Hostnamen verantwortlich ist, muss wahrscheinlich für jeden Namen (oder eine kleine Gruppe von Namen) ein anderes Zertifikat vorlegen. Es ist möglich, subjectAltName zu verwenden, um mehrere Domänen, die von einer Person kontrolliert werden, in einem einzigen Zertifikat zu enthalten. Solche „Unified Communications Certificates“ müssen bei jeder Änderung der Domänenliste neu ausgestellt werden.

Namensbasiertes virtuelles Hosting ermöglicht das Hosten mehrerer DNS-Hostnamen von einem einzigen Server (normalerweise einem Webserver) auf derselben IP-Adresse. Um dies zu erreichen, verwendet der Server einen Hostnamen, der vom Client als Teil des Protokolls präsentiert wird (bei HTTP wird der Name im Host-Header präsentiert ). Bei Verwendung von HTTPS erfolgt der TLS-Handshake jedoch, bevor der Server HTTP-Header sieht. Daher war es dem Server nicht möglich, anhand der Informationen im HTTP-Host-Header zu entscheiden, welches Zertifikat vorgelegt werden sollte, und daher konnten nur Namen, die von demselben Zertifikat abgedeckt werden, von derselben IP-Adresse bedient werden.

In der Praxis bedeutete dies, dass ein HTTPS-Server nur eine Domäne (oder eine kleine Gruppe von Domänen) pro IP-Adresse für sicheres und effizientes Surfen bedienen konnte. Die Vergabe einer separaten IP-Adresse für jeden Standort erhöht die Hosting-Kosten, da Anfragen nach IP-Adressen bei der regionalen Internet-Registrierungsstelle begründet werden müssen und IPv4-Adressen nun erschöpft sind . Bei IPv6 erhöht es den Verwaltungsaufwand, da mehrere IPs auf einem einzelnen Computer vorhanden sind, obwohl der Adressraum nicht erschöpft ist. Das Ergebnis war, dass viele Websites effektiv daran gehindert wurden, sichere Kommunikation zu verwenden.

Technische Grundlagen

SNI behebt dieses Problem, indem der Client den Namen der virtuellen Domäne als Teil der ClientHello- Nachricht der TLS-Aushandlung sendet . Dadurch kann der Server frühzeitig die richtige virtuelle Domäne auswählen und dem Browser das Zertifikat mit dem richtigen Namen präsentieren. Daher kann bei Clients und Servern, die SNI implementieren, ein Server mit einer einzigen IP-Adresse eine Gruppe von Domänennamen bedienen, für die es unpraktisch ist, ein gemeinsames Zertifikat zu erhalten.

SNI wurde die zugegebene IETF ‚s Internet RFCs im Juni 2003 durch RFC 3546, Transport Layer Security (TLS) Erweiterungen . Die neueste Version des Standards ist RFC 6066.

Auswirkungen auf die Sicherheit

Die Nutzlast der Servernamensanzeige ist nicht verschlüsselt, daher ist der Hostname des Servers, zu dem der Client eine Verbindung herzustellen versucht, für einen passiven Lauscher sichtbar. Diese Protokollschwäche wurde von Sicherheitssoftware zur Netzwerkfilterung und -überwachung sowie von Regierungen zur Implementierung von Zensur ausgenutzt. Derzeit gibt es mehrere Technologien, die versuchen, die Servernamensanzeige zu verbergen.

Domain-Fronting

Domain-Fronting ist eine Technik, bei der der gewünschte Hostname in SNI durch einen anderen ersetzt wird, der auf demselben Server oder häufiger einem als Content Delivery Network bekannten Servernetzwerk gehostet wird. Wenn ein Client Domain-Fronting verwendet, ersetzt er die Server-Domain in SNI (unverschlüsselt), belässt sie jedoch im HTTP-Host-Header (der durch TLS verschlüsselt wird), damit der Server den richtigen Inhalt bereitstellen kann. Domain-Fronting verstößt gegen den Standard, der SNI selbst definiert, daher ist seine Kompatibilität eingeschränkt (viele Dienste prüfen, ob der SNI-Host mit dem HTTP-Header-Host übereinstimmt, und weisen Verbindungen mit Domain-Fronted-SNI als ungültig zurück). Während Domain-Fronting in der Vergangenheit verwendet wurde, um staatliche Zensur zu vermeiden, ging seine Popularität zurück, weil große Cloud-Anbieter (Google, Amazons AWS und CloudFront) es in ihren Nutzungsbedingungen ausdrücklich verbieten und technische Einschränkungen dagegen haben.

Verschlüsselter Client Hallo

Encrypted Client Hello ( ECH ) ist eine TLS 1.3-Protokollerweiterung, die die Verschlüsselung der gesamten Client Hello-Nachricht ermöglicht, die während der frühen Phase der TLS 1.3-Aushandlung gesendet wird. ECH verschlüsselt die Nutzlast mit einem öffentlichen Schlüssel, den die vertrauende Partei (ein Webbrowser) im Voraus kennen muss, was bedeutet, dass ECH bei großen CDNs am effektivsten ist, die Browser-Anbietern im Voraus bekannt sind.

Die erste Version dieser Erweiterung aus dem Jahr 2018 hieß Encrypted SNI ( ESNI ) und ihre Implementierungen wurden auf "experimentelle" Weise eingeführt, um dieses Risiko des Abhörens von Domänen zu umgehen. Im Gegensatz zu ECH verschlüsselte Encrypted SNI nur das SNI und nicht das gesamte Client Hello. Die Opt-in-Unterstützung für diese Version wurde im Oktober 2018 in Firefox integriert und erforderte die Aktivierung von DNS-over-HTTPS.

Im März 2020 wurde ESNI in die ECH-Erweiterung umgearbeitet, nachdem Analysen gezeigt hatten, dass die Verschlüsselung nur des SNI nicht ausreicht. Spezifikationen erlauben beispielsweise, dass die Pre-Shared Key-Erweiterung alle Daten enthält, um die Wiederaufnahme der Sitzung zu erleichtern, sogar die Übertragung einer Klartextkopie genau desselben Servernamens, die von ESNI verschlüsselt wird. Außerdem würde das Verschlüsseln von Erweiterungen nacheinander eine verschlüsselte Variante jeder Erweiterung erfordern, jede mit möglichen Auswirkungen auf den Datenschutz, und selbst dies legt die beworbenen Erweiterungen offen. Schließlich hat der Einsatz von ESNI in der realen Welt Einschränkungen der Interoperabilität aufgedeckt. Der Kurzname lautete im März 2020 ECHO und wurde im Mai 2020 in ECH geändert.

Sowohl ESNI als auch ECH sind nur mit TLS 1.3 kompatibel, da sie auf KeyShareEntry angewiesen sind, das erstmals in TLS 1.3 definiert wurde. Um ECH zu verwenden, darf der Kunde außerdem keine TLS-Versionen unter 1.3 vorschlagen.

Im August 2020 hat die Great Firewall of China damit begonnen, den ESNI-Verkehr zu blockieren, während der ECH-Verkehr weiterhin zugelassen wird.

Im Oktober 2020 begannen der russische ISP Rostelecom und sein Mobilfunkbetreiber Tele2 damit, den ESNI-Verkehr zu blockieren. Im September desselben Jahres plante das russische Zensurministerium Roscomnadzor , eine Reihe von Verschlüsselungsprotokollen zu verbieten, darunter TLS 1.3 und ESNI, die die Zensur des Zugriffs auf Websites verhinderten.

Implementierung

Im Jahr 2004 wurde vom EdelKey-Projekt ein Patch zum Hinzufügen von TLS/SNI zu OpenSSL erstellt. 2006 wurde dieser Patch dann auf den Entwicklungszweig von OpenSSL portiert und 2007 auf OpenSSL 0.9.8 (erstmals veröffentlicht in 0.9.8f) zurückportiert.

Damit ein Anwendungsprogramm SNI implementieren kann, muss die von ihm verwendete TLS-Bibliothek es implementieren und die Anwendung muss den Hostnamen an die TLS-Bibliothek übergeben. Erschwerend kommt hinzu, dass die TLS-Bibliothek entweder im Anwendungsprogramm enthalten sein oder eine Komponente des zugrunde liegenden Betriebssystems sein kann. Aus diesem Grund implementieren einige Browser SNI, wenn sie auf einem beliebigen Betriebssystem ausgeführt werden, während andere es nur implementieren, wenn sie auf bestimmten Betriebssystemen ausgeführt werden.

Unterstützung

Verweise

Externe Links

• RFC  6066 (obsolet RFC  4366 , der RFC 3546 obsolet  )