ECH activado, pero SNI sigue visible: cómo verificar el cifrado del nombre del sitio en 2026

```html

ECH — la encriptación del nombre del sitio en el apretón de manos TLS — obtuvo el estatus de estándar en marzo de 2026 (RFC 9849, Standards Track). Firefox y Chrome lo incluyen por defecto, Cloudflare distribuye claves a casi todos sus clientes. Sin embargo, para la mayoría de los usuarios, ECH no funciona silenciosamente: el navegador recurre a un apretón de manos normal, y el proveedor todavía puede ver a dónde vas.

A continuación, se muestra cómo verificar en un minuto si el SNI está encriptado en tu caso, por qué a menudo no se encripta, y en qué escenarios ECH es fundamentalmente inútil (spoiler: para la detección anti y el scraping — casi siempre).

Qué es lo que oculta ECH — y qué no oculta

En el TLS 1.3 normal, todo está encriptado, excepto el primer mensaje — ClientHello. En él, el campo SNI con el dominio al que te conectas está en texto claro. La mayoría de los sistemas de filtrado funcionan con el SNI: la IP es la misma para miles de sitios detrás de un CDN, pero el dominio es visible.

ECH divide ClientHello en dos:

• ClientHelloOuter — se envía en claro, pero con un dominio de envoltura falso. En Cloudflare, esto es cloudflare-ech.com.
• ClientHelloInner — el verdadero dominio, ALPN y la lista de cifrados, encriptados con la clave pública del servidor.

La clave para esta encriptación es obtenida por el navegador no de la conexión, sino de DNS — de la entrada HTTPS (tipo 65), parámetro ech=. De aquí surge la principal consecuencia que se olvida: ECH no es posible sin DNS encriptado. Si la consulta DNS se envía en UDP/53 sin encriptar, el observador simplemente ve el nombre del dominio antes del apretón de manos, y el resolutor filtrante puede eliminar el parámetro ech= de la respuesta — y ECH no se activará.

Lo que ECH no oculta en absoluto:

• La dirección IP de destino — siempre es visible;
• el volumen y los tiempos del tráfico;
• la huella TLS del cliente (JA3/JA4) — el conjunto de cifrados y extensiones permanece en la parte abierta;
• tú para el propio sitio — el servidor, después de la desencriptación, ve todo lo que veía antes.

El último punto es la razón por la que ECH no tiene relación con el elusión de sistemas anti-bot. Cloudflare, DataDome y Akamai operan del lado del servidor: no les importa si el SNI fue encriptado en el camino. Si la tarea es no ser detectado durante la automatización, opera una capa completamente diferente: la suplantación de la huella TLS, de la que discutimos en el material sobre elusión de la huella JA4 a través de curl-cffi.

Verificación #1: ¿funciona ECH ahora mismo (10 segundos)?

Abre en el navegador:

https://crypto.cloudflare.com/cdn-cgi/trace

Busca la línea sni=. Pueden haber dos opciones:

• sni=encrypted — ECH está funcionando, el nombre del sitio está oculto en el camino;
• sni=plaintext — ECH no se aplicó, el dominio se envió en texto claro.

La misma dirección a través de curl en la terminal siempre devolverá sni=plaintext — el curl normal no sabe ECH, y esto es una buena referencia: así se ve "apagado".

Verificación #2: ¿tiene el dominio una clave ECH (dig, sin navegador)?

ECH se activará solo si el dominio tiene una entrada DNS HTTPS con el parámetro ech=. Veamos la entrada cruda:

dig +short TYPE65 example.com @1.1.1.1

En la respuesta, busca los bytes FE0D — este es el código de extensión ECH, seguido por ECHConfig. Un ejemplo práctico: en el momento de preparar este material, tanto crypto.cloudflare.com como nuestro dominio proxycove.com tienen una entrada de 133–136 bytes que contiene tanto FE0D como el nombre falso cloudflare-ech.com en formato hexadecimal. Pero el propio cloudflare.com tiene una entrada corta, de 61 bytes: solo ALPN y sugerencias de IP, sin ECH. Esto significa que incluso dentro de la infraestructura de Cloudflare, ECH no se distribuye a todos los dominios por igual — no te sorprendas si un sitio específico no lo tiene.

Si dig se queja de ignoring invalid type HTTPS — tienes una versión antigua de la herramienta, usa la forma numérica TYPE65, como en el comando anterior.

Por qué ECH no se activa para ti: cinco razones en orden

1. DNS encriptado está desactivado. Sin DoH, el navegador no obtendrá ECHConfig de manera confiable. En Firefox: Configuración → Privacidad → DNS a través de HTTPS en modo "Mejorado" o "Máxima protección". En Chrome: Configuración → Seguridad → Usar DNS seguro.
2. El dominio simplemente no tiene una entrada HTTPS con ech= — se verifica con el comando del bloque anterior. Aquí no depende de ti, es una decisión del propietario del sitio y su CDN.
3. El resolutor elimina el parámetro. Los servidores DNS corporativos y de proveedores suelen entregar entradas HTTPS sin ech=. Verifica solicitando la entrada directamente a un resolutor público (@1.1.1.1) y comparando con la respuesta del sistema.
4. Las banderas del navegador han sido restablecidas. En Firefox, las configuraciones network.dns.echconfig.enabled y network.dns.http3_echconfig.enabled en about:config — ambas deben ser true.
5. Hay un gateway de inspección en medio. Esto se aborda en la siguiente sección.

Cómo rompen ECH: dos esquemas diferentes

Firewall corporativo: degradación silenciosa

Los proveedores de equipos de red han lanzado recetas listas contra ECH — no están dispuestos a perder visibilidad del tráfico. Cisco, por ejemplo, desde la base de aplicaciones VDB 416 (octubre de 2025) define "ECH Servers" como una aplicación separada y ofrece dos enfoques: interceptar la conexión recreando el certificado y eliminar la extensión encrypted_client_hello de ClientHello, o actuar de manera más sencilla — a nivel DNS: bloquear entradas HTTPS para dominios ECH, cortar DoH/DoT/DoQ, bloquear el dominio canario use-application-dns.net y permitir DNS solo en servidores corporativos.

La astucia del primer esquema es que no parece una bloqueo. El servidor, al no ver la extensión ECH, responde como de costumbre, el cliente considera que ECH está "desactivado de forma segura" y se reconecta ya con SNI en claro. El sitio se abre, no hay errores — y el nombre del dominio se registra en el log del gateway.

Nivel estatal: la conexión simplemente muere

El ejemplo ruso es indicativo por su precisión. Desde el 5 de noviembre de 2024, la filtración se activa solo cuando coinciden dos características al mismo tiempo: SNI con el valor cloudflare-ech.com más la presencia de la extensión ECH. Por separado, ninguno de los dos activa el bloqueo — ECH pasa a otros dominios de envoltura (por ejemplo, los de prueba defo.ie o tls-ech.dev). Esto se implementa no mediante el restablecimiento de la conexión, sino mediante eliminación silenciosa de paquetes: la página se queda colgada y se desconecta por timeout. Se ven afectados tanto HTTP/2 basado en TCP como QUIC/HTTP-3. Roskomnadzor declaró en ese momento que el uso de TLS ECH viola la legislación rusa y recomendó a los propietarios de sitios que se alejaran de la CDN Cloudflare — miles de recursos completamente legales cayeron bajo el filtro de una vez, incluidos en la misma envoltura.

Firefox, en tal situación, aproximadamente un minuto después intenta nuevamente sin ECH — es decir, al final entrega SNI en claro, lo que la especificación no recomienda hacer precisamente por razones de seguridad. Si observas "el sitio se carga exactamente un minuto, luego se abre" — es casi seguro que es eso.

Cuándo ECH no es suficiente y qué usar en su lugar

Desglosemos las tareas honestamente.

• Privacidad del proveedor en internet doméstico. ECH + DoH — una mejora buena y gratuita. Funciona donde no lo cortan.
• Elusión de filtración. ECH no fue diseñado para esto, y la práctica lo ha confirmado: tan pronto como comenzó a interferir con los filtros, aprendieron a identificarlo y silenciarlo por completo. No se puede confiar en él como herramienta de acceso.
• Scraping, multi-cuentas, automatización. ECH no ofrece nada: el sitio objetivo ve tu IP, tu JA4 y tu historial de solicitudes. Solo importan la fuente de IP y la calidad de la huella.

En todos los casos donde ECH no puede manejar, opera una capa más burda pero confiable: llevar el apretón de manos TLS fuera de la red observable. Cuando el tráfico pasa a través de un proxy, el observador en tu canal solo ve la conexión con el nodo proxy — no hay SNI del sitio objetivo en absoluto, independientemente de si el dominio soporta ECH o no. Para el acceso diario y el trabajo con servicios sensibles a la reputación de IP, se pueden usar proxies residenciales; para aplicaciones móviles y plataformas que son especialmente exigentes con el tipo de conexión, se pueden usar móviles.

Y no olvides sobre DNS: un proxy en el navegador no garantiza que los nombres se resuelvan a través de él. La fuga de DNS revela exactamente lo que intentabas ocultar — cómo verificar esto se explicó en una instrucción separada sobre la verificación de proxies por fuga de DNS. Si la cuestión es un análisis profundo del tráfico en el canal, no debes mirar ECH, sino el propio transporte.

Lista de verificación corta

1. Abre crypto.cloudflare.com/cdn-cgi/trace y mira la línea sni=.
2. Si plaintext — activa DoH en el navegador y verifica de nuevo.
3. No funcionó — verifica la existencia de la clave en el dominio: dig +short TYPE65 dominio @1.1.1.1, busca FE0D.
4. La clave existe, pero ECH no se aplica — compara la respuesta de los resolutores públicos y del sistema: probablemente, el parámetro se corta en el camino.
5. La conexión se cuelga durante un minuto y se abre — ECH está siendo silenciado a nivel de red; ECH no ayudará aquí, se necesita otro transporte.

Conclusión

ECH es la última brecha cuidadosamente cerrada en la privacidad de TLS, y no un medio de acceso y mucho menos una herramienta para la automatización. Depende de DNS encriptado, se desactiva en medio sin un solo error en la pantalla y se silencia por completo donde comienza a interferir. Vale la pena verificarlo — los dos comandos anteriores toman un minuto. Pero construir sobre él para eludir bloqueos o protegerse contra sistemas anti-bot es inútil: estas tareas se resuelven a nivel de quién ve la IP y la huella TLS en el servidor del otro lado.