TLS 1.3 trimite în continuare numele serverului în text clar
TLS 1.3 criptează handshake-ul, dar nu SNI. Citiți ClientHello, verificați o acceptare ECH reală și înregistrați ce poate vedea încă un observator.
Trecerea unui listener la TLS 1.3 schimbă ce poate citi un observator, dar nu atât de mult pe cât sugerează numărul versiunii. ClientHello călătorește în continuare înainte de a se negocia orice criptare, iar într-o conexiune obișnuită numele de server solicitat stă acolo în text clar. Encrypted Client Hello este mecanismul care îl ascunde, și este o implementare separată cu propriile ei condiții prealabile. Rulați acești patru pași înainte de a scrie o politică ce presupune unul dintre cele două comportamente.
Ce expune de fapt handshake-ul
TLS 1.3 criptează certificatul serverului și cea mai mare parte a handshake-ului care urmează după ServerHello. Tot ce trimite clientul primul rămâne în afara acelei protecții, pentru că cheile nu există încă. Indicația numelui de server face parte din acel prim zbor, motiv pentru care un observator pasiv îl poate citi în continuare fără să spargă nimic.
Specificația ECH, RFC 9849, schimbă acest lucru criptând un ClientHello interior pentru un server care cooperează. Handshake-ul exterior rămâne și poartă un nume public pe care rețeaua îl poate vedea, așa că implementarea are în continuare nevoie de o identitate exterioară care să aibă sens pentru intermediari. Acel nume exterior este partea pe care oamenii o ratează când se așteaptă ca conexiunea să devină anonimă. Este un nume de acoperire, nu unul ascuns, și trebuie să se rezolve și să se autentifice ca oricare altul.
Nimic din toate acestea nu ascunde calea de livrare. Adresele sursă și destinație, porturile, dimensiunile pachetelor și temporizarea rămân observabile, iar acestea spun adesea mai mult despre cine vorbește decât numele. Rezolvarea numelor și relațiile la nivel de aplicație sunt încă un alt strat, fiecare cu propria vizibilitate.
Citiți un ClientHello în loc să presupuneți
Versiunea din ServerHello nu vă spune ce a trimis clientul. Uitați-vă direct la primul zbor, dintr-o poziție care reprezintă observatorul care vă interesează.
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
Prima comandă efectuează un handshake și arată parametrii negociați, inclusiv versiunea protocolului și numele pe care l-ați solicitat. A doua captează primele pachete ale unei conexiuni reale, iar a treia extrage câmpul SNI din acea captură. Dacă câmpul este completat, observatorul pe care l-ați emulat îl poate citi.
Capturați separat pe partea clientului și pe cale când cele două nu sunt de acord, pentru că o captură locală poate arăta un nume pe care un middlebox îl rescrie sau îl aruncă mai târziu. Capturați și de pe un host care nu termină el însuși TLS, deoarece un proxy care termină vede text clar prin proiectare și nu demonstrează nimic despre ce vede rețeaua.
Tratați o extensie ECH ca pe o afirmație, nu ca pe o dovadă
A vedea o extensie ECH într-un ClientHello nu înseamnă că conexiunea a folosit ECH. Clienții trimit GREASE ECH când nu au o configurație utilizabilă, exact pentru ca handshake-urile lor să arate uniform. Extensia este prezentă, hello-ul interior este o momeală, iar numele real este încă lizibil.
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'
Prima comandă arată dacă originea publică o înregistrare de resursă HTTPS cu un parametru de configurare ECH, ceea ce este modul în care clienții învață cheia. A doua caută informații despre starea handshake-ului, deși mesajul de succes al unui client este dovada mai puternică. Acceptarea este ce contează: un server care nu deține cheia potrivită nu poate decripta hello-ul interior, iar conexiunea revine.
Verificați și clientul, deoarece suportul browserelor și configurația diferă în funcție de versiune și platformă. O politică bazată pe „browserele moderne folosesc ECH” este o presupunere despre o flotă, nu un fapt despre flota dumneavoastră. Inventariați versiunile care se conectează efectiv, apoi testați câte una din fiecare. Aceeași pagină care funcționează dintr-un browser de desktop actual poate să nu ascundă nimic pentru un client mai vechi din aceeași rețea.
Scrieți sfera observatorului în politică
Precizați unde se află observatorul și ce este vizibil în acel punct înainte de a decide pe ce se poate baza un control. Conexiunea unui browser la un site, un transport VPN exterior și un proxy care termină TLS expun fiecare un alt set de fapte, iar o regulă scrisă pentru o poziție se transferă rar curat la alta.
Dacă un control depinde de citirea SNI, testați cum se comportă clienții implementați când ECH este disponibil și când nu este. Apoi înregistrați consecința de compatibilitate, pentru că un filtru care încetează silențios să se potrivească este mai rău decât unul care nu a fost niciodată implementat.
În final, păstrați incertitudinea în registru. Înlocuirea unei vechi afirmații universale cu una mai nouă lasă aceeași lacună sub un alt nume de protocol, iar următorul recenzent va crede în ea la fel de ferm.