TLS 1.3 še vedno pošilja ime strežnika v odprtem besedilu

Nadgradnja listenerja na TLS 1.3 spremeni, kaj lahko opazovalec prebere, a ne toliko, kot nakazuje številka različice. ClientHello še vedno potuje, preden se izpogaja kakršno koli šifriranje, in v običajni povezavi je zahtevano ime strežnika tam v odprtem besedilu. Encrypted Client Hello je mehanizem, ki ga skrije, in je ločena namestitev z lastnimi predpogoji. Izvedite te štiri korake, preden napišete pravilnik, ki predpostavlja eno od obeh vedenj.

Kaj rokovanje dejansko razkrije

TLS 1.3 šifrira strežnikov certifikat in večino rokovanja, ki sledi ServerHello. Vse, kar odjemalec pošlje najprej, ostane zunaj te zaščite, ker ključi še ne obstajajo. Označba imena strežnika je del tega prvega poleta, zato jo pasivni opazovalec še vedno lahko prebere, ne da bi karkoli zlomil.

Specifikacija ECH, RFC 9849, to spremeni s šifriranjem notranjega ClientHello za sodelujoči strežnik. Zunanje rokovanje ostane in nosi javno ime, ki ga omrežje vidi, zato namestitev še vedno potrebuje zunanjo identiteto, ki ima smisel za posrednike. To zunanje ime je del, ki ga ljudje zgrešijo, ko pričakujejo, da bo povezava postala anonimna. To je pokrivno ime, ne skrito, in mora se razrešiti in overiti kot vsako drugo.

Nič od tega ne skrije dostavne poti. Izvorni in ciljni naslovi, vrata, velikosti paketov in čas ostanejo opazni in pogosto povedo več o tem, kdo govori, kot ime. Razreševanje imen in odnosi na ravni aplikacije so še ena plast, vsaka z lastno vidnostjo.

Preberite ClientHello, namesto da predvidevate

Različica v ServerHello vam ne pove, kaj je odjemalec poslal. Poglejte prvi polet neposredno, s položaja, ki predstavlja opazovalca, ki vas zanima.

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

Prvi ukaz izvede rokovanje in pokaže izpogajane parametre, vključno z različico protokola in imenom, ki ste ga zahtevali. Drugi zajame prve pakete resnične povezave, tretji pa izlušči polje SNI iz tega zajema. Če je polje izpolnjeno, ga opazovalec, ki ste ga posnemali, lahko prebere.

Zajemajte ločeno na strani odjemalca in na poti, ko se ta dva ne ujemata, ker lahko lokalni zajem pokaže ime, ki ga middlebox pozneje prepiše ali zavrže. Zajemajte tudi z gostitelja, ki sam ne zaključi TLS, saj zaključujoči proxy vidi odprto besedilo po zasnovi in ne dokazuje ničesar o tem, kaj vidi omrežje.

Razširitev ECH obravnavajte kot trditev, ne kot dokaz

Če v ClientHello vidite razširitev ECH, to ne pomeni, da je povezava uporabila ECH. Odjemalci pošljejo GREASE ECH, ko nimajo uporabne konfiguracije, prav zato, da so njihova rokovanja videti enotna. Razširitev je prisotna, notranji hello je vaba, dejansko ime pa je še vedno berljivo.

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'

Prvi ukaz pokaže, ali izvor objavlja zapis vira HTTPS s parametrom konfiguracije ECH, kar je način, kako se odjemalci naučijo ključa. Drugi išče informacije o stanju rokovanja, čeprav je sporočilo o uspehu odjemalca močnejši dokaz. Sprejem je tisto, kar šteje: strežnik, ki nima ustreznega ključa, ne more dešifrirati notranjega hello, in povezava se umakne.

Preverite tudi odjemalca, saj se podpora brskalnikov in konfiguracija razlikujeta glede na različico in platformo. Pravilnik, zgrajen na „sodobni brskalniki uporabljajo ECH“, je ugibanje o floti, ne dejstvo o vaši floti. Popišite različice, ki se dejansko povezujejo, in nato preizkusite po eno od vsake. Ista stran, ki deluje iz aktualnega namiznega brskalnika, morda pred starejšim odjemalcem v istem omrežju ne skrije ničesar.

Zapišite obseg opazovalca v pravilnik

Navedite, kje sedi opazovalec in kaj je na tej točki vidno, preden se odločite, na kaj se lahko opre nadzor. Povezava brskalnika do spletnega mesta, zunanji transport VPN in proxy, ki zaključi TLS, vsak razkrijejo drugačen nabor dejstev, in pravilo, napisano za en položaj, se le redko prenese čisto na drugega.

Če je nadzor odvisen od branja SNI, preizkusite, kako se nameščeni odjemalci obnašajo, ko je ECH na voljo in ko ni. Nato zabeležite posledico za združljivost, ker je filter, ki tiho preneha ujemati, slabši od tistega, ki ni bil nikoli nameščen.

Nazadnje, negotovost ohranite v zapisu. Zamenjava stare univerzalne trditve z novejšo pusti isto vrzel pod drugim imenom protokola, in naslednji pregledovalec ji bo verjel prav tako trdno.