HTTPS, DoH, ECH y una VPN ocultan cosas distintas
Cada mecanismo elimina del camino a un observador distinto, y ninguno los elimina todos. Compare qué queda protegido antes de añadir otro túnel.
Añadir una VPN a un navegador que ya usa HTTPS, DoH y ECH no apila tres protecciones en una; cambia quién está en posición de observar qué. Cada mecanismo elimina a una parte distinta de un intercambio distinto, y cada uno deja algo atrás. La pregunta útil no es cuál es el más fuerte, sino qué observador intentas eliminar, porque la respuesta decide si un túnel ayuda siquiera. Una comparación de los observadores que quedan es más útil que una lista de funciones.
Cuatro mecanismos, cuatro observadores
Empieza por las cuatro relaciones y por la parte que cada una está diseñada a dejar fuera. La tabla de abajo es la que uso en revisión, porque obliga a la conversación a nombrar un observador en lugar de una tecnología.
| Mecanismo | Relación que protege | Observador que no elimina |
|---|---|---|
| HTTPS | La conexión TLS de la aplicación con su punto final nombrado | La red de acceso sigue viendo la dirección de destino |
| DoH | El intercambio DNS con el resolutor HTTPS elegido | Ese resolutor ve cada consulta |
| ECH | Los campos sensibles del ClientHello, cuando se admiten y se aceptan | Las direcciones de destino, y el DNS si no queda cubierto |
| VPN | Los paquetes cubiertos llevados hasta el par de VPN | El operador de la VPN ve los destinos |
El valor de la tabla es lo que se niega a decir. No clasifica los mecanismos ni afirma que usar los cuatro elimine a los cuatro observadores. Una aplicación web en la nube que ya termina TLS en su propio borde está protegida de la red de acceso para ese intercambio, y ningún túnel mejora esa propiedad concreta. Lo que un túnel puede cambiar es qué red ve los paquetes exteriores y qué operador está ahora en el camino.
Qué oculta realmente HTTPS
HTTPS protege el intercambio de la aplicación entre el cliente y el punto final que nombra el certificado. No oculta la dirección de destino, no oculta que hubo una conexión y no oculta el nombre salvo que ECH esté en juego. La validación del certificado es parte de la protección, no una formalidad a su alrededor.
Una VPN no necesita terminar ese TLS, y una salida de reenvío no debe tratarse como el punto final autenticado de la aplicación. Si un diseño hace que la salida descifre, esa es otra arquitectura con otra declaración de confianza.
Qué mueven DoH y ECH, y qué dejan
DoH traslada el intercambio DNS a un resolutor HTTPS, lo que significa que ese resolutor ve tus consultas en lugar del resolutor de la red local. Es un cambio real y acotado: el resolutor elegido pasa a ser una parte que puede correlacionar las consultas con las direcciones a las que luego te conectas, que es precisamente la correlación que trata RFC 8484. El transporte cifrado no hace que el destinatario desconozca las consultas que responde.
ECH protege la parte sensible del ClientHello para que un observador pasivo en el camino no pueda leer el nombre de servidor previsto. Depende de un despliegue compatible y de la aceptación del servidor y de la red, y deja otros canales en su sitio: las direcciones de destino siguen visibles y el DNS puede revelar todavía el nombre.
La otra cosa que ECH no hace es demostrarse a sí mismo. Una conexión que usa TLS 1.3 no es prueba de que ECH se haya aceptado, y un navegador que ofrece ECH a un servidor que no lo admite retrocede en silencio. Comprueba el estado real de la conexión en lugar de deducirlo de la versión del protocolo.
Esa es la forma general de toda esta comparación: cada mecanismo se verifica en su propia capa, y ninguno de ellos se verifica por el éxito de otro.
Qué mueve una VPN, y qué añade
Cuando el tráfico web entra en una VPN, la red de acceso ve el intercambio exterior con el par de VPN en lugar de las conexiones individuales de las aplicaciones, y el operador de la VPN toma posición en el camino posterior. Es un desplazamiento de la frontera de confianza, no su eliminación. El operador ve ahora a qué destinos llegas, aunque el contenido siga cifrado de extremo a extremo. Si eso es una mejora depende por completo de a cuál de esas dos partes confías menos.
Mantén el HTTPS de la aplicación y la protección prevista del resolutor mientras haces esto. Un túnel no sustituye la validación del certificado, y desactivar las protecciones de un resolutor porque el tráfico va por un túnel elimina un control sin reemplazarlo.
Elegir a partir del requisito
Enuncia el requisito real, porque es lo que decide el diseño. La admisión a recursos privados, un punto de salida gestionado, una amenaza concreta de la red de acceso y la autorización de dispositivos son cuatro necesidades distintas con cuatro respuestas distintas, y una empresa que solo usa aplicaciones de nube pública sigue teniendo que decidir la autorización y el tratamiento de datos. Las capas adicionales pueden ser adecuadas sin ser intercambiables. Una conexión más complicada no es una medida de anonimato y no es un argumento de seguridad por sí misma.
La especificación de ECH, RFC 9849, merece leerse por lo que el mecanismo cubre y lo que no, y es honesta sobre los canales que deja en paz. Compara los mecanismos por el observador que elimina cada uno, escribe ese observador y luego decide si la capa extra se dirige a él. Si la respuesta es que el observador ya estaba fuera de tu modelo de amenazas, el túnel es coste sin beneficio.