Si te preocupa la privacidad y la seguridad en Internet, estás de enhorabuena, porque la extensión de seguridad Encrypted Client Hello (ECH) ya es oficial, y el RFC 9849 define en detalle su funcionamiento y todas las implicaciones que ello conlleva. Es compatible con el protocolo TLS 1.3 y posteriores, así como DTLS 1.3 y posteriores. Esta extensión de seguridad mejora significativamente la privacidad a la hora de navegar por Internet, evitando que los operadores puedan interceptar las conexiones TLS y «leer» qué dominio estamos solicitando. Esto es una clara victoria para Internet en general, ya que añade una capa de privacidad muy importante, y es una gran derrota para aquellos operadores que espían a sus clientes, o para las empresas que les gusta atentar contra la privacidad en Internet.
Aunque las conexiones TLS cifran la mayor parte del protocolo de enlace, y todos los datos, incluyendo el certificado del servidor, lo cierto es que hay una extensión de texto plano llamada SNI (Server Name Indication) que está en texto claro, lo que filtra el dominio de destino de una conexión determinada. Esta es la información más delicada que el protocolo TLS 1.3 no cifraba, hasta que desarrollaron ECH. Ahora los operadores no podrán «ver» qué web o dominio estamos solicitando. El SNI existe por una razón técnica, y es que los servidores web necesitan saber qué certificado SSL/TLS presentar cuando hay varios sitios web en el mismo servidor, como lo que ocurre cuando una web usa un CDN (direcciones IP compartidas con cientos de webs).
El RFC 9849 supone un antes y un después
Que el Encrypted Client Hello (ECH) tenga el RFC 9849 significa que es oficial, hasta ahora estaba en «borrador» o también conocido como «draft», es decir, podría sufrir modificaciones a medida que se utilice. Este procedimiento es totalmente normal, a medida que se desarrolla un protocolo, se pueden encontrar problemas a la hora de implementarlo o en el propio funcionamiento, y es necesario meses e incluso años hasta que está totalmente terminado y listo para «pasar a producción». El documento del RFC publicado oficialmente por la IETF (Internet Engineering Task Force) el 5 de marzo de 2026, especifica formalmente esta extensión, que permitirá a los clientes cifrar el «ClientHello» al servidor TLS, protegiendo el SNI y otros campos potencialmente confidenciales, como el ALPN (Application-Layer Protocol Negotiation). Todo esto está orientado a proporcionar la máxima privacidad posible en todas las comunicaciones.
El funcionamiento de ECH es como enviar una carta en dos sobres: el sobre exterior muestra el destino genérico (dirección IP), mientras que el dominio real permanece en el sobre interior y oculto, de tal forma que un operador solamente podrá ver el sobre exterior, pero no revela nada sobre el destino real, ni tampoco su contenido. Esto elimina cualquier filtrado de SNI, en caso de querer filtrado, se tendrá que hacer donde se descifra el tráfico, como en los navegadores, sistemas operativos o en el servidor web, pero no en la comunicación cifrada punto a punto.
Esta extensión ECH que ya es oficial, por sí sola no es capaz de proteger la identidad del servidor. El dominio de destino puede ser visible a través de las consultas DNS de los clientes, los cuales están en texto plano, e incluso si usamos direcciones IP de servidores visibles. Al usar DNS cifrado, se oculta las búsquedas DNS y ningún operador podrá descifrar esta información, hay que tener en cuenta que muchos servidores alojan múltiples dominios bajo una misma dirección IP, como los principales CDN. Sin embargo, si utilizas los siguientes protocolos para proteger las consultas DNS, sí tendrás privacidad:
- DNS over TLS: este protocolo se encarga de cifrar las consultas y respuestas DNS, haciendo uso de TLS 1.3 para ello. Los principales servidores DNS como los de Google o Cloudflare lo soportan.
- DNS over HTTPS: este protocolo generalmente está en los navegadores web, como Chrome, y hace uso de una conexión HTTPS (que usa realmente TLS por debajo). También es compatible con los servidores DNS de Google, Cloudflare y muchos otros proveedores.
- DNS over QUIC: este protocolo hace uso de QUIC para las comunicaciones, así que todas las consultas y respuestas también estarán protegidas por cifrado.
Os recomendamos acceder a nuestro listado de mejores servidores DNS con DNS over TLS y DNS over HTTPS, donde encontraréis un listado de cuáles son, y también la configuración que debes indicar en el cliente.
Aunque es compatible con TLS 1.3 y DTLS 1.3, es crítico que tanto los navegadores web como los servidores web y CDN, soporten este protocolo. A fecha de marzo de 2026, el estado de implementación es la siguiente:
- Navegadores web: Chrome lo tiene activado por defecto desde la versión 129, Firefox lo tiene activo desde la versión 118 y requiere DoH, Safari lo tiene en fase beta. Otros navegadores también lo tienen soportado.
- CDN: Cloudflare dispone de implementación completa, otros CDN como Akamai lo están desplegando.
- Sistemas operativos: todos lo soportan, incluyendo Android y también iOS.
Hoy en día ya se usa ECH aunque no lo hayamos notado, sobre todo si tu web está en el CDN de Cloudflare. Puedes comprobar si tu navegador lo soporta en la comprobación de seguridad de Cloudflare.
Gran derrota para los que quieren espiar el tráfico
La estandarización de ECH supone un obstáculo técnico muy importante para los sistemas de bloqueo basados en la inspección del SNI. Según Cloudflare, la implementación combinada de ECH y DNS cifrado (DoH o DoT) puede reducir hasta en un 89% la efectividad de estos bloqueos. Por ejemplo, en pruebas realizadas por la Electronic Frontier Foundation (EFF) en enero de 2026, se demostró que los operadores no pudieron identificar el 92% de los dominios de destino cuando ECH estaba activo.
Estoes un gran revés para operadores que interceptan la conexión HTTPS para realizar bloqueos, así como también para los países que aplican censura a sus ciudadanos, porque ahora no podrán saber a qué webs o dominios se conectan, ya que todo está cifrado y no hay ningún tipo de fuga de datos. Cuando se realiza una conexión a una web o servicio, podíamos tener «fugas» de datos, que podrían afectar a nuestra privacidad, pero estas han sido poco a poco solucionadas:
- Resolución DNS: el protocolo original enviaba todo sin cifrado, ahora tenemos DNS over TLS, DNS over HTTPS e incluso DNS over QUIC, por lo que está totalmente cifrado.
- Certificado SSL: en las primeras versiones de TLS el certificado SSL se enviaba en texto plano, así que se podría saber a qué web se ha accedido. Con el protocolo TLS 1.3 desde 2018 esto no es posible, ya que el certificado va cifrado durante la conexión.
- Fuga de datos por el SNI: hasta ahora, incluyendo también TLS 1.3, el campo SNI estaba sin cifrar para que lo reciba el servidor. Si se usa TLS 1.3 o DTLS 1.3 y ECH, ahora está cifrado.
Lo único que podría ser visible es la dirección IP pública del destino, la cual normalmente está compartida con cientos de webs, ya que se suelen usar CDN (redes de distribución de contenido) como Cloudflare. Lo cierto es que en España estamos viviendo bloqueos de las IPs de Cloudflare, donde cientos de sitios webs legítimos son bloqueados porque algunos emiten fútbol de forma ilegal. Es lo único que pueden hacer: bloquear IPs y ocasionar daños colaterales, porque todo el tráfico va cifrado punto a punto.