HTTPS, DoH, ECH og en VPN skjuler forskellige ting
Hver mekanisme fjerner en anden observatør fra vejen, og ingen fjerner dem alle. Sammenlign, hvad der er beskyttet, før du tilføjer endnu en tunnel.
At tilføje en VPN til en browser, der allerede bruger HTTPS, DoH og ECH, stabler ikke tre beskyttelser i én; det ændrer, hvem der er i en position til at observere hvad. Hver mekanisme fjerner en anden part fra en anden udveksling, og hver især efterlader noget. Det nyttige spørgsmål er ikke, hvilken der er stærkest, men hvilken observatør du prøver at fjerne, fordi svaret afgør, om en tunnel hjælper overhovedet. Sammenligningen af de resterende observatører er mere nyttig end en funktionsliste.
Fire mekanismer, fire observatører
Begynd med de fire relationer og den part, som hver af dem er designet til at holde ude. Tabellen nedenfor er den, jeg bruger ved gennemgang, fordi den tvinger samtalen til at navngive en observatør i stedet for en teknologi.
| Mekanisme | Relation, den beskytter | Observatør, den ikke fjerner |
|---|---|---|
| HTTPS | Applikationens TLS-forbindelse til sit navngivne endpoint | Adgangsnettet ser stadig destinationsadressen |
| DoH | DNS-udvekslingen med den valgte HTTPS-resolver | Den resolver ser hver forespørgsel |
| ECH | De følsomme ClientHello-felter, hvor det understøttes og accepteres | Destinationsadresser, og DNS hvis det ikke er dækket |
| VPN | Dækkede pakker båret til VPN-peeren | VPN-operatøren ser destinationerne |
Tabellens værdi er det, den nægter at sige. Den rangerer ikke mekanismerne, og den påstår ikke, at brug af alle fire fjerner alle fire observatører. En cloud-webapplikation, der allerede afslutter TLS ved sin egen kant, er beskyttet mod adgangsnettet for den udveksling, og ingen tunnel forbedrer netop den egenskab. Hvad en tunnel kan ændre, er hvilket netværk der ser de ydre pakker, og hvilken operatør der nu er på vejen.
Hvad HTTPS faktisk skjuler
HTTPS beskytter applikationens udveksling mellem klienten og det endpoint, som certifikatet navngiver. Den skjuler ikke destinationsadressen, den skjuler ikke, at der skete en forbindelse, og den skjuler ikke navnet, medmindre ECH er i spil. Certifikatvalidering er en del af beskyttelsen, ikke en formalitet omkring den.
En VPN behøver ikke afslutte den TLS, og en videresendende udgang bør ikke behandles som applikationens godkendte endpoint. Hvis et design lader udgangen dekryptere, er det en anden arkitektur med en anden tillidserklæring.
Hvad DoH og ECH flytter, og hvad de efterlader
DoH flytter DNS-udvekslingen til en HTTPS-resolver, hvilket betyder, at den resolver ser dine forespørgsler i stedet for det lokale netværks resolver. Det er en reel og afgrænset ændring: den valgte resolver bliver en part, der kan korrelere forespørgsler med de adresser, du derefter forbinder til, og det er netop den korrelation, som RFC 8484 drøfter. Krypteret transport gør ikke modtageren uvidende om de forespørgsler, den besvarer.
ECH beskytter den følsomme del af ClientHello, så en passiv observatør på vejen ikke kan læse det tilsigtede servernavn. Det afhænger af en understøttende udrulning og af accept fra serveren og netværket, og det efterlader andre kanaler på plads: destinationsadresser forbliver synlige, og DNS kan stadig afsløre navnet.
Den anden ting, ECH ikke gør, er at bevise sig selv. En forbindelse, der bruger TLS 1.3, er ikke bevis for, at ECH blev accepteret, og en browser, der tilbyder ECH til en server uden understøttelse, falder stille tilbage. Kontroller forbindelsens faktiske tilstand i stedet for at udlede den af protokolversionen.
Det er den generelle form for hele denne sammenligning: hver mekanisme verificeres på sit eget lag, og ingen af dem verificeres af en andens succes.
Hvad en VPN flytter, og hvad den tilføjer
Når webtrafik går ind i en VPN, ser adgangsnettet den ydre udveksling med VPN-peeren i stedet for de enkelte applikationsforbindelser, og VPN-operatøren tager en position på den videre vej. Det er en flytning af tillidsgrænsen, ikke en fjernelse af den. Operatøren ser nu, hvilke destinationer du når, selv om indholdet forbliver krypteret ende til ende. Om det er en forbedring, afhænger fuldstændigt af, hvilken af de to parter du stoler mindst på.
Behold applikationens HTTPS og den tilsigtede resolverbeskyttelse på plads, mens du gør dette. En tunnel er ikke en erstatning for certifikatvalidering, og at slå en resolvers beskyttelser fra, fordi trafikken er tunneleret, fjerner en kontrol uden at erstatte den.
At vælge ud fra kravet
Angiv det faktiske krav, fordi det er det, der afgør designet. Adgang til private ressourcer, et administreret udgangspunkt, en bestemt trussel mod adgangsnettet og enhedsautorisation er fire forskellige behov med fire forskellige svar, og en virksomhed, der kun bruger offentlige cloud-applikationer, skal stadig beslutte autorisation og datahåndtering. Ekstra lag kan være passende uden at være indbyrdes udskiftelige. En mere kompliceret forbindelse er ikke en anonymitetsmåling, og den er ikke i sig selv et sikkerhedsargument.
ECH-specifikationen, RFC 9849, er værd at læse for at se, hvad mekanismen dækker og ikke dækker, og den er ærlig om de kanaler, den lader være. Sammenlign mekanismerne efter den observatør, hver af dem fjerner, skriv den observatør ned, og beslut derefter, om det ekstra lag adresserer den. Hvis svaret er, at observatøren allerede var uden for din trusselsmodel, er tunnelen omkostning uden gavn.