TLS 1.3 sender stadig servernavnet i klartekst

At opgradere en listener til TLS 1.3 ændrer, hvad en observatør kan læse, men ikke så meget som versionsnummeret antyder. ClientHello rejser stadig, før der er forhandlet kryptering, og i en almindelig forbindelse står det anmodede servernavn der i klartekst. Encrypted Client Hello er mekanismen, der skjuler det, og det er en separat udrulning med egne forudsætninger. Kør disse fire trin, før du skriver en politik, der forudsætter en af de to adfærdsformer.

Hvad handshaket faktisk afslører

TLS 1.3 krypterer serverens certifikat og det meste af det handshake, der følger efter ServerHello. Alt, hvad klienten sender først, ligger uden for den beskyttelse, fordi nøglerne ikke findes endnu. Server name indication er en del af den første sending, og derfor kan en passiv observatør stadig læse den uden at bryde noget.

Den ECH-specifikationen, RFC 9849, ændrer dette ved at kryptere en indre ClientHello for en samarbejdende server. Det ydre handshake består og bærer et offentligt navn, som netværket kan se, så udrulningen har stadig brug for en ydre identitet, der giver mening for mellemled. Det ydre navn er den del, folk overser, når de forventer, at forbindelsen bliver anonym. Det er et dæknavn, ikke et skjult navn, og det skal slås op og autentificeres som ethvert andet.

Intet af dette skjuler leveringsvejen. Kilde- og destinationsadresser, porte, pakkestørrelser og timing forbliver observerbare, og de siger ofte mere om, hvem der taler, end navnet gør. Navneopløsning og relationer på applikationsniveau er endnu et lag, hver med sin egen synlighed.

Læs en ClientHello i stedet for at antage

Versionen i ServerHello fortæller dig ikke, hvad klienten sendte. Se den første sending direkte, fra en position, der svarer til den observatør, du bekymrer dig om.

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

Den første kommando udfører et handshake og viser de forhandlede parametre, herunder protokolversionen og det navn, du bad om. Den anden fanger de første pakker af en rigtig forbindelse, og den tredje udtrækker SNI-feltet fra den optagelse. Er feltet udfyldt, kan den observatør, du efterlignede, læse det.

Optag på klientsiden og på vejen hver for sig, når de to er uenige, fordi en lokal optagelse kan vise et navn, som en middlebox senere omskriver eller dropper. Optag også fra en vært, der ikke selv terminerer TLS, da en terminerende proxy ser klartekst per design og ikke beviser noget om, hvad netværket ser.

Behandl en ECH-udvidelse som en påstand, ikke et bevis

At se en ECH-udvidelse i en ClientHello betyder ikke, at forbindelsen brugte ECH. Klienter sender GREASE ECH, når de ikke har en brugbar konfiguration, netop for at deres handshakes skal se ensartede ud. Udvidelsen er der, det indre hello er en lokkedue, og det faktiske navn er stadig læsbart.

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'

Den første kommando viser, om oprindelsen publicerer en HTTPS-ressourcepost med en ECH-konfigurationsparameter, hvilket er, hvordan klienter lærer nøglen. Den anden leder efter statusinformation for handshaket, selvom en klients succesmeddelelse er det stærkere bevis. Accept er det, der tæller: en server, der ikke har den matchende nøgle, kan ikke dekryptere det indre hello, og forbindelsen falder tilbage.

Tjek også klienten, da browserunderstøttelse og konfiguration varierer efter version og platform. En politik bygget på »moderne browsere bruger ECH« er et gæt om en flåde, ikke en kendsgerning om din flåde. Optæl de versioner, der faktisk forbinder, og test derefter en af hver. Den samme side, der virker fra en aktuel skrivebordsbrowser, skjuler måske intet for en ældre klient på samme netværk.

Skriv observatørens rækkevidde ind i politikken

Angiv, hvor observatøren sidder, og hvad der er synligt på det punkt, før du afgør, hvad en kontrol kan stole på. En browsers forbindelse til et websted, en ydre VPN-transport og en TLS-terminerende proxy afslører hver en anden række fakta, og en regel skrevet til én position overføres sjældent rent til en anden.

Hvis en kontrol afhænger af at læse SNI, så test, hvordan de udrullede klienter opfører sig, når ECH er tilgængeligt, og når det ikke er. Notér derefter kompatibilitetskonsekvensen, fordi et filter, der stille holder op med at matche, er værre end et, der aldrig blev udrullet.

Til sidst, behold usikkerheden i protokollen. At erstatte en gammel universel påstand med en nyere efterlader det samme hul under et andet protokolnavn, og den næste anmelder vil tro på det lige så fast.