Ersätter ECH ett VPN? Vad var och en egentligen döljer

Du aktiverar Encrypted Client Hello, öppnar en webbplats och anslutningen fungerar. Någon frågar om VPN:et fortfarande behövs, och det ärliga svaret är att de två funktionerna döljer olika saker för olika parter. ECH skyddar delar av TLS-handskakningen som annars kan avslöja det servernamn du bad om. Ett VPN sätter din trafik i en tunnel som slutar vid en operatörs slutpunkt. Att blanda ihop de två leder antingen till att betala för mycket för skydd du redan har, eller till att tro att du har skydd du aldrig har haft.

Vad handskakningen avslöjar utan ECH

En TLS-anslutning börjar med en ClientHello, och i den äldre formen färdas det avsedda servernamnet i klartext inuti den. Den som kan observera handskakningen, från en nätverksoperatör till en passiv sensor på en väg, kan läsa det namnet även om applikationsdata efteråt är krypterad. Destinationsadressen är också synlig, så namnet är ofta bekräftande information snarare än den enda signalen.

Det är den specifika läckan som ECH riktar in sig på. Den är smal, och det är värt att snäva in den, men det är inte samma sak som att dölja vart din trafik tar vägen.

Vad ECH faktiskt ändrar

Med kompatibelt klient- och serverstöd och den nödvändiga konfigurationen krypterar ECH en inre ClientHello med nycklar som servern publicerat, så att en observatör ser en yttre handskakning som inte bär det riktiga servernamnet. Trafiken går fortfarande till samma adress, vid samma tider, i ungefär samma volymer. Timing och storlek är fortfarande observerbara, och destinations-IP:n var aldrig en del av det ECH krypterar.

Stödet är inte heller universellt. Inte varje klient, tjänst eller enskild anslutning använder ECH, och du kan inte sluta dig till dess närvaro från en hänglåsikon eller från att ha bytt VPN-land. Att diagnostisera det kräver att titta på handskakningen, inte på webbläsarens utsmyckning.

Vad VPN:et ändrar i stället

Ett VPN för täckt trafik inne i en tunnel till en slutpunkt, så observatören närmast dig ser en anslutning till VPN:et snarare än till destinationen. Det ändrar vem som kan observera vad, och det ändrar den adress som destinationen ser. Det krypterar inget som applikationen inte redan har krypterat, och det döljer inte anslutningen från VPN-operatören, som per konstruktion ligger på vägen.

De två kombineras naturligt: en applikation kan använda TLS och ECH medan tunneln skyddar nätverkssegmentet runt den. Ingen av dem fastställer vad varje part kan se eller behålla, eftersom parterna har olika positioner på vägen.

Var DNS passar in

En oskyddad DNS-förfrågan avslöjar namnet för resolvern och för alla som observerar den vägen, vilket är en exponering skild från TLS-handskakningen. ECH krypterar inte DNS, och ett VPN ändrar bara resolverens identitet om du också skickar dina förfrågningar genom tunneln eller använder en krypterad resolver. Folk aktiverar en av de tre och antar att de andra två följde med.

Kontrollera resolvervägen separat från handskakningsvägen. De misslyckas oberoende av varandra och de konfigureras på olika ställen.

Hur du avgör vilket lager du tittar på

Fråga vad observationen skulle avslöja. Om frågan är vilket servernamn som efterfrågades är handskakningen och resolvern de relevanta lagren. Om frågan är vilket nätverk trafiken gick till och vem som kunde se den under vägen är det tunneln. Om frågan är vilket konto som gjorde vad på webbplatsen hjälper ingen av dem, eftersom webbplatsen fortfarande tar emot begäran och varje identitet du angett.

Håll certifikatvalidering och DNS-policy intakta medan du undersöker kompatibilitet. Att stänga av en kontroll för att ett test ska gå igenom ändrar vad resultatet betyder i stället för att visa vad ECH skyddar.

Skriv ner vilket lager du faktiskt har aktiverat innan du lägger till ett till. Det mesta av förvirringen här kommer från antagandet att en enda kontroll täcker en begäran, dess namn, dess destination och dess identitet på en gång.