Erstatter ECH en VPN? Hvad hver af dem egentlig skjuler

Du aktiverer Encrypted Client Hello, åbner et websted, og forbindelsen virker. Nogen spørger, om VPN'en stadig er nødvendig, og det ærlige svar er, at de to funktioner skjuler forskellige ting for forskellige parter. ECH beskytter dele af TLS-håndtrykket, som ellers kan afsløre det servernavn, du bad om. En VPN sætter din trafik ind i en tunnel, der ender ved en udbyders endepunkt. At forveksle de to fører enten til at betale for meget for beskyttelse, du allerede har, eller til at tro, at du har beskyttelse, du aldrig har haft.

Hvad håndtrykket afslører uden ECH

En TLS-forbindelse begynder med en ClientHello, og i den ældre form rejser det tilsigtede servernavn i klartekst inde i den. Enhver, der er i stand til at observere håndtrykket, fra en netværksoperatør til en passiv sensor på en rute, kan læse det navn, selvom applikationsdataene bagefter er krypterede. Destinationsadressen er også synlig, så navnet er ofte bekræftende information snarere end det eneste signal.

Det er den specifikke lækage, ECH sigter på. Det er en snæver lækage, og det er værd at indsnævre den, men det er ikke det samme som at skjule, hvor din trafik går hen.

Hvad ECH faktisk ændrer

Med kompatibel klient- og serversupport og den nødvendige konfiguration krypterer ECH en indre ClientHello med nøgler, som serveren har offentliggjort, så en observatør ser et ydre håndtryk, der ikke bærer det rigtige servernavn. Trafikken går stadig til samme adresse, på samme tidspunkter, i nogenlunde samme mængder. Timing og størrelse forbliver observerbare, og destinations-IP'en var aldrig en del af det, ECH krypterer.

Support er heller ikke universel. Ikke hver klient, tjeneste eller enkeltforbindelse bruger ECH, og du kan ikke udlede tilstedeværelsen af et hængelåsikon eller af at have skiftet VPN-land. Diagnose kræver et kig på håndtrykket, ikke på browserens dekoration.

Hvad VPN'en ændrer i stedet

En VPN fører dækket trafik inde i en tunnel til et endepunkt, så den observatør, der er tættest på dig, ser en forbindelse til VPN'en snarere end til destinationen. Det ændrer, hvem der kan observere hvad, og det ændrer den adresse, destinationen ser. Den krypterer ikke noget, som applikationen ikke allerede har krypteret, og den skjuler ikke forbindelsen for VPN-udbyderen, som per konstruktion er i ruten.

De to kombineres naturligt: en applikation kan bruge TLS og ECH, mens tunnelen beskytter netværkssegmentet omkring den. Ingen af dem fastlægger, hvad hver part kan se eller gemme, fordi parterne indtager forskellige positioner på ruten.

Hvor DNS passer ind

En ubeskyttet DNS-forespørgsel afslører navnet for resolveren og for enhver, der observerer den rute, hvilket er en eksponering adskilt fra TLS-håndtrykket. ECH krypterer ikke DNS, og en VPN ændrer kun resolverens identitet, hvis du også sender dine forespørgsler gennem tunnelen eller bruger en krypteret resolver. Folk aktiverer en af de tre og antager, at de to andre fulgte med.

Kontroller resolverens rute adskilt fra håndtrykkets rute. De fejler uafhængigt, og de konfigureres forskellige steder.

Sådan afgør du, hvilket lag du kigger på

Spørg, hvad observationen ville afsløre. Hvis spørgsmålet er, hvilket servernavn der blev anmodet om, er håndtrykket og resolveren de relevante lag. Hvis spørgsmålet er, hvilket netværk trafikken gik til, og hvem der kunne se den undervejs, er det tunnelen. Hvis spørgsmålet er, hvilken konto der gjorde hvad på webstedet, hjælper ingen af dem, fordi webstedet stadig modtager anmodningen og enhver identitet, du har angivet.

Hold certifikatvalidering og DNS-politik intakte, mens du undersøger kompatibilitet. At deaktivere en kontrol for at få en test til at bestå ændrer, hvad resultatet betyder, i stedet for at vise, hvad ECH beskytter.

Skriv ned, hvilket lag du faktisk har aktiveret, før du tilføjer et mere. Det meste af forvirringen her kommer fra at antage, at én enkelt kontrol dækker en anmodning, dens navn, dens destination og dens identitet på én gang.