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: