Iba-iba ang itinatago ng HTTPS, DoH, ECH at VPN
Bawat mekanismo ay nag-aalis ng ibang tagamasid sa landas at wala sa kanila ang nag-aalis sa lahat. Ihambing kung ano ang protektado bago magdagdag ng isa pang tunnel.
Ang pagdaragdag ng VPN sa isang browser na gumagamit na ng HTTPS, DoH at ECH ay hindi nagsasama ng tatlong proteksyon sa isa; binabago nito kung sino ang nasa posisyon para magmasid ng ano. Bawat mekanismo ay nag-aalis ng ibang panig mula sa ibang palitan, at bawat isa ay may naiiwan. Ang kapaki-pakinabang na tanong ay hindi kung alin ang pinakamalakas kundi kung aling tagamasid ang sinusubukan mong alisin, dahil ang sagot ang nagpapasya kung ang tunnel ay nakakatulong talaga. Ang paghahambing ng natitirang mga tagamasid ay mas kapaki-pakinabang kaysa listahan ng feature.
Apat na mekanismo, apat na tagamasid
Magsimula sa apat na ugnayan at sa panig na dinisenyo upang ilabas ng bawat isa. Ang talahanayan sa ibaba ang ginagamit ko sa pagsusuri, dahil pinipilit nitong pangalanan ng usapan ang isang tagamasid sa halip na isang teknolohiya.
| 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 |
Ang halaga ng talahanayan ay ang tinatanggihan nitong sabihin. Hindi nito niraranggo ang mga mekanismo, at hindi nito sinasabing ang paggamit ng apat ay nag-aalis sa apat na tagamasid. Ang isang cloud web application na nagtatapos na ng TLS sa sariling gilid nito ay protektado mula sa access network para sa palitang iyon, at walang tunnel ang nagpapabuti sa partikular na katangiang iyon. Ang mababago ng tunnel ay kung aling network ang nakakakita ng panlabas na packet at kung aling operator ang nasa landas ngayon.
Ano ang talagang itinatago ng HTTPS
Pinoprotektahan ng HTTPS ang palitan ng aplikasyon sa pagitan ng client at ng endpoint na pinangalanan ng certificate. Hindi nito itinatago ang destination address, hindi nito itinatago na may nangyaring koneksyon, at hindi nito itinatago ang pangalan maliban kung may ECH. Ang validation ng certificate ay bahagi ng proteksyon, hindi isang pormalidad sa paligid nito.
Hindi kailangang tapusin ng VPN ang TLS na iyon, at ang isang forwarding exit ay hindi dapat ituring na authenticated endpoint ng aplikasyon. Kung ang isang disenyo ay hinahayaang mag-decrypt ang exit, ibang arkitektura iyon na may ibang pahayag ng tiwala.
Ano ang inililipat ng DoH at ECH, at ano ang naiiwan
Inililipat ng DoH ang palitan ng DNS sa isang HTTPS resolver, ibig sabihin nakikita ng resolver na iyon ang iyong mga query sa halip na ang resolver ng lokal na network. Iyon ay tunay at may hangganang pagbabago: ang napiling resolver ay nagiging panig na makakapag-ugnay ng mga query sa mga address na kinokonektahan mo pagkatapos, na siya mismong ugnayang tinatalakay ng dokumentong RFC 8484. Hindi ginagawang walang kamalayan ng encrypted transport ang tatanggap sa mga query na sinasagot nito.
Pinoprotektahan ng ECH ang sensitibong bahagi ng ClientHello upang ang passive observer sa landas ay hindi mabasa ang nilalayong pangalan ng server. Depende ito sa isang deployment na sumusuporta at sa pagtanggap ng server at network, at iniiwan ang ibang channel: nananatiling nakikita ang destination address, at maaari pa ring ilantad ng DNS ang pangalan.
Ang isa pang hindi ginagawa ng ECH ay patunayan ang sarili nito. Ang koneksyong gumagamit ng TLS 1.3 ay hindi ebidensya na tinanggap ang ECH, at ang browser na nag-aalok ng ECH sa server na hindi ito sinusuportahan ay tahimik na bumabalik. Suriin ang aktwal na estado ng koneksyon sa halip na hulaan ito mula sa bersyon ng protocol.
Iyon ang pangkalahatang anyo ng buong paghahambing: bawat mekanismo ay binibigyang-validate sa sariling layer, at wala sa kanila ang nabe-validate ng tagumpay ng iba.
Ano ang inililipat ng VPN, at ano ang idinadagdag nito
Kapag ang web traffic ay pumasok sa VPN, nakikita ng access network ang panlabas na palitan kasama ang VPN peer sa halip na ang mga indibidwal na koneksyon ng aplikasyon, at pumaposisyon ang VPN operator sa papasulong na landas. Iyon ay paglipat ng trust boundary, hindi pag-aalis nito. Nakikita na ngayon ng operator kung aling mga destinasyon ang naaabot mo, kahit nananatiling naka-encrypt end to end ang nilalaman. Kung ito ay pagbuti ay ganap na nakadepende sa kung alin sa dalawang panig na iyon ang mas kaunti mong pinagkakatiwalaan.
Panatilihin ang HTTPS ng aplikasyon at ang nilalayong proteksyon ng resolver habang ginagawa ito. Ang tunnel ay hindi kapalit ng certificate validation, at ang pagpatay sa mga proteksyon ng resolver dahil naka-tunnel ang traffic ay nag-aalis ng kontrol nang walang kapalit.
Pagpili mula sa pangangailangan
Sabihin ang aktwal na pangangailangan, dahil iyon ang nagpapasya sa disenyo. Ang pagtanggap sa pribadong resource, pinamamahalaang egress point, partikular na banta sa access network at awtorisasyon ng device ay apat na magkaibang pangangailangan na may apat na magkaibang sagot, at ang kumpanyang gumagamit lamang ng pampublikong cloud application ay kailangan pa ring magpasya sa awtorisasyon at paghawak ng data. Maaaring angkop ang karagdagang layer nang hindi nagpapalitan. Ang mas kumplikadong koneksyon ay hindi sukatan ng anonymity at hindi ito argumento ng seguridad sa sarili nito.
Ang ECH specification, RFC 9849, ay sulit basahin para sa saklaw at hindi saklaw ng mekanismo, at tapat ito tungkol sa mga channel na hinahayaan lang. Ihambing ang mga mekanismo ayon sa tagamasid na inaalis ng bawat isa, isulat ang tagamasid na iyon, at pagkatapos ay magpasya kung tinutugunan ito ng karagdagang layer. Kung ang sagot ay nasa labas na ng iyong threat model ang tagamasid, ang tunnel ay gastos na walang pakinabang.