Para qué sirve ECH y por qué está cambiando cómo se bloquean las webs

ECH (Encrypted Client Hello) se ha convertido en uno de los temas estrella cuando se habla de privacidad, bloqueos de webs y peleas entre operadoras, grandes plataformas como Cloudflare y organismos como LaLiga. No es una moda pasajera: es la pieza que faltaba en el cifrado de las conexiones HTTPS para cerrar una grieta por la que se colaba mucha información sobre lo que hacemos en Internet.

En pocas palabras, ECH sirve para ocultar el dominio exacto de la web a la que te conectas incluso aunque ya estés usando HTTPS. Hasta ahora, las operadoras, sistemas de censura o equipos de inspección profunda de paquetes (DPI) podían saber a qué dominio estabas entrando gracias a un campo llamado SNI en el protocolo TLS. Con ECH, ese dato va cifrado, lo que complica enormemente los bloqueos selectivos y mejora de forma notable la privacidad del usuario.

Qué es ECH y qué problema viene a resolver

ECH (Encrypted Client Hello) es una extensión del protocolo TLS, el mismo que se usa en las conexiones HTTPS de prácticamente todas las webs modernas. Su objetivo principal es cifrar el mensaje inicial que envía el navegador al servidor, llamado ClientHello, donde viajan parámetros muy sensibles desde el punto de vista de la privacidad.

El punto crítico de todo esto es el campo SNI (Server Name Indication). Cuando accedes a una web segura, tu navegador y el servidor realizan una negociación TLS (el famoso handshake) para acordar claves y algoritmos de cifrado. Antes de ECH, aunque el contenido posterior de la conexión viajaba cifrado, el nombre del dominio al que quieres entrar se enviaba en texto plano dentro de ese SNI. Es decir, cualquiera situado entre tu equipo y el servidor (operadora, firewall corporativo, censor estatal, atacante en una WiFi pública…) podía ver a qué dominio ibas.

Esto se ha aprovechado durante años para aplicar bloqueos selectivos de webs. Los operadores montan equipos de Inspección Profunda de Paquetes (DPI) que analizan el tráfico TLS, leen el SNI y, si detectan un dominio “prohibido”, cortan la conexión y te devuelven un mensaje de bloqueo. Aunque todo lo demás esté cifrado, ese dato en claro era suficiente para filtrar y censurar.

Con ECH, el ClientHello se cifra usando una clave pública obtenida vía DNS, de modo que el SNI y otros parámetros dejan de ir a la vista. Desde fuera, lo único que se observa es que te estás conectando a una IP concreta (que en el caso de Cloudflare puede alojar miles de webs distintas), pero no se sabe qué dominio estás solicitando exactamente.

La gracia del asunto es que ECH no rediseña Internet desde cero. Se integra como una extensión de TLS 1.3, apoyándose además en tecnologías como DNS over HTTPS (DoH), DNS over TLS (DoT) y nuevos tipos de registros DNS (como HTTPS) para distribuir las claves públicas necesarias sin exponerlas a ataques o manipulaciones.

Cómo funcionaba el SNI y por qué era un coladero de privacidad

Para entender para qué sirve ECH, primero hay que ver el agujero que tapona: SNI. Hoy en día es muy habitual que una sola dirección IP aloje decenas, cientos o incluso miles de webs distintas, sobre todo detrás de CDNs como Cloudflare. El servidor necesita saber a qué sitio exacto quieres ir para poder mostrarte el certificado TLS correcto y establecer la conexión segura con la web adecuada.

Ahí entra en juego el campo SNI. En el mensaje ClientHello, el navegador indica: “quiero hablar con este dominio concreto”. Ese dato lo usan los servidores para seleccionar el certificado y configurar la conexión, pero el problema es que viaja en claro antes de que exista cifrado alguno. Resultado: todos los nodos intermedios pueden leerlo cómodamente.

Con ese simple dato, se pueden hacer muchas cosas nada inocentes: desde bloquear webs mediante reglas de firewall, hasta censurar portales de noticias, páginas de partidos políticos o servicios de la competencia. No hace falta romper el cifrado ni leer el contenido, basta con saber a qué dominio se quiere acceder y cortar el canal en ese punto.

Con ese simple dato, se pueden hacer muchas cosas nada inocentes: los operadores montan equipos de Inspección Profunda de Paquetes (DPI) que analizan el tráfico TLS, leen el SNI y, si detectan un dominio “prohibido”, cortan la conexión y te devuelven un mensaje de bloqueo.

Esta situación chocaba de frente con la evolución general de TLS hacia el cifrado total del protocolo de enlace. Con TLS 1.3 ya se había dado un salto grande: se encriptan muchos más mensajes del handshake que en TLS 1.2, mejorando tanto seguridad como velocidad. Pero quedaba una “última ventana” abierta: el SNI y otros parámetros del ClientHello seguían desnudos ante cualquiera.

Qué hace exactamente ECH y cómo cifra el ClientHello

ECH da una vuelta de tuerca a la forma en que se negocia TLS. En lugar de enviar un único ClientHello en claro, el navegador construye dos versiones: un ClientHelloOuter y un ClientHelloInner. El Outer va sin cifrar, como siempre, pero el Inner, que es el que contiene los datos sensibles (SNI real, lista ALPN, parámetros que revelan qué aplicación o servicio usarás, etc.), se cifra utilizando una clave pública que el servidor ha publicado previamente en DNS.

El flujo general sería algo así:

• El cliente obtiene, vía DNS (y preferiblemente mediante DoH o DoT), una clave pública ECH asociada al dominio al que quiere acceder. Esa clave va en registros especiales (como HTTPS) que describen capacidades TLS del servidor.
• El navegador construye el ClientHelloInner con la información real de destino (el dominio concreto detrás de la CDN, la lista ALPN, etc.) y lo cifra con esa clave pública usando HPKE (Hybrid Public Key Encryption).
• Ese ClientHelloInner cifrado se incluye como una extensión dentro del ClientHelloOuter, que es el que ve cualquier dispositivo de la red. El Outer contiene parámetros mínimos para que la conexión no se rompa, pero sin filtrar datos sensibles.
• Cuando el servidor recibe la petición, intenta descifrar el bloque ECH. Si puede descifrarlo, usa el ClientHelloInner y continúa el handshake con la web de destino real. Si no puede (por ejemplo, porque el cliente tiene una clave pública antigua), completa la negociación con el ClientHelloOuter y de paso le envía al cliente la clave ECH correcta para que lo reintente.

Este diseño soluciona varios problemas de golpe. Por un lado, protege la SNI y otros parámetros privados dentro del ClientHelloInner. Por otro, gestiona mejor los casos en los que las claves cambian o el DNS tiene versiones en caché, evitando que la conexión falle directamente, como sucedía con el intento previo llamado ESNI (Encrypted SNI).

ESNI fue el precursor directo de ECH. En ESNI solo se cifraba la extensión SNI, usando una clave pública distribuida por DNS. Si el servidor no lograba descifrarla (por clave caducada o inconsistencia en el DNS), la conexión se abortaba. Cloudflare llegó a implementar ESNI y rotaba la clave cada hora, pero el comportamiento en escenarios reales mostró bastantes pegas, especialmente con cachés DNS lentas o inconsistentes.

ECH amplía el enfoque y cifra el ClientHello completo (al menos la parte sensible), no solo el SNI. Además, su diseño contempla explícitamente esa “vía de escape” usando el ClientHelloOuter para no tirar abajo la conexión cuando hay problemas de claves, y apoyándose en nuevas especificaciones DNS y en HPKE para simplificar la parte criptográfica.

Relación entre ECH, DNS cifrado, VPN y otras tecnologías de privacidad

ECH no vive solo: se apoya en otras piezas de la arquitectura actual de Internet. Para que funcione de forma segura, hace falta que la distribución de la clave pública ECH a través de DNS no pueda ser espiada o manipulada por cualquiera que esté en la red.

Aquí entran en juego DNS over HTTPS (DoH) y DNS over TLS (DoT). Ambos protocolos sirven para cifrar las consultas DNS, de forma que los dominios que resuelves no vayan en texto plano. Si activas ECH pero sigues usando DNS tradicional sin cifrar, tu operadora o cualquier intermediario seguiría viendo las peticiones DNS, así que buena parte de la gracia se pierde.

Los navegadores modernos ya han dado pasos importantes:

• Firefox integra DoH y, de hecho, solo permite usar ECH si DoH está activo. En su configuración avanzada (about:config) pueden verse varias opciones “echconfig” en true, indicando que la extensión está habilitada, y se desactiva el fallback para no volver a SNI en texto plano fácilmente.
• Chrome, Edge y otros navegadores basados en Chromium permiten habilitar DNS seguro en sus menús de privacidad y seguridad. El usuario puede elegir proveedores como Cloudflare, Google u otros incorporados.

ECH también se lleva bien con las VPN. Una VPN cifra todo el tráfico y oculta tu IP pública detrás de la del proveedor, pero aunque uses VPN, sin ECH el SNI podría seguir siendo visible para el proveedor de la VPN u otros elementos de su red. Con ECH activo sobre una VPN, se añaden capas: tu IP queda camuflada por la VPN y, además, el dominio al que accedes va protegido dentro del ClientHello cifrado.

En redes públicas como cafeterías, aeropuertos o hoteles, ECH tiene aún más sentido. En estos entornos el riesgo de interceptación o manipulación de tráfico es mayor. Combinando ECH, DoH/DoT y, si quieres rizar el rizo, una VPN, reduces al mínimo la información que terceros pueden inferir sobre tus conexiones: ni el dominio exacto, ni el contenido, ni siquiera tu IP de origen real.

El conflicto ECH, LaLiga, Cloudflare y las operadoras

La teoría está muy bien, pero ECH también ha destapado un choque frontal de intereses entre quienes quieren reforzar la privacidad general de la red y quienes utilizan el SNI como herramienta para bloquear contenidos, como es el caso de la lucha contra las retransmisiones ilegales de fútbol.

Todo se empezó a calentar cuando Cloudflare activó ECH de forma masiva en su red. En octubre de 2023, la CDN decidió desplegar ECH para millones de dominios, lo que en la práctica hacía que las operadoras dejaran de poder ver qué dominio concreto se solicitaba detrás de una IP compartida. Si una IP aloja tanto webs legales como servicios IPTV de dudosa procedencia, al encender ECH la operadora ya no puede bloquear solo la web “pirata” leyendo el SNI.

En ese escenario solo quedan dos opciones poco elegantes: o se bloquea toda la IP (cargándose por el camino cientos o miles de webs perfectamente legítimas), o no se bloquea nada y esos servicios escapan al filtrado. Ese dilema ha provocado cortes y problemas de acceso para muchas empresas españolas alojadas en Cloudflare cuando ciertas operadoras han optado por el bloqueo masivo de IPs.

El conflicto se ha cebado especialmente con los bloqueos impulsados por LaLiga para frenar las listas IPTV ilegales. Se han documentado casos en los que, al intentar acceder a webs alojadas tras Cloudflare desde redes de determinados operadores, el usuario se encontraba con mensajes de “Contenido bloqueado por requerimiento de la Autoridad Competente”. En algunos casos, bastaba con que el navegador tuviera ECH y DoH activados para que ese mismo dominio pasara a cargar sin problemas, lo que evidencia que los sistemas de filtrado no eran capaces de ver ya el SNI.

Operadoras como Movistar, O2, Orange, DIGI o Vodafone han reaccionado de forma diferente. Algunas han suavizado los bloqueos ante el impacto colateral y la mala imagen; otras los han endurecido, y alguna afirma disponer de sistemas más finos basados en análisis de patrones de tráfico o DPI avanzados, aunque sin dar demasiados detalles públicos.

En medio de todo esto, Cloudflare ha ido afinando su despliegue de ECH. Primero lo ofreció como opción para ciertos sitios, luego lo activó por defecto en toda su red y, ante los problemas de compatibilidad y la elevada tasa de errores de navegación, lo desactivó de nuevo de forma global. Más adelante, ya en 2024, lo ha vuelto a habilitar progresivamente, coincidiendo con un mejor soporte en navegadores y ajustes en la infraestructura.

El resultado es un choque directo entre privacidad y modelos de bloqueo basados en SNI. ECH hace “técnicamente imposible” que la operadora vea qué dominio exacto solicita el usuario, y eso obliga a replantearse las herramientas regulatorias y técnicas para combatir determinados usos ilegales sin destrozar la neutralidad de la red ni arrasar con webs legítimas por el camino.

Cómo activar ECH en los navegadores más usados

La buena noticia es que activar o aprovechar ECH como usuario es cada vez más sencillo, porque los principales navegadores han ido incorporando soporte nativo y, en muchos casos, lo traen ya listo de fábrica.

En Google Chrome:

• ECH está soportado desde Chrome 117. En las versiones iniciales era necesario ir a chrome://flags/#encrypted-client-hello y activar la opción “Enable”.
• En versiones recientes, ECH viene activado por defecto y ni siquiera aparece como flag configurable. El navegador lo usa automáticamente cuando el servidor lo soporta.
• Lo importante es habilitar DNS seguro desde chrome://settings/security, marcando “Usar DNS seguro” y eligiendo un proveedor como Cloudflare, Google, etc.

En Mozilla Firefox:

• Hace falta usar la versión 118 o posterior para tener soporte estable de ECH.
• En about:config, las claves relacionadas con “echconfig” suelen venir ya en “true”, lo que indica que ECH está operativo en el motor del navegador.
• Condición imprescindible: activar DNS over HTTPS (DoH) en Ajustes → Privacidad & Seguridad, en la parte baja, marcando la protección que habilita DoH. Sin DoH, Firefox no emplea ECH aunque esté compilado en el navegador.

En Microsoft Edge y Opera (basados en Chromium) el comportamiento es muy similar a Chrome: soporte nativo desde versiones relativamente recientes y uso transparente si el servidor lo permite, siempre que el DNS seguro esté configurado. Safari, por su parte, ha ido experimentando con ECH pero su soporte es todavía más limitado y requiere activación en opciones avanzadas o experimentales.

En todos los casos, conviene recordar que ECH solo se aprovechará si el servidor o la CDN lo soportan. Si entras en una web alojada en un hosting tradicional sin ECH o una CDN que no lo tenga activado, tu navegador caerá de vuelta en el modelo clásico con SNI visible.

Cómo comprobar si ECH está funcionando en tu conexión

Una cosa es activar opciones y otra comprobar que realmente estén haciendo algo. Para verificar que ECH está activo y funcionando, existen varias herramientas online bastante sencillas.

Cloudflare ofrece una de las pruebas más populares. En su página de diagnóstico de privacidad puedes lanzar un test que revisa, entre otros puntos, si estás usando DNS seguro, DNSSEC, TLS 1.3 y “Secure SNI”. Si este último aparece como correcto, significa que tu navegador está usando ECH cuando se conecta a servicios compatibles de Cloudflare.

Además, Cloudflare dispone de herramientas en modo texto que permiten hacer chequeos desde terminal o scripts automatizados, muy útiles para administradores de sistemas que quieran validar despliegues sin depender de una interfaz web. En esos resultados, el campo SNI suele marcarse como “Encrypted” cuando ECH está activo.

Otras webs de test también muestran el estado de ECH a través de campos como “SSL_ECH_STATUS”, que debería salir como “Success” si la extensión se ha negociado correctamente. Estas páginas suelen revisar la versión de TLS, el uso de HTTP/3/QUIC y otros parámetros avanzados.

Si te encuentras con que una web no carga bien tras activar ECH, siempre queda la opción de deshabilitar temporalmente DoH o las flags experimentales del navegador y comprobar si el problema desaparece. No es lo ideal a nivel de privacidad, pero hoy por hoy aún hay servidores, firewalls y middleboxes que no se llevan del todo bien con ECH.

Impacto en controles parentales, filtros corporativos y rendimiento

ECH mejora la privacidad del usuario, pero también rompe ciertos modelos de filtrado tradicionales. En entornos domésticos o de empresa, muchos administradores se apoyan en sistemas como Pi-hole, AdGuard Home o filtros DNS personalizados para bloquear webs maliciosas, publicidad o contenidos inapropiados como parte de los controles parentales.

Si el navegador usa DoH directamente contra un proveedor externo y además negocia ECH, estos filtros “en la red local” pierden gran parte de su capacidad: ya no ven las consultas DNS ni el SNI. En la práctica, el router o el servidor de filtrado no pueden decidir qué bloquear porque la información clave ya no pasa por ellos o va cifrada.

Por eso, tanto Mozilla como Google han introducido opciones para habilitar o deshabilitar DoH y ECH desde el propio navegador, e incluso admiten listas de excepciones o políticas administradas en entornos corporativos. De este modo, una empresa puede decidir si prioriza la privacidad del empleado o el cumplimiento estricto de sus políticas internas de navegación.

En cuanto al rendimiento, ECH implica un poquito más de trabajo criptográfico. Hay que cifrar y descifrar el ClientHelloInner, manejar claves públicas ECH, etc. En equipos modernos esto supone una sobrecarga casi imperceptible, pero en dispositivos muy antiguos o muy justos de recursos podría añadirse algo de latencia en el establecimiento de la conexión.

La realidad es que TLS 1.3, QUIC y las optimizaciones modernas compensan sobradamente ese pequeño coste extra. TLS 1.3 requiere menos idas y vueltas para establecer la conexión, QUIC reduce la latencia a nivel de transporte y, en general, la navegación termina siendo más rápida que con antiguos TLS 1.2 incluso añadiendo ECH a la ecuación.

Ventajas y desventajas prácticas de activar ECH

Entre las principales ventajas de ECH se pueden destacar varias muy claras:

• Privacidad reforzada frente a operadores y observadores de red: el dominio al que accedes deja de viajar en texto plano dentro del SNI. Los intermediarios ya no pueden monitorizar o perfilar fácilmente a qué webs entras simplemente mirando el handshake TLS.
• Dificulta el bloqueo selectivo de webs: los sistemas que se basan en leer el SNI para aplicar censura o restricciones de acceso dejan de funcionar. Esto obliga a usar métodos más complejos, costosos y menos precisos si se quiere seguir filtrando contenido.
• Compatibilidad con la infraestructura de seguridad existente: ECH no obliga a rediseñar TLS ni a tirar servidores a la basura. Se implementa como una extensión en navegadores, servidores web (Nginx, Apache, etc.) y CDNs. Basta con actualizar software y activar las opciones pertinentes.

Pero también hay desventajas y limitaciones que no conviene ignorar:

• Compatibilidad incompleta: no todos los servidores, librerías TLS y herramientas de seguridad soportan aún ECH. Esto puede provocar fallos de conexión, errores raros o comportamientos extraños mientras la adopción sigue madurando.
• Necesidad de actualizaciones y mantenimiento: para que ECH siga siendo efectivo, hay que mantener actualizados navegadores, servidores, resolutores DNS y CDNs. No es un caso de “lo activo y me olvido”; habrá cambios de claves, ajustes de configuración y nuevas versiones del estándar.
• Mayor carga de procesamiento: aunque sea pequeña, la encriptación adicional del handshake añade trabajo tanto al cliente como al servidor. En entornos de altísimo tráfico o hardware muy limitado, puede ser un factor a tener en cuenta.
• Adopción todavía limitada: aunque gigantes como Cloudflare, Mozilla o Google están empujando fuerte, muchas plataformas y servicios todavía no hablan “ECH nativamente”, lo que reduce su efecto global a corto plazo.

En cualquier caso, para la mayoría de usuarios las ventajas superan con creces los inconvenientes. Si no dependes de controles parentales basados en DNS local ni de filtros corporativos clásicos, activar ECH y DoH suele ser una muy buena idea para ganar en privacidad sin renunciar a la comodidad.

Mirando el panorama completo, ECH es el último gran ladrillo que faltaba en el muro del cifrado web: TLS 1.3 aporta seguridad y velocidad, QUIC acelera las conexiones, DoH y DoT ocultan las consultas DNS y ECH tapa por fin la “ventana” del SNI y del ClientHello. El protocolo TLS llevaba años arrastrando esa filtración de metadatos, y la colaboración de IETF, grandes CDNs y navegadores ha permitido diseñar una solución robusta que, aunque aún está puliéndose, marca claramente el camino hacia un Internet donde cada vez es más difícil husmear en qué webs entras sin romper directamente la conexión o vulnerar la ley.