Encrypted Client Hello: qué dominio oculta ECH y qué sigue viendo la red

El candado de HTTPS no cuenta toda la historia de una conexión. Antes de pedir una página, el navegador necesita establecer una sesión cifrada con el servidor. En el saludo inicial de TLS puede aparecer el nombre del servidor que desea visitar, aun cuando el contenido posterior viaje cifrado. Encrypted Client Hello (ECH) protege esa información del saludo frente a observadores de la red cuando los extremos lo admiten y la negociación se completa. El estándar RFC 9849 se publicó en marzo de 2026. Su función es concreta: no oculta la dirección IP del servidor, no impide que el sitio reconozca al visitante y no convierte el navegador en una red de anonimato.

Qué nombre podía verse antes de abrir la página

Un servidor puede atender varios dominios en una misma dirección IP. Para que el servidor presente la configuración adecuada, el cliente suele incluir el nombre deseado en la extensión SNI del mensaje inicial ClientHello. Sin ECH, ese nombre puede viajar en claro en el saludo de TLS 1.3. Es el nombre de servidor, no toda la dirección escrita en la barra del navegador. Por ejemplo, en una URL ficticia con el camino /citas/consulta, ese camino no se envía como SNI. En HTTPS la petición HTTP que lo incluye se transmite dentro de la conexión cifrada. Confundir dominio y ruta exageraría qué información quedaba visible antes de ECH.

ECH utiliza una configuración que incluye una clave pública y otros parámetros. El cliente prepara un saludo interior con el nombre real y las extensiones que deben protegerse. Lo cifra para el servicio que puede descifrarlo y lo incluye en un saludo exterior transmisible que, para el observador, puede mostrar un nombre público compartido. El servidor frontal que tiene la configuración correspondiente procesa el interior y negocia conforme al protocolo. El nombre exterior y la IP siguen revelando algo sobre el proveedor. Lo que se intenta evitar es que el saludo permita distinguir directamente qué dominio del grupo se visitó.

La pregunta anterior a TLS pasa por el DNS

Antes de conectar, el cliente tiene que averiguar cómo contactar con el servicio y qué configuración de ECH utilizar. El RFC 9848 define cómo obtenerla mediante registros de servicio DNS, en particular el parámetro ech de registros HTTPS o SVCB. Estos registros DNS no son lo mismo que descargar una página HTTPS: aquí se consulta información de conexión publicada para un nombre. Un registro de tipo A o AAAA puede entregar una dirección IP sin comunicar la configuración ECH. Y una respuesta de tipo HTTPS puede existir sin incluir el parámetro ech.

Si el navegador pregunta en DNS sin cifrar por el nombre exacto y un observador local puede leer esa consulta, proteger después el SNI no borra lo que ya se reveló. Transportar la consulta mediante DNS sobre HTTPS o DNS sobre TLS puede evitar esa lectura en el trayecto al resolvedor, pero el resolvedor que recibe la consulta sigue siendo una parte de confianza. DNSSEC, por su parte, sirve para autenticar datos DNS, no para ocultar su contenido al observador. Las opciones del navegador, del sistema y de una red administrada importan; no basta con ver «HTTPS» en la dirección de la página para deducir cómo se hizo la resolución.

Una comprobación pública con dos nombres del mismo proveedor

El 7 de noviembre de 2026, a las 20:28 UTC, Gaia hizo cuatro consultas de solo lectura: registros HTTPS de crypto.cloudflare.com y www.cloudflare.com a través de los resolvedores públicos de Google y Cloudflare. En ambos resolvedores el primero devolvió un registro tipo 65 con el parámetro ech. Para el segundo ambos devolvieron un registro del mismo tipo sin ese parámetro. Se puede repetir la consulta en la API pública de Google para el primer nombre y el segundo. Los registros pueden rotar y las respuestas pueden variar con el tiempo o el resolvedor.

La prueba documenta anuncios DNS, no el resultado de un saludo TLS. No enviamos un ClientHello de prueba ni comprobamos si un navegador aceptó ECH en ninguno de los dos destinos. Por eso la primera fila no dice «cifrado verificado en el navegador» y la segunda no permite afirmar que ECH sea imposible en todos los entornos. Las dos filas sí demuestran que «el proveedor tiene ECH» y «este nombre publica configuración ECH en esta consulta» son afirmaciones distintas. Es un límite importante cuando alguien intenta diagnosticar todo un dominio con el resultado de otro nombre alojado en la misma red.

Hay un detalle adicional que sí puede comprobarse sin iniciar una sesión TLS. Al decodificar el parámetro de la respuesta para crypto.cloudflare.com, la lista de configuración contenía el nombre público cloudflare-ech.com. Ese nombre no es el que consultamos ni una nueva URL que deba abrir el lector. Es un dato que el servicio publica para construir el saludo exterior en esa configuración. Tampoco se publica la clave privada con la que el servicio procesa el saludo interior. Que una clave pública esté disponible para los clientes es el propósito de la distribución; no permite al observador descifrar lo que se envía al servidor.

Si alguien repite la consulta días después puede ver una clave diferente o una respuesta distinta. Una coincidencia entre los dos resolvedores que probamos ayuda a describir ese instante, pero no representa todos los cachés, todas las redes o todas las políticas de cliente. Para investigar una diferencia concreta conviene conservar pregunta y respuesta, momento UTC y nombre exacto, y comprobar si la información ha caducado antes de sacar conclusiones. Si solo se dispone de la dirección IP, queda sin responder la pregunta sobre la configuración ECH; si solo se dispone del parámetro DNS, sigue faltando la negociación.

Qué seguiría viendo cada parte

Un observador en el trayecto ve al menos las direcciones IP necesarias para entregar el tráfico, además de datos como tamaños y tiempos de los paquetes. Puede identificar al proveedor del servicio frontal y aprovechar otras pistas para inferir un destino. Si una IP sirve un solo sitio conocido, ocultar el SNI aporta menos incertidumbre que cuando varios nombres comparten infraestructura y configuración. RFC 9848 explica esta limitación mediante el conjunto de anonimato: incluso en una implantación ideal, el nombre se confunde con otros nombres compatibles de ese conjunto, no con cualquier sitio de Internet.

El servicio que termina o gestiona el ECH correspondiente sí debe procesar información suficiente para encaminar la conexión. El sitio final conoce las solicitudes que recibe; si el visitante inicia sesión, puede asociarlas a esa cuenta. ECH tampoco elimina cookies, historial local ni la información que el usuario decide enviar. Una red corporativa que controla el equipo puede observar datos en otros puntos conforme a sus políticas. Y la página visitada puede cargar recursos de otros dominios, cada uno con su propia resolución y negociación. Que una conexión esté protegida no convierte automáticamente a todas las conexiones de la misma página en equivalentes.

El ejemplo más útil para un lector quizá sea una red wifi compartida. Si la consulta DNS y el saludo están adecuadamente protegidos, al observador local le resulta más difícil leer el nombre exacto por esos canales. Eso no significa que no vea actividad, que el resolvedor no conozca la consulta ni que el navegador o el servidor dejen de saber qué sitio se abrió. La mejora está en reducir la exposición de un dato a un observador concreto. Para decidir si satisface una necesidad de privacidad hay que empezar por identificar frente a quién se quiere proteger qué dato.

Qué hace falta para probar una negociación real

El cliente debe implementar ECH y utilizar una configuración válida para un servidor que pueda aceptarla. La documentación de Firefox explica el papel del navegador y de la configuración DNS; la documentación de Cloudflare describe su funcionamiento concreto en el borde de esa red. Son ejemplos de implementación, no reglas universales para cualquier navegador o servidor. Para una comprobación técnica hay que registrar cliente, versión, nombre exacto, hora, resolvedor y resultado de aceptación. El simple hecho de que el navegador cargue la página solo prueba que consiguió una conexión utilizable.

La propia extensión puede aparecer con datos de relleno de compatibilidad cuando no se usa una configuración real. Así los intermediarios no suponen que todos los saludos tienen una forma fija. Por tanto, encontrar el nombre de la extensión en una captura tampoco demuestra automáticamente que se aceptó un ClientHello interior real. Cuando se trabaja en un dominio administrado, resulta más preciso contrastar el anuncio DNS con información de negociación del cliente o del servidor y comprobar la autenticación del destino. Un rechazo o una configuración antigua tiene procesos de recuperación que RFC 9849 define; no es correcto resumirlos como «siempre reintenta en claro».

Cuatro fallos de interpretación frecuentes

El primero es creer que DNS cifrado ya oculta todo lo que revelaba el saludo. Protege la consulta frente a determinados observadores, pero no cifra automáticamente el SNI de una conexión sin ECH. El segundo es creer que ECH cifra por primera vez el texto de una página HTTPS: esa protección de la petición y la respuesta ya era una función de TLS. El tercero es identificar un proveedor compartido con un dominio concreto. Ver infraestructura de una red no permite por sí solo distinguir el sitio exacto, aunque otras pistas puedan favorecer una inferencia. El cuarto es presentar una protección de metadatos como anonimato personal. Un inicio de sesión sigue identificando la cuenta ante el servicio.

Para quien administra un sitio, la verificación empieza por los nombres realmente usados, incluidos subdominios que terminan en proveedores diferentes. Conviene anotar dónde se publica la configuración, quién posee la clave del servicio frontal y qué clientes se probaron. Mantener un listado por nombre y proveedor permite detectar que el dominio principal y una API delegada tienen configuraciones diferentes, aunque formen parte del mismo servicio para el visitante. Si se cambia de proveedor, revisar el anuncio DNS evita conservar datos que ya no corresponden al receptor. La rotación y la política de recuperación dependen del despliegue; una guía general no sustituye las instrucciones del proveedor ni aconseja desactivar comprobaciones de certificados. Para el visitante, el beneficio más tangible sigue siendo sencillo: uno de los nombres que antes podían leerse en el camino deja de estar expuesto de esa forma cuando toda la negociación se realiza como se espera.

Fuentes y agradecimientos

Agradecemos al IETF los RFC 9849 y 9848, a Mozilla y Cloudflare la documentación de sus implementaciones. La consulta DNS y los gráficos son de Gaia. Su alcance se limita a los dos nombres y a las respuestas fechadas que se describen.