Substitueix ECH una VPN? Què amaga realment cadascun

Activeu Encrypted Client Hello, obriu un lloc i la connexió funciona. Algú pregunta si la VPN encara cal, i la resposta honesta és que les dues funcions amaguen coses diferents de parts diferents. ECH protegeix parts de l'handshake TLS que d'altra manera poden revelar el nom de servidor que heu demanat. Una VPN posa el vostre trànsit dins d'un túnel que acaba al punt final d'un operador. Confondre els dos porta o bé a pagar de més per una protecció que ja teniu, o bé a creure que teniu una protecció que mai no heu tingut.

Què exposa l'handshake sense ECH

Una connexió TLS comença amb un ClientHello, i en la forma més antiga el nom de servidor previst viatja en clar a dins. Qualsevol que estigui en posició d'observar l'handshake, des d'un operador de xarxa fins a un sensor passiu en un camí, pot llegir aquest nom tot i que les dades de l'aplicació posteriors estan xifrades. L'adreça de destinació també és visible, així que sovint el nom és informació confirmatòria més que no pas l'únic senyal.

Aquesta és la fuita concreta a què apunta ECH. És una fuita estreta, i estrènyer-la val la pena, però no és el mateix que amagar on va el vostre trànsit.

Què canvia realment ECH

Amb suport compatible de client i servidor i la configuració necessària, ECH xifra un ClientHello intern amb claus publicades pel servidor, de manera que un observador veu un handshake extern que no porta el nom real del servidor. El trànsit continua anant a la mateixa adreça, a les mateixes hores, en volums aproximadament iguals. El temps i la mida segueixen sent observables, i la IP de destinació mai no va formar part del que ECH xifra.

El suport tampoc no és universal. No cada client, servei o connexió individual utilitza ECH, i no podeu inferir-ne la presència a partir d'una icona de cadenat ni d'haver canviat el país de la VPN. Diagnosticar-ho requereix mirar l'handshake, no l'ornament del navegador.

Què canvia la VPN en canvi

Una VPN porta el trànsit cobert dins d'un túnel fins a un punt final, així que l'observador més proper a vosaltres veu una connexió a la VPN i no a la destinació. Això canvia qui pot observar què, i canvia l'adreça que veu la destinació. No xifra res que l'aplicació no hagués xifrat ja, i no amaga la connexió a l'operador de la VPN, que per construcció és al camí.

Els dos es combinen de manera natural: una aplicació pot utilitzar TLS i ECH mentre el túnel protegeix el segment de xarxa del voltant. Cap dels dos estableix què pot veure o retenir cada part, perquè les parts ocupen posicions diferents al camí.

On encaixa el DNS

Una consulta DNS no protegida revela el nom al resolutor i a qualsevol que observi aquest camí, cosa que és una exposició separada de l'handshake TLS. ECH no xifra el DNS, i una VPN només canvia la identitat del resolutor si també envieu les consultes pel túnel o feu servir un resolutor xifrat. La gent n'activa un dels tres i suposa que els altres dos han seguit.

Comproveu el camí del resolutor per separat del camí de l'handshake. Fallen de manera independent i es configuren en llocs diferents.

Com saber a quina capa esteu mirant

Pregunteu què revelaria l'observació. Si la pregunta és quin nom de servidor s'ha demanat, l'handshake i el resolutor són les capes rellevants. Si la pregunta és a quina xarxa ha anat el trànsit i qui el podia veure en trànsit, és el túnel. Si la pregunta és quin compte ha fet què al lloc, cap dels dos no ajuda, perquè el lloc web encara rep la petició i qualsevol identitat que hàgiu proporcionat.

Mantingueu la verificació de certificats i la política de DNS intactes mentre investigueu la compatibilitat. Desactivar una comprovació per fer passar una prova canvia el significat del resultat en lloc de mostrar què protegeix ECH.

Anoteu quina capa heu activat realment abans d'afegir-ne una altra. La major part de la confusió aquí ve de suposar que un sol control cobreix una petició, el seu nom, la seva destinació i la seva identitat alhora.