Pregunta y contexto
Usted opera un servicio multidominio detrás de una CDN. El equipo de seguridad notó que TLS aún expone un SNI en texto no cifrado en ClientHello y desea evaluar Encrypted Client Hello (ECH). Explique cómo obtienen los clientes la configuración de ECH, qué hacen el ClientHello exterior e interior, dónde se ubica el límite entre la CDN y el origen, cómo recurren al fallback los clientes antiguos y qué métricas diagnostican problemas de despliegue.
Qué está evaluando el entrevistador
El entrevistador espera que ECH se describa como una extensión de TLS, no como una VPN, DNS cifrado o anonimato total del tráfico. El cliente cifra un ClientHello interior con una clave pública publicada por el servidor y envía un ClientHello exterior a un servidor orientado al cliente; el nombre exterior se utiliza para el enrutamiento público. Una respuesta sólida cubre la entrega de configuración mediante HTTPS/SVCB o equivalente, el soporte de la CDN y del cliente, y el hecho de que las direcciones IP, el tamaño del tráfico, la temporización y otros canales laterales siguen siendo visibles.
Preguntas de clarificación que conviene hacer primero
Observador y objetivo de privacidad
Aclare si la amenaza es un observador pasivo, un proxy empresarial o un atacante activo man-in-the-middle, y si una puerta de enlace aún debe aplicar políticas de dominio. Cada observador ve una combinación diferente de IP, DNS, nombre exterior y temporización.
Topología y límite de claves
Confirme si ECH termina en el borde de la CDN o en un punto de entrada autogestionado y si el origen aún necesita TLS independiente. Asigne la responsabilidad de la rotación, distribución y revocación de la clave privada de ECH; la clave pública de la CDN no es un certificado de origen.
Compatibilidad y política de fallback
Confirme los navegadores, sistemas operativos, DoH/DoT, HTTP/3 y middleboxes empresariales de destino. Recurrir a un fallback con SNI en texto no cifrado restablece la compatibilidad, pero también restablece la visibilidad del observador, por lo que las políticas y las métricas deben decidir cuándo es aceptable.
Marco de respuesta en 30 segundos
«ECH cifra un ClientHello interior con una clave pública de ECH publicada por el servidor, colocando el SNI real y las extensiones sensibles en su interior. El ClientHello exterior lleva un nombre público para que el servidor orientado al cliente pueda enrutar la conexión. Los clientes suelen obtener la configuración a través de registros HTTPS/SVCB o políticas del navegador, y el borde descifra el mensaje interior antes de continuar con TLS 1.3. En caso de fallo, la política puede reintentar o abortar; un fallback a SNI en texto no cifrado ofrece menor privacidad. ECH aún no oculta la IP, el DNS, la temporización ni el volumen de tráfico, por lo que debe evaluarse junto con DNS, CDN, monitorización y rotación de claves».
Respuesta detallada paso a paso
Paso 1: Publicar la configuración de ECH
El servicio publica un ECHConfig que contiene una clave pública, la versión y metadatos de encapsulación. Un cliente lo obtiene a partir de registros HTTPS/SVCB confiables o de la configuración del navegador y valida su origen. La configuración necesita control de versiones y caducidad; las claves obsoletas no deben permanecer en caché indefinidamente.
Paso 2: Construir los protocolos de enlace exterior e interior
El cliente coloca el SNI real, ALPN y las extensiones sensibles en un ClientHello interior cifrado con la clave pública de ECH. El ClientHello exterior lleva un nombre público y la carga útil cifrada. Dicho nombre apunta a un servidor orientado al cliente con capacidad para ECH, en lugar de revelar el dominio final del servicio.
Paso 3: Procesar el mensaje en el borde
El borde recibe el ClientHello exterior y prueba la clave privada de ECH. Si tiene éxito, selecciona los certificados y el enrutamiento a partir de los parámetros interiores; si falla, envía una configuración de reintento o finaliza según las reglas de TLS. El enlace TLS desde el borde hacia el origen sigue siendo un límite de seguridad independiente; ECH no reemplaza la autenticación del origen.
Paso 4: Gestionar el fallback y la superficie de ataque
Una configuración caducada, versiones incompatibles, la manipulación de DNS o un middlebox que bloquea pueden impedir ECH. El servidor puede publicar una configuración de reintento de confianza y permitir que el cliente lo intente de nuevo. Si se permite el fallback a SNI en texto no cifrado, delimite su alcance y regístrelo. Nunca trate una configuración de reintento arbitraria como prueba de éxito, ya que son posibles la degradación y el enrutamiento incorrecto.
Paso 5: Declarar qué se oculta y qué no
ECH oculta principalmente el nombre del sitio y las extensiones relacionadas en ClientHello. Los observadores aún pueden ver consultas DNS, el nombre exterior, la IP de destino, los tiempos del protocolo de enlace, el recuento de conexiones, el tamaño de los paquetes y los patrones de tráfico posteriores. Un nombre exterior único o un despliegue reducido pueden reducir el conjunto de anonimato.
Paso 6: Administrar claves y operaciones
Establezca procedimientos de rotación, doble aprobación, reversión y revocación de emergencia para las claves privadas de ECH. Supervise el tiempo de publicación, la aceptación del cliente, la tasa de reintentos, los fallos de descifrado, las alertas de TLS y el desfase de versiones entre los nodos del borde. Utilice identificadores de diagnóstico que no contengan el SNI interior; los registros no deben recrear los datos sensibles que ECH debía proteger.
Paso 7: Implementar y verificar gradualmente
Realice un despliegue canary de ECH en dominios controlados y clientes compatibles. Compare el éxito, el fallback, la cancelación, la latencia del protocolo de enlace, la negociación de HTTP/2 o HTTP/3 y los errores del origen. Pruebe configuraciones caducadas, claves privadas incorrectas, middleboxes y rotación multinodo, y luego verifique que los clientes antiguos sigan funcionando bajo la política declarada.
Respuesta de muestra de alta calidad
ECH es una extensión de TLS 1.3 que cifra un ClientHello interior con una clave pública de ECHConfig. El SNI real y ALPN permanecen en el mensaje interior; el ClientHello exterior lleva un nombre público y una carga útil cifrada. Un borde de CDN compatible con ECH descifra el mensaje interior y selecciona el certificado y la ruta. El enlace TLS entre el borde y el origen se mantiene separado, y ECH no reemplaza la autenticación del origen.
Primero definiría el modelo de amenazas, la entrega mediante DNS/SVCB, la propiedad de claves de la CDN y la política de fallback. Una configuración caducada, una incompatibilidad de versiones o la interferencia de middleboxes pueden desencadenar un reintento de confianza; el fallback a SNI en texto no cifrado solo se permite mediante una política explícita y se mide. ECH oculta campos del protocolo de enlace, no la IP, el DNS, la temporización ni el volumen de tráfico. Durante el despliegue, supervisaría la aceptación, los reintentos, los fallos de descifrado, la latencia y los errores de origen, utilizando configuraciones versionadas y rotación de claves reversible.
Errores comunes
- Error: Asumir que ECH hace que cada visita sea anónima. → Por qué falla: La IP, el DNS, la temporización y el volumen aún pueden correlacionar una conexión. → Solución: Describa el conjunto de anonimato y los canales laterales restantes, incluidos el despliegue de DNS y CDN.
- Error: Tratar la clave privada de ECH como la clave del certificado de origen. → Por qué falla: El descifrado en el borde y la autenticación de origen son límites independientes. → Solución: Separe los ciclos de vida de las claves, los permisos y la rotación.
- Error: Recurrir al fallback de forma incondicional tras el fallo de ECH. → Por qué falla: Un atacante puede inducir fallos y degradar la privacidad. → Solución: Defina políticas de reintento, anulación y fallback con alertas.
- Error: Registrar el ClientHello interior completo para depuración. → Por qué falla: Los registros vuelven a exponer el nombre del sitio que ECH debía ocultar. → Solución: Registre la versión de configuración, el nodo y la clase de error sin campos sensibles.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cómo se relaciona ECH con ESNI?
ESNI protegía principalmente el SNI. ECH cifra un ClientHello interior más amplio y define la coordinación entre el exterior y el interior, así como la entrega de la configuración. Utilice el estándar actual de ECH y la documentación de despliegue; la terminología antigua de ESNI no constituye un plan de implementación completo.
Pregunta de seguimiento 2: ¿Cómo puede una empresa auditar el tráfico cuando el middlebox no puede ver el dominio real?
Primero determine si la organización controla los endpoints y las puertas de enlace de salida. Los dispositivos administrados pueden proporcionar señales de política a un agente o proxy de confianza. En redes públicas, ocultar el SNI no es un fallo de TLS; la privacidad y la visibilidad organizacional deben conciliarse mediante políticas explícitas.
Pregunta de seguimiento 3: ¿Por qué afecta el nombre exterior a la privacidad?
Si un nombre exterior solo sirve a un sitio real, la IP, el DNS y ese nombre aún pueden acotar el destino. Los puntos de entrada compartidos y un conjunto de anonimato más grande mejoran la privacidad, pero añaden complejidad operativa, de enrutamiento y de certificados.
Pregunta de seguimiento 4: ¿Cómo distingue un fallo de ECH de un fallo ordinario de TLS?
Correlacione si el cliente envió ECH, la versión de configuración, los reintentos en el borde, los contadores de fallos de descifrado, las alertas de TLS, el nodo y la ventana de tiempo. Reproduzca con ECH habilitado, deshabilitado y una configuración antigua en el mismo cliente para no etiquetar erróneamente problemas de certificados, ALPN o estado del origen como fallos de ECH.