TLS 1.3 sender fortsatt servernavnet i klartekst

Å oppgradere en listener til TLS 1.3 endrer hva en observatør kan lese, men ikke så mye som versjonsnummeret antyder. ClientHello reiser fortsatt før noen kryptering er forhandlet, og i en vanlig forbindelse står det forespurte servernavnet der i klartekst. Encrypted Client Hello er mekanismen som skjuler det, og det er en egen utrulling med egne forutsetninger. Kjør disse fire trinnene før du skriver en policy som forutsetter en av de to atferdene.

Hva håndtrykket faktisk avslører

TLS 1.3 krypterer serverens sertifikat og det meste av håndtrykket som følger etter ServerHello. Alt klienten sender først, ligger utenfor den beskyttelsen, fordi nøklene ikke finnes ennå. Server name indication er en del av den første sendingen, og derfor kan en passiv observatør fortsatt lese den uten å bryte noe.

Den ECH-spesifikasjonen, RFC 9849, endrer dette ved å kryptere en indre ClientHello for en samarbeidende server. Det ytre håndtrykket består og bærer et offentlig navn som nettet kan se, så utrullingen trenger fortsatt en ytre identitet som gir mening for mellomledd. Det ytre navnet er den delen folk overser når de forventer at forbindelsen skal bli anonym. Det er et dekknavn, ikke et skjult navn, og det må slås opp og autentiseres som alle andre.

Ingenting av dette skjuler leveringsveien. Kilde- og måladresser, porter, pakkestørrelser og tidspunkt forblir observerbare, og de sier ofte mer om hvem som snakker enn navnet gjør. Navneoppslag og relasjoner på applikasjonsnivå er enda et lag, hvert med sin egen synlighet.

Les en ClientHello i stedet for å anta

Versjonen i ServerHello forteller deg ikke hva klienten sendte. Se på den første sendingen direkte, fra en posisjon som tilsvarer observatøren du bryr deg 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 kommandoen utfører et håndtrykk og viser de forhandlede parameterne, inkludert protokollversjonen og navnet du ba om. Den andre fanger de første pakkene i en ekte forbindelse, og den tredje trekker ut SNI-feltet fra den fangsten. Hvis feltet er fylt ut, kan observatøren du etterlignet lese det.

Fang på klientsiden og på veien hver for seg når de to er uenige, fordi en lokal fangst kan vise et navn som en mellomvare senere skriver om eller dropper. Fang også fra en vert som ikke selv terminerer TLS, siden en terminerende proxy ser klartekst ved design og ikke beviser noe om hva nettet ser.

Behandle en ECH-utvidelse som en påstand, ikke et bevis

Å se en ECH-utvidelse i en ClientHello betyr ikke at forbindelsen brukte ECH. Klienter sender GREASE ECH når de ikke har en brukbar konfigurasjon, nettopp for at håndtrykkene deres skal se ensartede ut. Utvidelsen er der, den indre hello er en lokkefugl, og det faktiske navnet er fortsatt lesbart.

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 kommandoen viser om opprinnelsen publiserer en HTTPS-ressurspost med en ECH-konfigurasjonsparameter, som er hvordan klienter lærer nøkkelen. Den andre leter etter statusinformasjon for håndtrykket, selv om en klients suksessmelding er det sterkere beviset. Aksept er det som teller: en server som ikke har den matchende nøkkelen, kan ikke dekryptere den indre hello, og forbindelsen faller tilbake.

Sjekk klienten også, siden nettleserstøtte og konfigurasjon varierer med versjon og plattform. En policy bygget på «moderne nettlesere bruker ECH» er en gjetning om en flåte, ikke et faktum om din flåte. Kartlegg versjonene som faktisk kobler til, og test deretter én av hver. Den samme siden som fungerer fra en aktuell skrivebordsnettleser, skjuler kanskje ingenting for en eldre klient på samme nett.

Skriv observatørens omfang inn i policyen

Si hvor observatøren sitter og hva som er synlig på det punktet før du avgjør hva en kontroll kan basere seg på. En nettlesers forbindelse til et nettsted, en ytre VPN-transport og en TLS-terminerende proxy avslører hver sin mengde fakta, og en regel skrevet for én posisjon overføres sjelden rent til en annen.

Hvis en kontroll avhenger av å lese SNI, test hvordan de utrullede klientene oppfører seg når ECH er tilgjengelig og når det ikke er. Noter så kompatibilitetskonsekvensen, fordi et filter som stille slutter å matche, er verre enn et som aldri ble rullet ut.

Til slutt, behold usikkerheten i protokollen. Å erstatte en gammel universell påstand med en nyere etterlater det samme hullet under et annet protokollnavn, og neste gjennomgang vil tro på det like fast.