Durante veinte años, los firewalls y servidores proxy de red se han apoyado en un campo no cifrado para saber hacia dónde se dirigía el tráfico cifrado: la indicación del nombre del servidor (SNI), el nombre de host que un cliente anuncia en el primer mensaje de un protocolo de enlace TLS. DNS sobre HTTPS (DoH, RFC 8484) ya ocultó la búsqueda de DNS que precede a una conexión. Cliente cifrado Hola, ahora publicado como RFC 9849, oculta el SNI. Juntos eliminan las dos señales sobre las que se construyó la mayor parte del filtrado de salida.
Cómo funciona ECH: un Cliente interno y externo Hola
Con ECH, el cliente crea dos mensajes ClientHello. El interno lleva el destino real y los parámetros confidenciales y está cifrado con HPKE en una clave pública que el servidor publicó con anticipación. El externo, enviado sin cifrar, lleva un nombre público compartido, normalmente el nombre de la interfaz del proveedor, por lo que un observador sólo se entera de que el cliente está hablando con ese proveedor (RFC 9849; Explicador de Cloudflare).
TLS ClientHello (outer, cleartext)
server_name: cloudflare-ech.com <- shared public name
encrypted_client_hello: <HPKE ciphertext> <- real hostname is inside
De dónde viene la clave: el registro DNS HTTPS
El cliente necesita la clave pública ECH del servidor antes del protocolo de enlace. Lo obtiene de DNS, en el registro de recursos HTTPS (tipo 65, RFC 9460), cuyo parámetro ech lleva una ECHConfigList. Consultamos uno real. El dig enviado con macOS no conoce el registro por nombre, así que solicítelo por número:
dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
…0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.comSi esa consulta de DNS viaja a través de DoH, un observador de la red no ve la búsqueda ni, con ECH, el nombre de host en el protocolo de enlace. Esa es la combinación de la que trata este artículo.
El uso de ECH depende del cliente
ECH no es algo que active una red; cada cliente decide. Los navegadores han incluido soporte (Estado de la plataforma Chrome), generalmente vinculado al uso de DNS cifrado. Mucho software no lo utiliza en absoluto. El punto final de seguimiento de Cloudflare informa lo que recibió, y el curl integrado en macOS aún envía el nombre de host sin cifrar:
curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintextAsí que el panorama realista actual es una mezcla: los navegadores ocultan cada vez más el nombre del host, muchos otros programas no lo hacen, y el software escrito para evadir el monitoreo puede optar por usar ECH y DoH deliberadamente.
Qué pierde un cortafuegos perimetral y qué conserva
| Señal | TLS + DNS simple | ECH + Departamento de Salud |
|---|---|---|
| Búsqueda de DNS (qué nombre) | Visible en el puerto 53 | Oculto dentro de HTTPS para el solucionador |
| SNI (qué nombre de host) | Visible | Sólo el nombre público compartido |
| IP y puerto de destino | Visible | Aún visible |
| ¿Qué dispositivo en la LAN? | Visible | Aún visible |
| ¿Qué programa en el dispositivo? | No visible | No visible |
El resumen honesto es que el filtrado basado en nombres de host en el borde deja de funcionar para el tráfico ECH, mientras que los controles basados en IP no. Una red aún puede rechazar conexiones a solucionadores DoH conocidos, lo que en la práctica también impide que los navegadores obtengan claves ECH a través de DNS cifrado, y aún puede bloquear rangos de direcciones. Lo que ya no puede hacer es diferenciar dos sitios detrás del mismo proveedor, o permitir uno y bloquear el otro, sin romper TLS en las formas en que ECH está diseñado para detectar.
La visibilidad se traslada al punto final
El único lugar donde el nombre de host nunca se oculta es la máquina que realiza la conexión: el programa lo solicitó por su nombre. Es por eso que ECH desplaza el control de salida hacia el punto final. Un firewall basado en host no necesita leer el protocolo de enlace en absoluto; ve qué proceso abrió la conexión, a qué dirección y, cuándo el programa resolvió un nombre, qué nombre, antes de que salgan los bytes cifrados. También ve lo único que un dispositivo de red nunca pudo ver, incluso antes de ECH: qué aplicación en la máquina está hablando.
- Decida por aplicación, no por nombre de host: un navegador, un cliente de sincronización y un binario desconocido obtienen reglas diferentes.
- Trate un programa que inicia su propio DoH en un solucionador que el sistema no configuró como una señal que vale la pena ver.
- Mantenga las listas de bloqueo basadas en IP en el borde; todavía funcionan y no cuestan nada.
Dónde entran FireAI y HisnLabs
ECH hides the hostname from the network, not from the machine making the connection: an on-device firewall such as FireAI still sees which process is connecting and where, and asks before an app it does not know goes online.
FireAI es el producto de HisnLabs: un firewall con IA que corre directamente en tu Mac. Te muestra, en lenguaje claro, cada conexión que hacen tus aplicaciones y te deja decidir qué sale de tu Mac; su IA funciona de manera local, así que tu tráfico nunca se envía a nosotros ni a nadie más. El equipo de investigación en seguridad de HisnLabs es el que mantiene esas decisiones confiables: cataloga qué dominios son simple telemetría y cuáles un servicio real, rastrea el país y la red detrás de cada conexión, y entrena el modelo local (la función Autopilot) con patrones de tráfico reales, sin que nada de eso salga de tu Mac.
Puedes leer las decisiones técnicas detrás de FireAI, o probarlo durante 17 días, en FireAI, de HisnLabs.