TLS 1.3 saadab serveri nime endiselt lihttekstina

Kuulaja uuendamine TLS 1.3-le muudab seda, mida vaatleja saab lugeda, kuid mitte nii palju, kui versiooninumber vihjab. ClientHello liigub endiselt enne, kui mis tahes krüpteerimine kokku lepitakse, ja tavalisse ühendusse jääb soovitud serveri nimi sinna lihttekstina. Encrypted Client Hello on mehhanism, mis selle peidab, ja see on eraldi juurutus oma eeldustega. Tehke need neli sammu enne, kui kirjutate poliitika, mis eeldab kumbagi käitumist.

Mida käepigistus tegelikult paljastab

TLS 1.3 krüpteerib serveri sertifikaadi ja suurema osa ServerHellole järgnevast käepigistusest. Kõik, mis klient esimesena saadab, jääb sellest kaitsest välja, sest võtmeid veel ei ole. Serveri nime osutus on osa sellest esimesest lennust, mistõttu passiivne vaatleja saab seda endiselt lugeda, ilma et midagi katki teeks.

Spetsifikatsioon ECH, RFC 9849, muudab seda, krüpteerides sisemise ClientHello koostöövalmis serveri jaoks. Välimine käepigistus jääb alles ja kannab avalikku nime, mida võrk näeb, seega vajab juurutus endiselt välist identiteeti, mis on vahendajate jaoks mõistlik. See välimine nimi on osa, mille inimesed jätavad märkamata, kui nad loodavad, et ühendus muutub anonüümseks. See on kattenimi, mitte peidetud nimi, ja see peab lahenema ja autentima nagu iga teine.

Miski sellest ei peida kohaletoimetamise teed. Allika- ja sihtaddressid, pordid, paketi suurused ja ajastus jäävad vaadeldavaks ning need ütlevad sageli rohkem selle kohta, kes räägib, kui nimi. Nime lahendamine ja rakendustasandi suhted on veel üks kiht, igaüks oma nähtavusega.

Lugege ClientHello'i, selle asemel et oletada

ServerHello versioon ei ütle teile, mida klient saatis. Vaadake esimest lendu otse, positsioonilt, mis esindab vaatlejat, kes teid huvitab.

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

Esimene käsk sooritab käepigistuse ja näitab kokku lepitud parameetreid, sealhulgas protokolli versiooni ja nime, mida küsisite. Teine jäädvustab tõelise ühenduse esimesed paketid ja kolmas eraldab sellest jäädvustusest SNI välja. Kui väli on täidetud, saab jäljendatud vaatleja seda lugeda.

Jäädvustage eraldi kliendi poolel ja teel, kui need kaks ei kattu, sest kohalik jäädvustus võib näidata nime, mille vahendaja hiljem ümber kirjutab või ära jätab. Jäädvustage ka hostilt, mis ise TLS-i ei lõpeta, kuna lõpetav puhverserver näeb lihtteksti oma olemuselt ega tõesta midagi selle kohta, mida võrk näeb.

Käsitlege ECH laiendit väitena, mitte tõestusena

ECH laiendi nägemine ClientHello's ei tähenda, et ühendus ECH-d kasutas. Kliendid saadavad GREASE ECH-d, kui neil pole kasutatavat konfiguratsiooni, just selleks, et nende käepigistused näeksid ühtsed. Laiend on olemas, sisemine hello on peibutis ja tegelik nimi on endiselt loetav.

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'

Esimene käsk näitab, kas päritolu avaldab HTTPS-i ressursikirje ECH konfiguratsiooniparameetriga, ja nii õpivad kliendid võtit. Teine otsib käepigistuse olekuteavet, kuigi kliendi õnnestumisteade on tugevam tõestus. Vastuvõtt on see, mis loeb: server, kellel pole sobivat võtit, ei saa sisemist hellot dekrüpteerida ja ühendus taandub.

Kontrollige ka klienti, sest brauserite tugi ja konfiguratsioon erinevad versiooni ja platvormi järgi. Poliitika, mis põhineb väitel „kaasaegsed brauserid kasutavad ECH-d“, on oletus laevastiku kohta, mitte fakt teie laevastiku kohta. Kaardistage versioonid, mis tegelikult ühenduvad, ja seejärel testige igast ühte. Sama leht, mis töötab praegusest töölaua brauserist, ei pruugi vanemalt kliendilt samas võrgus midagi peita.

Kirjutage vaatleja ulatus poliitikasse

Märkige, kus vaatleja asub ja mis on selles punktis nähtav, enne kui otsustate, millele kontroll toetuda saab. Brauseri ühendus veebisaidiga, välimine VPN-transport ja TLS-i lõpetav puhverserver paljastavad igaüks erineva hulga fakte ja ühe positsiooni jaoks kirjutatud reegel kandub harva puhtalt teisele üle.

Kui kontroll sõltub SNI lugemisest, testige, kuidas juurutatud kliendid käituvad, kui ECH on saadaval ja kui see pole. Seejärel kirjutage üles ühilduvuse tagajärg, sest filter, mis vaikselt lakkab sobimast, on halvem kui see, mida kunagi ei juurutatud.

Lõpuks hoidke ebakindlus protokollis. Vana üldise väite asendamine uuemaga jätab sama lünga teise protokolli nime all ja järgmine ülevaataja usub seda sama kindlalt.