TLS 1.3 sendet den Servernamen weiterhin im Klartext

Ein Listener auf TLS 1.3 umzustellen ändert, was ein Beobachter lesen kann, aber nicht so viel, wie die Versionsnummer vermuten lässt. Das ClientHello wandert weiterhin vor jeder ausgehandelten Verschlüsselung, und in einer gewöhnlichen Verbindung steht der angeforderte Servername dort im Klartext. Encrypted Client Hello ist der Mechanismus, der ihn verbirgt, und es ist eine eigene Bereitstellung mit eigenen Voraussetzungen. Führen Sie diese vier Schritte aus, bevor Sie eine Richtlinie schreiben, die eines der beiden Verhalten annimmt.

Was der Handshake tatsächlich preisgibt

TLS 1.3 verschlüsselt das Zertifikat des Servers und den größten Teil des Handshakes, der auf das ServerHello folgt. Alles, was der Client zuerst sendet, liegt außerhalb dieses Schutzes, weil die Schlüssel noch nicht existieren. Die Server Name Indication ist Teil dieses ersten Flugs, weshalb ein passiver Beobachter sie weiterhin lesen kann, ohne etwas aufzubrechen.

Die ECH-Spezifikation, RFC 9849, ändert dies, indem sie ein inneres ClientHello für einen kooperierenden Server verschlüsselt. Der äußere Handshake bleibt bestehen und trägt einen öffentlichen Namen, den das Netz sehen kann, sodass die Bereitstellung weiterhin eine äußere Identität braucht, die für Zwischenstationen Sinn ergibt. Dieser äußere Name ist der Teil, den Leute übersehen, wenn sie erwarten, dass die Verbindung anonym wird. Er ist ein Deckname, kein verborgener Name, und er muss sich wie jeder andere auflösen und authentifizieren.

Nichts davon verbirgt den Zustellweg. Quell- und Zieladressen, Ports, Paketgrößen und Zeitverhalten bleiben beobachtbar, und die sagen oft mehr darüber, wer spricht, als der Name. Namensauflösung und Beziehungen auf Anwendungsebene sind eine weitere Schicht, jede mit eigener Sichtbarkeit.

Ein ClientHello lesen statt zu vermuten

Die Version im ServerHello sagt Ihnen nicht, was der Client gesendet hat. Sehen Sie sich den ersten Flug direkt an, und zwar von einer Position aus, die dem Beobachter entspricht, der Sie interessiert.

openssl s_client -connect app.plant.example:443 -servername app.plant.example -tls1_3 </dev/null> 2>/dev/null | head -20
sudo tcpdump -ni eth0 -c 40 'tcp port 443' -w /tmp/tls.pcap
tshark -r /tmp/tls.pcap -Y 'tls.handshake.extensions_server_name' -T fields -e tls.handshake.extensions_server_name

Der erste Befehl führt einen Handshake aus und zeigt die ausgehandelten Parameter, einschließlich der Protokollversion und des Namens, den Sie angefordert haben. Der zweite zeichnet die ersten Pakete einer echten Verbindung auf, und der dritte extrahiert das SNI-Feld aus dieser Aufzeichnung. Ist das Feld gefüllt, kann der von Ihnen nachgeahmte Beobachter es lesen.

Zeichnen Sie auf der Clientseite und auf dem Pfad getrennt auf, wenn die beiden nicht übereinstimmen, denn eine lokale Aufzeichnung kann einen Namen zeigen, den eine Middlebox später umschreibt oder verwirft. Zeichnen Sie außerdem von einem Host auf, der TLS nicht selbst terminiert, da ein terminierender Proxy den Klartext konstruktionsbedingt sieht und nichts darüber beweist, was das Netz sieht.

Eine ECH-Erweiterung ist eine Behauptung, kein Beweis

Eine ECH-Erweiterung in einem ClientHello zu sehen heißt nicht, dass die Verbindung ECH verwendet hat. Clients senden GREASE ECH, wenn sie keine brauchbare Konfiguration haben, gerade damit ihre Handshakes einheitlich aussehen. Die Erweiterung ist vorhanden, das innere Hello ist ein Köder, und der tatsächliche Name ist weiterhin lesbar.

dig +short HTTPS app.plant.example
openssl s_client -connect app.plant.example:443 -tls1_3 -status </dev/null> 2>/dev/null | grep -i -E 'ech|status_request'

Der erste Befehl zeigt, ob der Ursprung einen HTTPS-Ressourceneintrag mit einem ECH-Konfigurationsparameter veröffentlicht, denn so lernen Clients den Schlüssel. Der zweite sucht nach Statusinformationen des Handshakes, wobei die Erfolgsmeldung eines Clients der stärkere Beleg ist. Die Annahme ist entscheidend: Ein Server, der nicht den passenden Schlüssel besitzt, kann das innere Hello nicht entschlüsseln, und die Verbindung fällt zurück.

Prüfen Sie auch den Client, denn Browser-Unterstützung und Konfiguration unterscheiden sich nach Version und Plattform. Eine Richtlinie, die auf „moderne Browser nutzen ECH“ baut, ist eine Vermutung über einen Bestand, keine Tatsache über Ihren Bestand. Erfassen Sie die Versionen, die sich tatsächlich verbinden, und testen Sie dann je eine davon. Dieselbe Seite, die von einem aktuellen Desktop-Browser funktioniert, verbirgt bei einem älteren Client im selben Netz möglicherweise nichts mehr.

Den Beobachterbereich in die Richtlinie schreiben

Legen Sie fest, wo der Beobachter sitzt und was an diesem Punkt sichtbar ist, bevor Sie entscheiden, worauf eine Maßnahme bauen darf. Die Verbindung eines Browsers zu einer Website, ein äußerer VPN-Transport und ein TLS-terminierender Proxy legen jeweils andere Fakten offen, und eine für eine Position geschriebene Regel lässt sich selten sauber auf eine andere übertragen.

Wenn eine Maßnahme vom Lesen der SNI abhängt, testen Sie, wie sich die eingesetzten Clients verhalten, wenn ECH verfügbar ist und wenn nicht. Halten Sie dann die Kompatibilitätsfolge fest, denn ein Filter, der stillschweigend aufhört zu passen, ist schlimmer als einer, der nie ausgerollt wurde.

Behalten Sie schließlich die Unsicherheit im Protokoll. Eine alte universelle Aussage durch eine neuere zu ersetzen lässt dieselbe Lücke unter einem anderen Protokollnamen zurück, und der nächste Prüfer wird ihr genauso fest glauben.