Resumen

  • ECH encierra el ClientHelloInner privado dentro de un ClientHelloOuter público y protege el SNI y otros parámetros sensibles frente a la observación ordinaria del camino.
  • El resultado exige coordinación entre la zona DNS, el cliente, el frontal que guarda la clave y el origen que confirma la negociación.
  • No oculta por sí solo la consulta DNS, la dirección IP ni todas las señales laterales; un registro con ech es una instrucción, no una prueba de éxito.

Dos saludos para una sola conexión

La extensión server_name nació para resolver un problema práctico: varios servicios podían compartir dirección y el cliente debía indicar cuál quería. RFC 6066 colocó el nombre en una extensión. RFC 8446 mantuvo ClientHello como primer mensaje de TLS 1.3. Ese orden dejaba el nombre disponible antes de que el resto del intercambio quedara cifrado.

RFC 9849, estándar IETF de marzo de 2026, crea un saludo interno con el nombre verdadero y un saludo externo con valores públicos. El cliente cifra el primero mediante HPKE y una clave de ECHConfig; el segundo transporta el bloque sellado en la extensión encrypted_client_hello.

El frontal puede aceptar la oferta, abrir el mensaje y enviarlo al origen correcto. Si no puede abrirlo, trabaja con el saludo externo y puede devolver configuraciones vigentes. El cliente comprueba qué ocurrió. Cuando ofreció ECH y este fue rechazado, no utiliza esa conexión para datos de aplicación: reintenta con información nueva en vez de confundir rechazo con privacidad.

El frontal no es un simple proxy opaco

En modo compartido, frontal y terminador TLS son el mismo sistema. En modo dividido, el frontal descifra el saludo interno y lo remite a un backend separado que termina TLS. La arquitectura permite encaminar sin entregar al frontal el contenido de aplicación, pero sí le confía el nombre necesario para elegir destino.

El reparto de autoridad es claro. El DNS publica la configuración. El cliente decide ofrecerla. El frontal conserva la clave privada y los identificadores aún presentes en cachés. El backend confirma la aceptación vinculada a la transcripción. Una inconsistencia entre esos cuatro planos puede romper la propiedad aunque cada componente pase su prueba aislada.

Las claves antiguas no desaparecen en el instante de una rotación: los TTL y otras cachés siguen presentándolas. Conservar demasiadas aumenta el trabajo de descifrado de prueba; conservar pocas provoca reintentos. Rotar rápido reduce una ventana de compromiso, pero puede dividir a los clientes entre configuraciones y reducir el grupo visible común.

La instrucción de privacidad viaja por DNS

RFC 9848 define el parámetro ech para los registros SVCB y HTTPS de RFC 9460. Esos registros entregan al cliente endpoints y parámetros antes de conectar. Por eso un bloqueo de la respuesta puede ser tan decisivo como un fallo criptográfico.

RFC 9848 desaconseja mezclar en el mismo RRSet alternativas con y sin ECH. Un intermediario podría bloquear las protegidas y dejar solo la alternativa clara. También puede impedir por completo que el cliente conozca la configuración si suprime la resolución de servicio.

El DNS cifrado protege el tramo frente a un observador local, pero el resolvedor continúa viendo la consulta. La IP del frontal sigue en la red. ECH cubre el nombre explícito dentro del saludo; no convierte la ruta en anónima.

Un conjunto de anonimato se construye, no se declara

La meta formal es que varios nombres detrás del mismo frontal se parezcan. Compartir un ECHConfig ayuda. Usar uno distinto por nombre puede dejar un conjunto de tamaño uno. También separan a los miembros una suite pública singular, el orden de extensiones, la fragmentación del mensaje o una cookie de reintento reconocible.

La privacidad, por tanto, tiene una dimensión de operaciones. Un proveedor puede cifrar correctamente todos los saludos internos y aun identificar cada origen por su exterior. La prueba debe comparar miembros, no inspeccionar uno solo.

GREASE separa intolerancia de una promesa rota

GREASE ECH produce extensiones plausibles sin una oferta real. Sirve para detectar cajas intermedias que rechazan extensiones nuevas y para que el ECH verdadero no sea la única forma llamativa. También impide interpretar cada fallo de descifrado como error de configuración.

Las configuraciones de reintento, los bucles entre nodos y la alerta ech_required ofrecen señales más útiles. Un frontal puede medirlas sin inventar que una oferta imposible de abrir era necesariamente maliciosa o defectuosa.

Límites de la evidencia

Los RFC fijan formatos, roles y amenazas. No demuestran la activación en un navegador concreto, la conducta de una red ni el tamaño efectivo del grupo de un proveedor. Tampoco prueban que el cliente use transporte DNS cifrado o validación estricta.

Fuentes