Die Firma Mozilla hat angekündigt, dass die stabile Version von Firefox nun die Unterstützung für den ECH-Mechanismus (Encrypted Client Hello) umfasst, der die Entwicklung der Technologie ESNI (Encrypted Server Name Indication) fortsetzt und dazu dient, Informationen über TLS-Sitzungsparameter wie das angeforderte Domain-Namen zu verschlüsseln. Ursprünglich wurde der Code für die Arbeit mit ECH in die Veröffentlichung von Firefox 85 eingefügt, jedoch standardmäßig deaktiviert. In Chrome wurde die Unterstützung für ECH schrittweise ab der Version Chrome 115 aktiviert.
Da zusätzlich zur Verbindung mit dem Server durch das Auslaufen von Informationen über die angeforderten Domains über DNS erfolgt, ist neben ECH die Technologie DNS over HTTPS oder DNS over TLS erforderlich, um den DNS-Verkehr zu verschlüsseln. Firefox wird ECH nicht nutzen, ohne dass DNS over HTTPS in den Einstellungen aktiviert ist. Die Unterstützung von ECH im Browser kann auf dieser Seite überprüft werden.
Ein Faktor für die standardmäßige Aktivierung der ECH-Unterstützung in Firefox war die kürzliche Einführung durch Cloudflare, die ECH in ihrem Content Delivery Network unterstützt. Praktisch gesehen, da die Daten zu den angeforderten Hosts bei der Verwendung von ECH vor der Analyse verborgen sind, erfordert das Filtern und Blockieren von unerwünschten Websites, die das Cloudflare-CDN nutzen, nun die Blockierung des gesamten Cloudflare-Netzwerks, das Blockieren aller Anfragen mit ECH oder die Einrichtung von HTTPS-Abfangmaßnahmen mittels gefälschter Root-Zertifikate auf dem Nutzer-System.
Ursprünglich wurde das TLS-Erweiterung SNI verwendet, um den Betrieb mehrerer HTTPS-Websites unter einer einzigen IP-Adresse zu ermöglichen. Dabei wurde der Name des angeforderten Hosts im ClientHello-Nachricht angegeben, die vor dem Aufbau des verschlüsselten Kommunikationskanals gesendet wurde. Diese Besonderheit erlaubte es, Anfragen frühzeitig in der Verarbeitung der Verbindung auf virtuelle Hosts zu verteilen, ermöglichte jedoch auch den Internetanbietern selektives Filtern des HTTPS-Traffics und das Analysieren, welche Websites der Nutzer aufruft, was vollständige Vertraulichkeit bei der Anwendung von HTTPS verhinderte.
Um dieses Problem zu lösen und die Offenlegung von Informationen über die angeforderte Website zu verhindern, wurde später die ESNI-Erweiterung vorgeschlagen, die die Verschlüsselung von Daten mit dem Hostnamen implementiert. Bei der Einführung von ESNI stellte sich heraus, dass der vorgeschlagene Mechanismus nicht alle möglichen Quellen für Datenlecks über den Host abdeckt und seine Anwendung nicht ausreicht, um eine vollständige Vertraulichkeit der HTTPS-Sitzungen sicherzustellen. Insbesondere wurde beim Wiederherstellen einer zuvor etablierten Sitzung der Domainname weiterhin im Klartext in den TLS-Erweiterungsparametern PSK (Pre-Shared Key) angegeben. Zudem zeigten die Versuche zur Einführung von ESNI Probleme hinsichtlich der Kompatibilität und Skalierbarkeit, die einer weit verbreiteten Akzeptanz von ESNI im Wege standen.
Berücksichtigt man die festgestellten Mängel, wurde ein neuer universeller Mechanismus namens ECH entwickelt, der die Verschlüsselung der Parameter beliebiger TLS-Erweiterungen ermöglicht. Technisch gesehen besteht der Hauptunterschied zwischen ECH und ESNI darin, dass anstelle einzelner Felder die gesamte Nachricht ClientHello verschlüsselt wird. ECH sieht die Aufteilung von ClientHello in zwei separate Nachrichten vor – die verschlüsselte Nachricht ClientHelloInner (SNI Inner) und die unverschlüsselte Basisnachricht ClientHelloOuter (SNI Outer). In SNI Outer werden nicht vertrauliche Daten, wie die TLS-Version und die Liste der verwendeten Cipher, übermittelt, sowie ein allgemeiner Domainname, der nicht mit dem tatsächlichen Namen der angeforderten Domain verknüpft ist. Zum Beispiel wird für alle Cloudflare-Kunden in SNI Outer der allgemeine Host "cloudflare-ech.com" angegeben, während der tatsächliche Name des angeforderten Hosts in der verschlüsselten SNI Inner übermittelt wird und nicht für die Analyse zur Verfügung steht.
ECH verwendet auch ein alternatives Schlüsselverbreitungsschema für die Verschlüsselung – Informationen über den öffentlichen Schlüssel werden in DNS-Einträgen vom Typ HTTPSSVC und nicht in TXT-Einträgen übermittelt. Authentifizierte Ende-zu-Ende-Verschlüsselung wird verwendet, um den Schlüssel zu erhalten und zu verschlüsseln, basierend auf dem HPKE-Mechanismus (Hybrid Public Key Encryption). ECH unterstützt auch eine sichere Schlüsselrückübertragung vom Server, die bei der Schlüsselrotation verwendet werden kann. Server und zur Lösung von Problemen beim Abrufen veralteter Schlüssel aus dem DNS-Cache.
Quelle: opennet.ru
