HTTPS, DoH, ECH og ein VPN skjuler ulike ting
Kvar mekanisme fjernar ein annan observatør frå vegen, og ingen fjernar alle. Samanlikn kva som er verna før du legg til endå ein tunnel.
Å leggje til ein VPN i ein nettlesar som allereie brukar HTTPS, DoH og ECH stablar ikkje tre vern i eitt; det endrar kven som er i posisjon til å observere kva. Kvar mekanisme fjernar ein annan part frå ei anna utveksling, og kvar av dei lèt noko att. Det nyttige spørsmålet er ikkje kven som er sterkast, men kven observatør du prøver å fjerne, fordi svaret avgjer om ein tunnel hjelper i det heile. Samanlikninga av dei attverande observatørane er nyttigare enn ei funksjonsliste.
Fire mekanismar, fire observatørar
Byrja med dei fire relasjonane og den parten kvar av dei er laga for å halde utanfor. Tabellen nedanfor er den eg brukar i gjennomgang, fordi han tvingar samtalen til å namngi ein observatør i staden for ein teknologi.
| Mekanisme | Relasjonen han vernar | Observatøren han ikkje fjernar |
|---|---|---|
| HTTPS | TLS-tilkoplinga til applikasjonen til det namngitte endepunktet | Aksessnettet ser framleis destinasjonsadressa |
| DoH | DNS-utvekslinga med den valde HTTPS-resolveren | Den resolveren ser kvar spørjing |
| ECH | Dei følsame ClientHello-felta, der det er støtta og akseptert | Destinasjonsadresser, og DNS om det ikkje er dekt |
| VPN | Dekka pakkar borne til VPN-peeren | VPN-operatøren ser destinasjonane |
Verdien av tabellen er det han nektar å seie. Han rangerer ikkje mekanismane, og han påstår ikkje at bruk av alle fire fjernar alle fire observatørane. Ein skybasert webapplikasjon som allereie avsluttar TLS ved sin eigen kant, er verna mot aksessnettet for den utvekslinga, og ingen tunnel betrar nettopp den eigenskapen. Det ein tunnel kan endre, er kva nettverk som ser dei ytre pakkane og kven operatør som no er på vegen.
Kva HTTPS faktisk skjuler
HTTPS vernar utvekslinga til applikasjonen mellom klienten og endepunktet sertifikatet namngir. Han skjuler ikkje destinasjonsadressa, han skjuler ikkje at det skjedde ei tilkopling, og han skjuler ikkje namnet med mindre ECH er i spel. Sertifikatvalidering er ein del av vernet, ikkje ein formalitet rundt det.
Ein VPN treng ikkje avslutte den TLS-en, og ein videresendande utgang bør ikkje handsamast som det autentiserte endepunktet til applikasjonen. Viss eit design lèt utgangen dekryptere, er det ein annan arkitektur med ei anna tillitserklæring.
Kva DoH og ECH flyttar, og kva dei lèt bli
DoH flyttar DNS-utvekslinga til ein HTTPS-resolver, noko som tyder at den resolveren ser spørjingane dine i staden for resolversen i det lokale nettverket. Det er ei reell og avgrensa endring: den valde resolveren blir ein part som kan korrelere spørjingar med adressene du deretter koplar til, og det er nettopp korrelasjonen RFC 8484 drøftar. Kryptert transport gjer ikkje mottakaren uvitande om spørjingane han svarer på.
ECH vernar den følsame delen av ClientHello slik at ein passiv observatør på vegen ikkje kan lese det tiltenkte servernamnet. Det er avhengig av ein støttande utrulling og av aksept frå serveren og nettverket, og det lèt andre kanalar stå: destinasjonsadresser er framleis synlege, og DNS kan framleis røpe namnet.
Den andre tingen ECH ikkje gjer, er å prove seg sjølv. Ei tilkopling som brukar TLS 1.3 er ikkje prov på at ECH vart akseptert, og ein nettlesar som tilbyr ECH til ein server utan støtte, fell stille tilbake. Kontroller den faktiske tilstanden til tilkoplinga i staden for å utleie han frå protokollversjonen.
Det er den generelle forma for heile denne samanlikninga: kvar mekanisme vert verifisert på sitt eige lag, og ingen av dei vert verifisert av suksessen til ein annan.
Kva ein VPN flyttar, og kva han tilfører
Når webtrafikk går inn i ein VPN, ser aksessnettet den ytre utvekslinga med VPN-peeren i staden for dei enkelte applikasjonstilkoplingane, og VPN-operatøren tek posisjon på den vidare vegen. Det er ei flytting av tillitsgrensa, ikkje ein fjerning av ho. Operatøren ser no kva destinasjonar du når, sjølv om innhaldet blir verande kryptert ende til ende. Om det er ei betring er heilt avhengig av kven av dei to partane du stolar minst på.
Hald HTTPS-en til applikasjonen og det tiltenkte resolververnet på plass medan du gjer dette. Ein tunnel er ikkje ei erstatning for sertifikatvalidering, og å slå av vernet til ein resolver fordi trafikken går gjennom ein tunnel, fjernar ein kontroll utan å erstatte han.
Å velje ut frå kravet
Angi det faktiske kravet, fordi det er det som avgjer designet. Tilgang til private ressursar, eit administrert utgangspunkt, ein bestemd trussel mot aksessnettet og einingautorisasjon er fire ulike behov med fire ulike svar, og ei verksemd som berre brukar offentlege skyapplikasjonar må framleis avgjere autorisasjon og datahandsaming. Ekstra lag kan vere høvelege utan å vere utskiftbare. Ei meir komplisert tilkopling er ikkje ei anonymitetsmåling, og ho er ikkje eit tryggleiksargument i seg sjølv.
ECH-spesifikasjonen, RFC 9849, er verdt å lese for kva mekanismen dekkjer og ikkje dekkjer, og han er ærleg om kanalane han lèt vere i fred. Samanlikn mekanismane etter observatøren kvar av dei fjernar, skriv ned den observatøren, og avgjer deretter om det ekstra laget adresserer han. Viss svaret er at observatøren allereie var utanfor trugsmålsmodellen din, er tunnelen kostnad utan nytte.