Přechod listeneru na TLS 1.3 mění to, co může pozorovatel přečíst, ale ne tolik, kolik naznačuje číslo verze. ClientHello stále putuje dřív, než je vyjednáno jakékoli šifrování, a v běžném spojení tam požadované jméno serveru leží v otevřeném textu. Encrypted Client Hello je mechanismus, který jej skrývá, a je to samostatné nasazení s vlastními předpoklady. Proveďte tyto čtyři kroky, než napíšete zásadu, která předpokládá jedno z obou chování.

Co handshake skutečně odhaluje

TLS 1.3 šifruje certifikát serveru a většinu handshake, který následuje po ServerHello. Vše, co klient odešle jako první, zůstává mimo tuto ochranu, protože klíče ještě neexistují. Označení jména serveru je součástí toho prvního letu, a proto jej pasivní pozorovatel může stále číst, aniž by cokoli rozbil.

Specifikace ECH, RFC 9849, to mění tím, že šifruje vnitřní ClientHello pro spolupracující server. Vnější handshake zůstává a nese veřejné jméno, které síť vidí, takže nasazení stále potřebuje vnější identitu, která dává smysl pro prostředníky. To vnější jméno je část, kterou lidé přehlédnou, když očekávají, že spojení bude anonymní. Je to krycí jméno, ne skryté, a musí se překládat a ověřovat jako každé jiné.

Nic z toho neskrývá cestu doručení. Zdrojové a cílové adresy, porty, velikosti paketů a časování zůstávají pozorovatelné a často řeknou víc o tom, kdo mluví, než jméno. Překlad jmen a vztahy na úrovni aplikace jsou další vrstvou, každá s vlastní viditelností.

Čtěte ClientHello místo předpokladů

Verze v ServerHello vám neřekne, co klient odeslal. Podívejte se na první let přímo, z pozice, která představuje pozorovatele, na kterém vám záleží.

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

První příkaz provede handshake a ukáže vyjednané parametry, včetně verze protokolu a jména, které jste požadovali. Druhý zachytí první pakety skutečného spojení a třetí vytáhne pole SNI z tohoto zachycení. Pokud je pole vyplněné, pozorovatel, kterého jste napodobili, jej může číst.

Zachytávejte odděleně na straně klienta a na cestě, když se oba neshodují, protože místní zachycení může ukázat jméno, které middlebox později přepíše nebo zahodí. Zachytávejte také z hostitele, který sám neukončuje TLS, protože ukončující proxy vidí otevřený text ze zásady a nic nedokazuje o tom, co vidí síť.

Berte rozšíření ECH jako tvrzení, ne jako důkaz

Vidět rozšíření ECH v ClientHello neznamená, že spojení ECH použilo. Klienti posílají GREASE ECH, když nemají použitelnou konfiguraci, právě proto, aby jejich handshake vypadal stejně. Rozšíření je přítomné, vnitřní hello je návnada a skutečné jméno je stále čitelné.

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'

První příkaz ukáže, zda zdroj publikuje záznam prostředku HTTPS s parametrem konfigurace ECH, což je způsob, jakým se klienti učí klíč. Druhý hledá informace o stavu handshake, i když zpráva o úspěchu klienta je silnějším důkazem. Přijetí je to, na čem záleží: server, který nemá odpovídající klíč, nemůže vnitřní hello dešifrovat a spojení se vrací zpět.

Zkontrolujte také klienta, protože podpora prohlížečů a konfigurace se liší podle verze a platformy. Zásada postavená na „moderní prohlížeče používají ECH“ je dohad o flotile, ne fakt o vaší flotile. Zmapujte verze, které se skutečně připojují, a pak každou z nich otestujte. Stejná stránka, která funguje z aktuálního stolního prohlížeče, nemusí před starším klientem ve stejné síti skrýt nic.

Zapište rozsah pozorovatele do zásady

Uveďte, kde pozorovatel sedí a co je v tomto bodě viditelné, než rozhodnete, na co se může kontrola spoléhat. Připojení prohlížeče k webu, vnější transport VPN a proxy ukončující TLS odhalují každý jinou sadu faktů a pravidlo napsané pro jednu pozici se jen zřídka přenese čistě na jinou.

Pokud kontrola závisí na čtení SNI, otestujte, jak se nasazení klienti chovají, když je ECH dostupné a když není. Poté zaznamenejte důsledek pro kompatibilitu, protože filtr, který tiše přestane odpovídat, je horší než ten, který nebyl nikdy nasazen.

Nakonec ponechte nejistotu v záznamu. Nahrazení starého univerzálního tvrzení novějším zanechá stejnou mezeru pod jiným názvem protokolu a další recenzent mu uvěří stejně pevně.

Související články