HTTPS, DoH, ECH ja VPN peittävät eri asioita
Jokainen mekanismi poistaa polulta eri tarkkailijan, eikä mikään poista kaikkia. Vertaa, mitä on suojattu, ennen kuin lisäät uuden tunnelin.
VPN:n lisääminen selaimeen, joka käyttää jo HTTPS:ää, DoH:ta ja ECH:tä, ei pinonna kolmea suojausta yhdeksi; se muuttaa sitä, kuka on asemassa havainnoida mitä. Jokainen mekanismi poistaa eri osapuolen eri vaihdosta, ja jokainen jättää jotain jälkeensä. Hyödyllinen kysymys ei ole, mikä on vahvin, vaan minkä tarkkailijan yrität poistaa, koska vastaus ratkaisee, auttaako tunneli ylipäätään. Jäljelle jäävien tarkkailijoiden vertailu on hyödyllisempää kuin ominaisuusluettelo.
Neljä mekanismia, neljä tarkkailijaa
Aloita neljästä suhteesta ja osapuolesta, jonka kukin on suunniteltu pitämään ulkona. Alla oleva taulukko on se, jota käytän katselmoinnissa, koska se pakottaa keskustelun nimeämään tarkkailijan teknologian sijaan.
| Mekanismi | Suhde, jota se suojaa | Tarkkailija, jota se ei poista |
|---|---|---|
| HTTPS | Sovelluksen TLS-yhteys sen nimettyyn päätepisteeseen | Käyttöverkko näkee yhä kohdeosoitteen |
| DoH | DNS-vaihto valitun HTTPS-resolverin kanssa | Tämä resolver näkee jokaisen kyselyn |
| ECH | ClientHellon arkaluontoiset kentät, kun tuetaan ja hyväksytään | Kohdeosoitteet ja DNS, jos se ei ole katettu |
| VPN | Katetut paketit, jotka viedään VPN-vertaiskumppanille | VPN-operaattori näkee kohteet |
Taulukon arvo on siinä, mitä se kieltäytyy sanomasta. Se ei aseta mekanismeja järjestykseen eikä väitä, että kaikkien neljän käyttäminen poistaa kaikki neljä tarkkailijaa. Pilvipalvelun verkkosovellus, joka jo päättää TLS:n omalla reunallaan, on suojattu käyttöverkolta tuon vaihdon osalta, eikä mikään tunneli paranna tuota ominaisuutta. Sen, minkä tunneli voi muuttaa, on se, mikä verkko näkee ulommat paketit ja mikä operaattori on nyt polulla.
Mitä HTTPS todella peittää
HTTPS suojaa sovelluksen vaihdon asiakkaan ja sen päätepisteen välillä, jonka varmenteessa nimetään. Se ei peitä kohdeosoitetta, se ei peitä sitä, että yhteys tapahtui, eikä se peitä nimeä, ellei ECH ole pelissä. Varmenteen validointi on osa suojausta, ei sen ympärillä oleva muodollisuus.
VPN:n ei tarvitse päättää tuota TLS:ää, eikä välityslähtöä pitäisi kohdella sovelluksen todennettuna päätepisteenä. Jos suunnittelussa lähtö purkaa salauksen, se on toinen arkkitehtuuri ja toinen luottamuslausuma.
Mitä DoH ja ECH siirtävät ja mitä jättävät
DoH siirtää DNS-vaihdon HTTPS-resolverille, mikä tarkoittaa, että tämä resolver näkee kyselysi paikallisen verkon resolverin sijaan. Se on todellinen ja rajattu muutos: valitusta resolverista tulee osapuoli, joka voi korreloida kyselyt niihin osoitteisiin, joihin myöhemmin yhdistät, ja juuri siitä korrelaatiosta RFC 8484 puhuu. Salattu siirto ei tee vastaanottajaa tietämättömäksi kyselyistä, joihin se vastaa.
ECH suojaa ClientHellon arkaluontoisen osan, jotta polulla oleva passiivinen tarkkailija ei voi lukea aiottua palvelimen nimeä. Se riippuu tukea tarjoavasta käyttöönotosta sekä palvelimen ja verkon hyväksynnästä, ja se jättää muut kanavat paikoilleen: kohdeosoitteet pysyvät näkyvinä ja DNS voi yhä paljastaa nimen.
Toinen asia, jota ECH ei tee, on todistaa itseään. TLS 1.3:a käyttävä yhteys ei ole todiste siitä, että ECH hyväksyttiin, ja selain, joka tarjoaa ECH:tä palvelimelle, joka ei tue sitä, vetäytyy hiljaa. Tarkista yhteyden todellinen tila sen sijaan, että päättelet sen protokollan versiosta.
Tämä on koko vertailun yleinen muoto: jokainen mekanismi varmennetaan omalla kerroksellaan, eikä yhtäkään niistä varmenneta toisen onnistumisella.
Mitä VPN siirtää ja mitä se lisää
Kun verkkoliikenne tulee VPN:ään, käyttöverkko näkee ulomman vaihdon VPN-vertaiskumppanin kanssa yksittäisten sovellusyhteyksien sijaan, ja VPN-operaattori ottaa aseman eteenpäin menevällä polulla. Se on luottamusrajan siirto, ei sen poistaminen. Operaattori näkee nyt, mihin kohteisiin pääset, vaikka sisältö pysyy salattuna päästä päähän. Onko se parannus, riippuu täysin siitä, kumpaa näistä kahdesta osapuolesta luotat vähemmän.
Pidä sovelluksen HTTPS ja aiottu resolverin suojaus paikoillaan tätä tehdessäsi. Tunneli ei korvaa varmenteen validointia, ja resolverin suojausten sammuttaminen siksi, että liikenne kulkee tunnelissa, poistaa hallinnan korvaamatta sitä.
Valinta vaatimuksesta
Esitä todellinen vaatimus, koska se ratkaisee suunnittelun. Pääsy yksityisiin resursseihin, hallittu lähtöpiste, tietty käyttöverkon uhka ja laitevaltuutus ovat neljä erilaista tarvetta ja neljä erilaista vastausta, ja yrityksen, joka käyttää vain julkisia pilvisovelluksia, on silti päätettävä valtuutuksesta ja tietojen käsittelystä. Lisäkerrokset voivat olla asianmukaisia olematta vaihdettavissa. Monimutkaisempi yhteys ei ole anonymiteetin mittari eikä itsessään turvallisuusargumentti.
ECH:n määritelmä, RFC 9849, kannattaa lukea sen vuoksi, mitä mekanismi kattaa ja mitä ei, ja se on rehellinen niistä kanavista, jotka se jättää rauhaan. Vertaa mekanismeja sen tarkkailijan mukaan, jonka kukin poistaa, kirjoita se tarkkailija muistiin ja päätä sitten, kohdistaako lisäkerros siihen. Jos vastaus on, että tarkkailija oli jo uhkamallisi ulkopuolella, tunneli on kustannus ilman hyötyä.