# Hola del cliente cifrado y DoH: lo que los firewalls perimetrales ya no pueden ver

> ECH (RFC 9849) oculta el nombre de host real en el protocolo de enlace TLS y DoH oculta la búsqueda de DNS. Lo que eso le quita a los firewalls de red, lo que no le quita y hacia dónde se mueve la visibilidad.

HisnLabs Security & Research Team · Published 2026-09-25
Canonical: https://hisnlabs.com/es/blog/encrypted-client-hello-ech-doh-blind-perimeter-firewalls

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](https://www.rfc-editor.org/rfc/rfc8484.html)) ya ocultó la búsqueda de DNS que precede a una conexión. Cliente cifrado Hola, ahora publicado como [RFC 9849](https://www.rfc-editor.org/rfc/rfc9849.html), 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](https://www.rfc-editor.org/rfc/rfc9849.html); [Explicador de Cloudflare](https://blog.cloudflare.com/encrypted-client-hello/)).

*Lo que ve un observador de la red (ilustrativo)*

```text
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](https://www.rfc-editor.org/rfc/rfc9460.html)), 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:

*Terminal, macOS 26.7, 25 de septiembre de 2026*

```console
$ 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.com
```

Si 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](https://chromestatus.com/feature/6196703843581952)), 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:

```console
$ curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext
```

Así 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 |

*En la interfaz de un proveedor compartido, la IP de destino a menudo identifica al proveedor, no al sitio.*

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.

> **Warning:** Las afirmaciones de que ECH hace que el tráfico sea “irrastreable” o que el filtrado perimetral sea “obsoleto” van demasiado lejos: las IP, la sincronización, los volúmenes y el dispositivo aún son visibles. Lo que se pierde es el nombre del host y, con él, la palanca política más sencilla.

## 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.

## El papel de FireAI y de 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 propio producto de HisnLabs: un cortafuegos con IA integrada para Mac. Muestra, en lenguaje claro, cada conexión que hacen tus aplicaciones y te deja decidir qué sale de tu Mac; su IA funciona en el propio equipo, así que tu tráfico nunca se envía a HisnLabs ni a nadie más. El equipo de investigación en seguridad de HisnLabs es quien mantiene esas decisiones fiables: cataloga qué dominios son simple telemetría frente a un servicio real, sigue el país y la red detrás de una conexión, y entrena el modelo local (la función FireAI Pilot) con tráfico real, sin que nada salga de tu Mac.

Puedes leer las decisiones técnicas detrás de esto, o probar FireAI durante 17 días, en [FireAI, de HisnLabs](https://hisnlabs.com/fireai/es/download).

## Sources

- [RFC 9849: TLS Encrypted Client Hello](https://www.rfc-editor.org/rfc/rfc9849.html)
- [RFC 9460: SVCB and HTTPS DNS resource records](https://www.rfc-editor.org/rfc/rfc9460.html)
- [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484.html)
- [Cloudflare: Good-bye ESNI, hello ECH!](https://blog.cloudflare.com/encrypted-client-hello/)
- [Chrome Platform Status: Encrypted Client Hello](https://chromestatus.com/feature/6196703843581952)