Encrypted Client Hello und DoH: Was Perimeter-Firewalls nicht mehr sehen können

Zwanzig Jahre lang haben sich Netzwerk-Firewalls und Proxys auf ein einziges unverschlüsseltes Feld verlassen, um zu erkennen, wohin verschlüsselter Datenverkehr geht: die Server Name Indication (SNI), der Hostname, den ein Client in der ersten Nachricht eines TLS-Handshakes bekanntgibt. DNS over HTTPS (DoH, RFC 8484) verbarg bereits die DNS-Abfrage, die einer Verbindung vorausgeht. Encrypted Client Hello, inzwischen als RFC 9849 veröffentlicht, verbirgt nun auch die SNI selbst. Zusammen nehmen sie die beiden Signale weg, auf denen die meiste Egress-Filterung aufgebaut war.

Wie ECH funktioniert: ein inneres und ein äußeres ClientHello

Bei ECH baut der Client zwei ClientHello-Nachrichten. Die innere trägt das eigentliche Ziel und sensible Parameter und ist mit HPKE gegen einen öffentlichen Schlüssel verschlüsselt, den der Server im Voraus veröffentlicht hat. Die äußere, im Klartext gesendet, trägt einen gemeinsam genutzten öffentlichen Namen, typischerweise den Namen des Frontends des Anbieters, sodass ein Beobachter nur erfährt, dass der Client mit diesem Anbieter spricht (RFC 9849; Cloudflares Erklärung).

TLS ClientHello (outer, cleartext)
  server_name:            cloudflare-ech.com      <- shared public name
  encrypted_client_hello: <HPKE ciphertext>        <- real hostname is inside

Woher der Schlüssel kommt: der HTTPS-DNS-Eintrag

Der Client braucht den öffentlichen ECH-Schlüssel des Servers vor dem Handshake. Er bekommt ihn aus dem DNS, im HTTPS-Ressourceneintrag (Typ 65, RFC 9460), dessen ech-Parameter eine ECHConfigList trägt. Wir haben einen echten abgefragt. Das mit macOS ausgelieferte dig kennt den Eintrag nicht beim Namen, also fragen Sie ihn über seine Nummer ab:

$ dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
     …0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.com

Reist diese DNS-Abfrage selbst über DoH, sieht ein Netzwerkbeobachter weder die Abfrage noch, mit ECH, den Hostnamen im Handshake. Genau um diese Kombination geht es in diesem Artikel.

Ob ECH verwendet wird, hängt vom Client ab

ECH ist nichts, das ein Netzwerk einschaltet; jeder Client entscheidet selbst. Browser haben die Unterstützung bereits ausgeliefert (Chrome Platform Status), meist gekoppelt an die Nutzung von verschlüsseltem DNS. Viele andere Programme verwenden es überhaupt nicht. Der Trace-Endpunkt von Cloudflare meldet, was er empfangen hat, und das in macOS eingebaute curl sendet den Hostnamen weiterhin im Klartext:

$ curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext

Das realistische Bild heute ist also gemischt: Browser verbergen den Hostnamen zunehmend, viele andere Programme tun das nicht, und Software, die gezielt zur Umgehung von Überwachung geschrieben wurde, kann ECH und DoH bewusst einsetzen.

Was eine Perimeter-Firewall verliert — und was sie behält

Die ehrliche Zusammenfassung lautet: Hostnamen-basierte Filterung am Perimeter funktioniert bei ECH-Verkehr nicht mehr, IP-basierte Kontrollen dagegen schon. Ein Netzwerk kann weiterhin Verbindungen zu bekannten DoH-Resolvern ablehnen, was in der Praxis auch verhindert, dass Browser ECH-Schlüssel über verschlüsseltes DNS beziehen, und es kann weiterhin Adressbereiche blockieren. Was es nicht mehr kann, ist, zwei Websites hinter demselben Anbieter zu unterscheiden oder die eine zuzulassen und die andere zu blockieren, ohne TLS auf eine Weise zu brechen, die ECH gezielt erkennen soll.

Sichtbarkeit wandert zum Endpunkt

Der eine Ort, an dem der Hostname nie verborgen ist, ist die Maschine, die die Verbindung aufbaut: Das Programm hat ihn ja beim Namen angefragt. Deshalb verschiebt ECH die Kontrolle über abgehenden Verkehr zum Endpunkt. Eine host-basierte Firewall muss den Handshake gar nicht lesen; sie sieht, welcher Prozess die Verbindung geöffnet hat, zu welcher Adresse, und, sofern das Programm einen Namen aufgelöst hat, welchen Namen — bevor überhaupt verschlüsselte Bytes das Gerät verlassen. Sie sieht außerdem das eine, das ein Netzwerkgerät selbst vor ECH nie konnte: welche Anwendung auf dem Gerät gerade spricht.

• Entscheiden Sie pro Anwendung, nicht pro Hostname: Ein Browser, ein Sync-Client und eine unbekannte Binärdatei erhalten unterschiedliche Regeln.
• Behandeln Sie ein Programm, das eigenes DoH zu einem Resolver aufbaut, den das System nicht konfiguriert hat, als ein Signal, das einen Blick wert ist.
• Behalten Sie IP-basierte Sperrlisten am Perimeter bei; sie funktionieren weiterhin und kosten nichts.

Wo FireAI und HisnLabs ins Spiel kommen

ECH hides the hostname from the network, not from the machine making the connection: an on-device firewall such as FireAI still sees which process is connecting and where, and asks before an app it does not know goes online.

FireAI ist das eigene Produkt von HisnLabs: eine KI-Firewall für den Mac, die direkt auf dem Gerät läuft. Sie zeigt jede Verbindung Ihrer Apps in verständlicher Sprache und lässt Sie entscheiden, was Ihren Mac verlässt — die KI arbeitet lokal, Ihr Datenverkehr wird also nie an uns oder irgendjemand anderen gesendet. Das Sicherheitsforschungsteam von HisnLabs sorgt dafür, dass diese Entscheidungen verlässlich bleiben: Es katalogisiert, welche Domains gewöhnliche Telemetrie und welche ein echter Dienst sind, verfolgt Land und Netzwerk hinter einer Verbindung und trainiert das lokale Modell (die Autopilot-Funktion) mit echten Verkehrsmustern — ohne dass irgendetwas davon Ihren Mac verlässt.

Die technischen Entscheidungen dahinter können Sie nachlesen — oder FireAI 17 Tage lang ausprobieren — unter FireAI, von HisnLabs.