TLS 1.3 sender framleis servernamnet i klartekst

Å oppgradere ein lyttar til TLS 1.3 endrar kva ein observatør kan lese, men ikkje så mykje som versjonsnummeret antyder. ClientHello reiser framleis før noka kryptering er forhandla, og i ei vanleg tilkopling står det etterlyste servernamnet der i klartekst. Encrypted Client Hello er mekanismen som skjuler det, og det er ei eiga utrulling med eigne føresetnader. Køyr desse fire trinna før du skriv ein policy som føreset ei av dei to åtferdene.

Kva handtrykket faktisk avdekkjer

TLS 1.3 krypterer sertifikatet til serveren og det meste av handtrykket som følgjer etter ServerHello. Alt klienten sender først, ligg utanfor den vernet, fordi nøklane ikkje finst enno. Server name indication er ein del av den første sendinga, og difor kan ein passiv observatør framleis lese han utan å bryte noko.

Den ECH-spesifikasjonen, RFC 9849, endrar dette ved å kryptere ein indre ClientHello for ein samarbeidande server. Det ytre handtrykket står att og ber eit offentleg namn som nettet kan sjå, så utrullinga treng framleis ein ytre identitet som gjev mening for mellomledd. Det ytre namnet er den delen folk overser når dei ventar at tilkoplinga skal bli anonym. Det er eit dekknamn, ikkje eit skjult namn, og det må slåast opp og autentiserast som alle andre.

Ingenting av dette skjuler leveringsvegen. Kjelde- og målresser, portar, pakkestorleikar og tidspunkt blir verande observerbare, og dei seier ofte meir om kven som snakkar enn namnet gjer. Namneoppslag og relasjonar på applikasjonsnivå er endå eit lag, kvart med si eiga synlegheit.

Les ein ClientHello i staden for å anta

Versjonen i ServerHello fortel deg ikkje kva klienten sende. Sjå på den første sendinga direkte, frå ein posisjon som svarar til 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 eit handtrykk og viser dei forhandla parametrane, inkludert protokollversjonen og namnet du bad om. Den andre fangar dei første pakkane i ei ekte tilkopling, og den tredje trekkjer ut SNI-feltet frå den fanginga. Er feltet fylt ut, kan observatøren du etterlikna lese det.

Fang på klientsida og på vegen kvar for seg når dei to er usamde, fordi ei lokal fanging kan vise eit namn som ein mellomvare seinare skriv om eller droppar. Fang òg frå ein vert som ikkje sjølv terminerer TLS, sidan ein terminerande proxy ser klartekst ved design og ikkje beviser noko om kva nettet ser.

Behandle ei ECH-utviding som ein påstand, ikkje eit prov

Å sjå ei ECH-utviding i ein ClientHello betyr ikkje at tilkoplinga brukte ECH. Klientar sender GREASE ECH når dei ikkje har ein brukbar konfigurasjon, nettopp for at handtrykka deira skal sjå einsarta ut. Utvidinga er der, den indre hello er ein lokkefugl, og det faktiske namnet er framleis 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 opphavet publiserer ein HTTPS-ressurspost med ein ECH-konfigurasjonsparameter, som er korleis klientar lærer nøkkelen. Den andre leitar etter statusinformasjon for handtrykket, sjølv om suksessmeldinga til ein klient er det sterkare provet. Aksept er det som tel: ein server som ikkje har den matchende nøkkelen, kan ikkje dekryptere den indre hello, og tilkoplinga fell tilbake.

Sjekk klienten òg, sidan nettlesarstøtte og konfigurasjon varierer med versjon og plattform. Ein policy bygd på «moderne nettlesarar brukar ECH» er ei gjetning om ein flåte, ikkje eit faktum om flåten din. Kartlegg versjonane som faktisk koplar til, og test deretter éin av kvar. Den same sida som fungerer frå ein aktuell skrivebordsnettlesar, skjuler kanskje ingenting for ein eldre klient på same nett.

Skriv omfanget til observatøren inn i policyen

Sei kvar observatøren sit og kva som er synleg på det punktet før du avgjer kva ein kontroll kan byggje på. Tilkoplinga til ein nettlesar mot eit nettstad, ein ytre VPN-transport og ein TLS-terminerande proxy avdekkjer kvar si mengd fakta, og ein regel skriven for éin posisjon blir sjeldan overført reint til ein annan.

Viss ein kontroll er avhengig av å lese SNI, test korleis dei utrulla klientane oppfører seg når ECH er tilgjengeleg og når det ikkje er. Noter så kompatibilitetskonsekvensen, fordi eit filter som stille sluttar å matche, er verre enn eit som aldri vart rulla ut.

Til slutt, hald usikkerheita i protokollen. Å erstatte ein gammal universell påstand med ein nyare lèt den same luka stå att under eit anna protokollnamn, og neste gjennomgang vil tru på det like fast.