HTTPS, DoH, ECH și un VPN ascund lucruri diferite
Fiecare mecanism elimină un observator diferit din traseu și niciunul nu îi elimină pe toți. Comparați ce este protejat înainte de a adăuga un alt tunel.
Adăugarea unui VPN într-un browser care folosește deja HTTPS, DoH și ECH nu suprapune trei protecții într-una singură; schimbă cine este în poziția de a observa ce. Fiecare mecanism elimină o altă parte dintr-un alt schimb și fiecare lasă ceva în urmă. Întrebarea utilă nu este care este cel mai puternic, ci pe care observator încercați să îl eliminați, pentru că răspunsul decide dacă un tunel ajută deloc. O comparație a observatorilor rămași este mai utilă decât o listă de funcții.
Patru mecanisme, patru observatori
Începeți cu cele patru relații și cu partea pe care fiecare este proiectată să o țină afară. Tabelul de mai jos este cel pe care îl folosesc la revizuire, pentru că obligă discuția să numească un observator în loc de o tehnologie.
| Mechanism | Relationship it protects | Observer it does not remove |
|---|---|---|
| HTTPS | The application's TLS connection to its named endpoint | The access network still sees the destination address |
| DoH | The DNS exchange to the selected HTTPS resolver | That resolver sees every query |
| ECH | The sensitive ClientHello fields, where supported and accepted | Destination addresses, and DNS if it is not covered |
| VPN | Covered packets carried to the VPN peer | The VPN operator sees the destinations |
Valoarea tabelului este ceea ce refuză să spună. El nu clasează mecanismele și nu susține că folosirea tuturor patru elimină toți cei patru observatori. O aplicație web în cloud care își termină deja TLS la propria margine este protejată de rețeaua de acces pentru acel schimb, iar niciun tunel nu îmbunătățește acea proprietate anume. Ce poate schimba un tunel este care rețea vede pachetele exterioare și care operator se află acum pe traseu.
Ce ascunde de fapt HTTPS
HTTPS protejează schimbul aplicației dintre client și punctul final pe care îl numește certificatul. Nu ascunde adresa destinației, nu ascunde că a avut loc o conexiune și nu ascunde numele decât dacă ECH este implicat. Validarea certificatului face parte din protecție, nu este o formalitate în jurul ei.
Un VPN nu trebuie să termine acel TLS, iar o ieșire de forwardare nu ar trebui tratată ca punctul final autentificat al aplicației. Dacă un proiect are ieșirea care decriptează, aceea este o altă arhitectură cu o altă declarație de încredere.
Ce mută DoH și ECH și ce lasă în urmă
DoH mută schimbul DNS către un resolver HTTPS, ceea ce înseamnă că acel resolver vede interogările dumneavoastră în locul resolverului rețelei locale. Aceasta este o schimbare reală și una mărginită: resolverul ales devine o parte care poate corela interogările cu adresele la care vă conectați apoi, exact corelația discutată de RFC 8484. Transportul criptat nu face destinatarul inconștient de interogările la care răspunde.
ECH protejează partea sensibilă a ClientHello astfel încât un observator pasiv de pe traseu să nu poată citi numele de server dorit. Depinde de o implementare care îl susține și de acceptarea de către server și rețea, și lasă alte canale în loc: adresele destinației rămân vizibile, iar DNS poate încă dezvălui numele.
Celălalt lucru pe care ECH nu îl face este să se demonstreze. O conexiune care folosește TLS 1.3 nu este dovada că ECH a fost acceptat, iar un browser care oferă ECH unui server care nu îl susține revine discret. Verificați starea reală a conexiunii în loc să o deduceți din versiunea protocolului.
Aceasta este forma generală a întregii comparații: fiecare mecanism este verificat la propriul nivel și niciunul nu este verificat de succesul altuia.
Ce mută un VPN și ce adaugă
Când traficul web intră într-un VPN, rețeaua de acces vede schimbul exterior cu partenerul VPN în locul conexiunilor individuale ale aplicațiilor, iar operatorul VPN ia o poziție pe traseul ulterior. Aceasta este o mutare a graniței de încredere, nu eliminarea uneia. Operatorul vede acum ce destinații atingeți, chiar dacă conținutul rămâne criptat cap la cap. Dacă aceasta este o îmbunătățire depinde în întregime de care dintre cele două părți are mai puțină încredere.
Păstrați HTTPS al aplicației și protecția resolverului dorit în timp ce faceți acest lucru. Un tunel nu este un substitut pentru validarea certificatului, iar oprirea protecțiilor unui resolver pentru că traficul este tunelat elimină un control fără a-l înlocui.
Alegerea pornind de la cerință
Formulați cerința reală, pentru că ea decide proiectarea. Admiterea resurselor private, un punct de ieșire administrat, o amenințare specifică a rețelei de acces și autorizarea dispozitivului sunt patru nevoi diferite cu patru răspunsuri diferite, iar o companie care folosește doar aplicații cloud publice tot trebuie să decidă autorizarea și manipularea datelor. Straturile suplimentare pot fi potrivite fără a fi interschimbabile. O conexiune mai complicată nu este o măsurătoare a anonimatului și nu este singură un argument de securitate.
Specificația ECH, RFC 9849, merită citită pentru ce acoperă și ce nu acoperă mecanismul, și este onestă cu privire la canalele pe care le lasă în pace. Comparați mecanismele după observatorul pe care fiecare îl elimină, notați acel observator și apoi decideți dacă stratul suplimentar îl abordează. Dacă răspunsul este că observatorul era deja în afara modelului dumneavoastră de amenințare, tunelul este cost fără beneficiu.