HTTPS, DoH, ECH og en VPN skjuler forskjellige ting
Hver mekanisme fjerner en annen observatør fra veien, og ingen fjerner alle. Sammenlign hva som er beskyttet før du legger til enda en tunnel.
Å legge til en VPN i en nettleser som allerede bruker HTTPS, DoH og ECH stabler ikke tre beskyttelser i én; det endrer hvem som er i posisjon til å observere hva. Hver mekanisme fjerner en annen part fra en annen utveksling, og hver av dem etterlater noe. Det nyttige spørsmålet er ikke hvilken som er sterkest, men hvilken observatør du prøver å fjerne, fordi svaret avgjør om en tunnel hjelper i det hele tatt. Sammenligningen av de gjenstående observatørene er nyttigere enn en funksjonsliste.
Fire mekanismer, fire observatører
Begynn med de fire relasjonene og den parten hver av dem er laget for å holde utenfor. Tabellen nedenfor er den jeg bruker i gjennomgang, fordi den tvinger samtalen til å navngi en observatør i stedet for en teknologi.
| Mekanisme | Relasjonen den beskytter | Observatøren den ikke fjerner |
|---|---|---|
| HTTPS | Applikasjonens TLS-tilkobling til sitt navngitte endepunkt | Aksessnettet ser fortsatt destinasjonsadressen |
| DoH | DNS-utvekslingen med den valgte HTTPS-resolveren | Den resolveren ser hver spørring |
| ECH | De følsomme ClientHello-feltene, der det støttes og aksepteres | Destinasjonsadresser, og DNS hvis det ikke er dekket |
| VPN | Dekkede pakker båret til VPN-peeren | VPN-operatøren ser destinasjonene |
Verdien av tabellen er det den nekter å si. Den rangerer ikke mekanismene, og den påstår ikke at bruk av alle fire fjerner alle fire observatørene. En skybasert webapplikasjon som allerede avslutter TLS ved sin egen kant, er beskyttet mot aksessnettet for den utvekslingen, og ingen tunnel forbedrer nettopp den egenskapen. Det en tunnel kan endre, er hvilket nettverk som ser de ytre pakkene og hvilken operatør som nå er på veien.
Hva HTTPS faktisk skjuler
HTTPS beskytter applikasjonens utveksling mellom klienten og endepunktet sertifikatet navngir. Den skjuler ikke destinasjonsadressen, den skjuler ikke at det skjedde en tilkobling, og den skjuler ikke navnet med mindre ECH er i spill. Sertifikatvalidering er en del av beskyttelsen, ikke en formalitet rundt den.
En VPN trenger ikke avslutte den TLS-en, og en videresendende utgang bør ikke behandles som applikasjonens autentiserte endepunkt. Hvis et design lar utgangen dekryptere, er det en annen arkitektur med en annen tillitserklæring.
Hva DoH og ECH flytter, og hva de lar bli
DoH flytter DNS-utvekslingen til en HTTPS-resolver, noe som betyr at den resolveren ser spørringene dine i stedet for den lokale nettverksresolveren. Det er en reell og avgrenset endring: den valgte resolveren blir en part som kan korrelere spørringer med adressene du deretter kobler til, og det er nettopp korrelasjonen RFC 8484 drøfter. Kryptert transport gjør ikke mottakeren uvitende om spørringene den besvarer.
ECH beskytter den følsomme delen av ClientHello slik at en passiv observatør på veien ikke kan lese det tiltenkte servernavnet. Det avhenger av en støttende utrulling og av aksept fra serveren og nettverket, og det lar andre kanaler stå: destinasjonsadresser forblir synlige, og DNS kan fortsatt avsløre navnet.
Den andre tingen ECH ikke gjør, er å bevise seg selv. En tilkobling som bruker TLS 1.3 er ikke bevis for at ECH ble akseptert, og en nettleser som tilbyr ECH til en server uten støtte, faller stille tilbake. Kontroller den faktiske tilstanden til tilkoblingen i stedet for å utlede den fra protokollversjonen.
Det er den generelle formen for hele denne sammenligningen: hver mekanisme verifiseres på sitt eget lag, og ingen av dem verifiseres av en annens suksess.
Hva en VPN flytter, og hva den tilfører
Når webtrafikk går inn i en VPN, ser aksessnettet den ytre utvekslingen med VPN-peeren i stedet for de enkelte applikasjonstilkoblingene, og VPN-operatøren tar posisjon på den videre veien. Det er en flytting av tillitsgrensen, ikke en fjerning av den. Operatøren ser nå hvilke destinasjoner du når, selv om innholdet forblir kryptert ende til ende. Om det er en forbedring avhenger helt av hvilken av de to partene du stoler minst på.
Behold applikasjonens HTTPS og den tiltenkte resolverbeskyttelsen på plass mens du gjør dette. En tunnel er ikke en erstatning for sertifikatvalidering, og å slå av en resolvers beskyttelser fordi trafikken går gjennom en tunnel, fjerner en kontroll uten å erstatte den.
Å velge ut fra kravet
Angi det faktiske kravet, fordi det er det som avgjør designet. Tilgang til private ressurser, et administrert utgangspunkt, en bestemt trussel mot aksessnettet og enhetsautorisasjon er fire forskjellige behov med fire forskjellige svar, og en bedrift som bare bruker offentlige skyapplikasjoner må fortsatt bestemme autorisasjon og datahåndtering. Ekstra lag kan være passende uten å være utskiftbare. En mer komplisert tilkobling er ikke en anonymitetsmåling, og den er ikke et sikkerhetsargument i seg selv.
ECH-spesifikasjonen, RFC 9849, er verdt å lese for hva mekanismen dekker og ikke dekker, og den er ærlig om kanalene den lar være i fred. Sammenlign mekanismene etter observatøren hver av dem fjerner, skriv ned den observatøren, og avgjør deretter om det ekstra laget adresserer den. Hvis svaret er at observatøren allerede var utenfor trusselmodellen din, er tunnelen kostnad uten nytte.