HTTPS, DoH, ECH e unha VPN ocultan cousas distintas
Cada mecanismo elimina do camiño un observador distinto, e ningún os elimina todos. Compare o que queda protexido antes de engadir outro túnel.
Engadir unha VPN a un navegador que xa usa HTTPS, DoH e ECH non apila tres proteccións nunha; cambia quen está en posición de observar que. Cada mecanismo elimina unha parte distinta dun intercambio distinto, e cada un deixa algo atrás. A pregunta útil non é cal é o máis forte, senón que observador intentas eliminar, porque a resposta decide se un túnel axuda sequera. Unha comparación dos observadores que quedan é máis útil ca unha lista de funcións.
Catro mecanismos, catro observadores
Comece polas catro relacións e pola parte que cada unha está deseñada a deixar fóra. A táboa de abaixo é a que uso na revisión, porque obriga a conversa a nomear un observador en lugar dunha tecnoloxía.
| Mecanismo | Relación que protexe | Observador que non elimina |
|---|---|---|
| HTTPS | A conexión TLS da aplicación co seu punto final nomeado | A rede de acceso segue vendo o enderezo de destino |
| DoH | O intercambio DNS co resolvedor HTTPS elixido | Ese resolvedor ve cada consulta |
| ECH | Os campos sensibles do ClientHello, cando se admiten e se aceptan | Os enderezos de destino, e o DNS se non queda cuberto |
| VPN | Os paquetes cubertos levados ata o par de VPN | O operador da VPN ve os destinos |
O valor da táboa é o que se nega a dicir. Non clasifica os mecanismos nin afirma que usar os catro elimine os catro observadores. Unha aplicación web na nube que xa remata TLS no seu propio bordo está protexida da rede de acceso para ese intercambio, e ningún túnel mellora esa propiedade concreta. O que un túnel pode cambiar é que rede ve os paquetes exteriores e que operador está agora no camiño.
Que oculta realmente HTTPS
HTTPS protexe o intercambio da aplicación entre o cliente e o punto final que nomea o certificado. Non oculta o enderezo de destino, non oculta que houbo unha conexión e non oculta o nome agás que ECH estea en xogo. A validación do certificado é parte da protección, non unha formalidade ao seu redor.
Unha VPN non necesita rematar ese TLS, e unha saída de reenvío non debe tratarse como o punto final autenticado da aplicación. Se un deseño fai que a saída descifre, esa é outra arquitectura con outra declaración de confianza.
Que moven DoH e ECH, e que deixan
DoH traslada o intercambio DNS a un resolvedor HTTPS, o que significa que ese resolvedor ve as súas consultas en lugar do resolvedor da rede local. É un cambio real e limitado: o resolvedor elixido pasa a ser unha parte que pode correlacionar as consultas cos enderezos aos que logo se conecta, que é precisamente a correlación que trata RFC 8484. O transporte cifrado non fai que o destinatario descoñeza as consultas que responde.
ECH protexe a parte sensible do ClientHello para que un observador pasivo no camiño non poida ler o nome de servidor previsto. Depende dun despregamento compatible e da aceptación do servidor e da rede, e deixa outros canais no seu sitio: os enderezos de destino seguen visibles e o DNS pode revelar aínda o nome.
A outra cousa que ECH non fai é demostrarse a si mesmo. Unha conexión que usa TLS 1.3 non é proba de que ECH fose aceptado, e un navegador que ofrece ECH a un servidor que non o admite retrocede en silencio. Comprobe o estado real da conexión en lugar de deducilo da versión do protocolo.
Esta é a forma xeral de toda esta comparación: cada mecanismo verifícase na súa propia capa, e ningún deles se verifica polo éxito doutro.
Que move unha VPN, e que engade
Cando o tráfico web entra nunha VPN, a rede de acceso ve o intercambio exterior co par de VPN en lugar das conexións individuais das aplicacións, e o operador da VPN toma posición no camiño posterior. É un desprazamento da fronteira de confianza, non a súa eliminación. O operador ve agora a que destinos chega, aínda que o contido siga cifrado de extremo a extremo. Se iso é unha mellora depende por completo de a cal desas dúas partes confía menos.
Manteña o HTTPS da aplicación e a protección prevista do resolvedor mentres fai isto. Un túnel non substitúe a validación do certificado, e desactivar as proteccións dun resolvedor porque o tráfico vai por un túnel elimina un control sen substituílo.
Escoller a partir do requisito
Enuncie o requisito real, porque é o que decide o deseño. A admisión a recursos privados, un punto de saída xestionado, unha ameaza concreta da rede de acceso e a autorización de dispositivos son catro necesidades distintas con catro respostas distintas, e unha empresa que só usa aplicacións de nube pública segue tendo que decidir a autorización e o tratamento de datos. As capas adicionais poden ser adecuadas sen ser intercambiables. Unha conexión máis complicada non é unha medida de anonimato e non é un argumento de seguridade por si mesma.
A especificación de ECH, RFC 9849, merece lerse polo que o mecanismo cobre e polo que non, e é honesta sobre os canais que deixa en paz. Compare os mecanismos polo observador que elimina cada un, escriba ese observador e logo decida se a capa extra se dirixe a el. Se a resposta é que o observador xa estaba fóra do seu modelo de ameazas, o túnel é custo sen beneficio.