Erstatter ECH en VPN? Hva hver av dem egentlig skjuler

Du aktiverer Encrypted Client Hello, åpner et nettsted, og forbindelsen virker. Noen spør om VPN-en fortsatt er nødvendig, og det ærlige svaret er at de to funksjonene skjuler ulike ting for ulike parter. ECH beskytter deler av TLS-håndtrykket som ellers kan avsløre servernavnet du ba om. En VPN setter trafikken din inn i en tunnel som ender ved en operatørs endepunkt. Å blande de to fører enten til å betale for mye for beskyttelse du allerede har, eller til å tro at du har beskyttelse du aldri har hatt.

Hva håndtrykket avslører uten ECH

En TLS-forbindelse begynner med en ClientHello, og i den eldre formen reiser det tiltenkte servernavnet i klartekst inne i den. Alle som er i stand til å observere håndtrykket, fra en nettverksoperatør til en passiv sensor på en rute, kan lese det navnet selv om applikasjonsdataene etterpå er kryptert. Destinasjonsadressen er også synlig, så navnet er ofte bekreftende informasjon snarere enn det eneste signalet.

Det er den spesifikke lekkasjen ECH retter seg mot. Den er smal, og det er verdt å snevre den inn, men det er ikke det samme som å skjule hvor trafikken din går.

Hva ECH faktisk endrer

Med kompatibel klient- og serverstøtte og den nødvendige konfigurasjonen krypterer ECH en indre ClientHello med nøkler serveren har publisert, slik at en observatør ser et ytre håndtrykk som ikke bærer det virkelige servernavnet. Trafikken går fortsatt til samme adresse, til samme tider, i omtrent samme mengder. Timing og størrelse er fortsatt observerbare, og destinasjons-IP-en var aldri en del av det ECH krypterer.

Støtten er heller ikke universell. Ikke hver klient, tjeneste eller enkeltforbindelse bruker ECH, og du kan ikke utlede tilstedeværelsen fra et hengelåsikon eller fra å ha byttet VPN-land. Å diagnostisere det krever å se på håndtrykket, ikke på nettleserens dekorasjon.

Hva VPN-en endrer i stedet

En VPN fører dekket trafikk inne i en tunnel til et endepunkt, slik at observatøren nærmest deg ser en forbindelse til VPN-en snarere enn til destinasjonen. Det endrer hvem som kan observere hva, og det endrer adressen destinasjonen ser. Den krypterer ikke noe applikasjonen ikke allerede har kryptert, og den skjuler ikke forbindelsen for VPN-operatøren, som per konstruksjon er i ruten.

De to kombineres naturlig: en applikasjon kan bruke TLS og ECH mens tunnelen beskytter nettverkssegmentet rundt den. Ingen av dem fastsetter hva hver part kan se eller beholde, fordi partene har ulike posisjoner i ruten.

Hvor DNS passer inn

En ubeskyttet DNS-forespørsel avslører navnet for resolvern og for alle som observerer den ruten, noe som er en eksponering adskilt fra TLS-håndtrykket. ECH krypterer ikke DNS, og en VPN endrer bare resolverens identitet hvis du også sender forespørslene gjennom tunnelen eller bruker en kryptert resolver. Folk aktiverer én av de tre og antar at de to andre fulgte etter.

Kontroller resolverens rute atskilt fra håndtrykkets rute. De feiler uavhengig, og de konfigureres på forskjellige steder.

Slik finner du ut hvilket lag du ser på

Spør hva observasjonen ville avsløre. Hvis spørsmålet er hvilket servernavn som ble forespurt, er håndtrykket og resolvern de relevante lagene. Hvis spørsmålet er hvilket nettverk trafikken gikk til og hvem som kunne se den underveis, er det tunnelen. Hvis spørsmålet er hvilken konto som gjorde hva på nettstedet, hjelper ingen av dem, fordi nettstedet fortsatt mottar forespørselen og enhver identitet du oppga.

Hold sertifikatvalidering og DNS-policy intakte mens du undersøker kompatibilitet. Å deaktivere en sjekk for å få en test til å bestå endrer hva resultatet betyr i stedet for å vise hva ECH beskytter.

Skriv ned hvilket lag du faktisk har aktivert før du legger til et nytt. Det meste av forvirringen her kommer fra å anta at én enkelt kontroll dekker en forespørsel, navnet dens, destinasjonen og identiteten på én gang.