Prompt y alcance
TLS 1.3 cifra la mayor parte del contenido del handshake, pero un ClientHello tradicional puede exponer el SNI y permitir que un observador infiera el servicio de destino. Explica el rol de ECH en el protocolo, la entrega de la configuración de claves y el comportamiento ante fallos, y distingue entre ocultar el SNI y ocultar todas las características del tráfico.
Esto encaja en roles de redes, seguridad, plataforma y protocolos generales. Su habilidad principal son los límites de privacidad y el handshake de TLS, por lo que pertenece a general.
Qué evalúan los entrevistadores
Primero, ¿entiendes el ClientHello exterior (outer) y el interior (inner)? ClientHelloOuter proporciona una estructura de compatibilidad mientras que el destino real se coloca en ClientHelloInner cifrado con la clave pública configurada del servidor.
Segundo, ¿puedes explicar la entrega de la configuración? ECHConfig contiene una clave pública y metadatos del algoritmo; se puede descubrir mediante registros DNS SVCB/HTTPS, pero la autenticidad y la frescura siguen siendo importantes.
Tercero, ¿sabes que ECH no es anonimato de extremo a extremo? El DNS, la IP, los tiempos, los certificados y las rutas sin ECH todavía pueden revelar información.
Cuarto, ¿puedes explicar el fallback ante fallos? Un cliente puede reintentar o enviar un ClientHello normal cuando ECH no está disponible. La política no debe contabilizar un intento de privacidad fallido como un éxito.
Quinto, ¿puedes diseñar la verificación? Inspecciona las extensiones del handshake, las métricas del edge, la tasa de aciertos de configuración y la tasa de fallback en lugar de comprobar únicamente el éxito de HTTPS.
Preguntas para aclarar primero
- ¿El cliente, el proxy edge y la biblioteca TLS soportan RFC 9849?
- ¿Cómo se entrega ECHConfig y cómo se manejan DNSSEC o el DNS cifrado?
- ¿El servicio tiene un frontend compartido y múltiples nombres de backend?
- ¿Se permite el fallback a SNI en texto plano o el fallo de privacidad debe ser un fallo estricto (hard failure)?
- ¿Estamos protegiendo un dominio, un nombre de tenant o metadatos de tráfico más amplios?
- ¿Puede la telemetría registrar el éxito de ECH sin registrar el nombre interno?
Estructura de respuesta de 30 segundos
“ECH coloca el destino real en ClientHelloInner y lo cifra con HPKE utilizando la clave pública publicada en ECHConfig; ClientHelloOuter mantiene la compatibilidad del handshake. ECHConfig se puede entregar mediante DNS SVCB/HTTPS, con comprobaciones de autenticidad y frescura. Ante un fallo, la política elige fallback o hard failure, y el éxito de TLS no es sinónimo de éxito de privacidad. La verificación combina extensiones de handshake, métricas del edge, aciertos de configuración y tasas de fallback, al tiempo que reconoce que el DNS, la IP y los patrones de tráfico siguen siendo visibles”.
Respuesta paso a paso
Paso 1: Separar los dos mensajes ClientHello
El cliente construye ClientHelloInner con el SNI real y las extensiones que desea ocultar, luego crea ClientHelloOuter como un mensaje de compatibilidad. El servidor o edge utiliza la clave de ECHConfig para descifrar el mensaje interno; si no puede, maneja el fallo según el protocolo.
Paso 2: Entender HPKE y la configuración
ECHConfig transporta una versión, clave pública, suites de cifrado y metadatos del servidor. El cliente utiliza HPKE para proteger ClientHelloInner, mientras que el servidor conserva la clave privada correspondiente. La rotación necesita solapamiento de validez, control de caché y revocación; no se debe codificar la clave de forma fija (hard-code) en los clientes.
config = fetch_ech_config()
inner = build_client_hello(real_sni, extensions)
outer = build_outer_hello(public_name, ech_extension)
encrypted_inner = hpke_seal(config.public_key, inner)
send(outer, encrypted_inner)Paso 3: Analizar la entrega por DNS y la autenticidad
ECHConfig se puede descubrir a través de registros SVCB/HTTPS. Evalúa la frescura, el almacenamiento en caché y el riesgo de manipulación; el DNS cifrado solo protege parte de la ruta, mientras que DNSSEC y la política de la aplicación determinan la confianza. Actualiza ante una configuración inválida o expirada.
Paso 4: Definir el fallo y el fallback
Un fallo de descifrado, una configuración expirada, GREASE o la incompatibilidad de extensiones pueden desencadenar un reintento o un handshake ordinario. Decide qué dominios permiten fallback y qué requisitos de privacidad exigen un hard failure, y registra la razón. El fallback no es un éxito de ECH.
Paso 5: Identificar la exposición restante
ECH oculta el nombre de destino en ClientHello, pero las consultas DNS, la IP de destino, los tiempos, los tamaños de paquete, los certificados y el comportamiento de la aplicación aún pueden permitir el análisis de tráfico. Define el objetivo como la reducción de la exposición de metadatos específicos del handshake, no como anonimato.
Paso 6: Planificar el despliegue y la rotación de claves
Despliega las claves privadas en el edge con el principio de menor privilegio y pistas de auditoría, y publica configuraciones antiguas y nuevas solapadas. Las cachés multirregión necesitan versiones consistentes e invalidación. Si una clave se ve comprometida, revoca la configuración antigua, acorta el TTL y vigila las tasas de fallback.
Paso 7: Construir la aceptación de extremo a extremo
Prueba clientes con y sin ECH, múltiples rutas DNS y múltiples nodos edge. Registra la negociación de extensiones, la versión de configuración, los fallos de descifrado, la tasa de fallback, la latencia del handshake y los errores de conexión. La validación de paquetes no debe registrar el nombre interno sensible.
Respuesta modelo
“ECH es una extensión del handshake de TLS, no un túnel a nivel de aplicación. El cliente coloca el SNI real en ClientHelloInner, lo cifra con HPKE usando la clave pública de ECHConfig y envía un ClientHelloOuter compatible. ECHConfig se puede descubrir mediante SVCB/HTTPS, por lo que el despliegue debe abordar la autenticidad del DNS, el almacenamiento en caché y la rotación.
Yo definiría la política de fallos explícitamente: hard failure para endpoints sensibles a la privacidad y fallback ordinario observable para endpoints de compatibilidad. La telemetría cubre la negociación, aciertos de configuración, fallos de descifrado, fallback y latencia de handshake sin registrar el nombre interno. El DNS, la IP, los certificados y los patrones de tráfico aún requieren un análisis de privacidad separado. La aceptación abarca clientes, rutas DNS y rotación de claves”.
Errores comunes
- Afirmar que ECH oculta todo el tráfico → El DNS, la IP y los tiempos siguen siendo visibles → establecer un objetivo de privacidad acotado.
- Codificar de forma fija (hard-code) las claves de ECHConfig → La rotación y revocación se vuelven difíciles → usar una configuración actualizable.
- Comprobar solo el éxito de HTTPS → El fallback ordinario se contabiliza como ECH → registrar extensiones y la razón del fallback.
- Ignorar la manipulación de DNS y las cachés obsoletas → Los clientes usan una configuración incorrecta → evaluar la autenticidad, el TTL y la actualización.
- Tratar el SNI externo como el destino real → El nombre de compatibilidad se malinterpreta → separar el nombre público y el SNI interno.
- Rotar claves sin solapamiento → Los clientes multirregión fallan de forma intermitente → usar un plan de solapamiento e invalidación.
- Registrar el nombre interno → La telemetría vuelve a filtrar privacidad → registrar únicamente hashes, versiones y estados.
- Ignorar clientes no soportados → Los usuarios reales no pueden conectarse → mantener reglas explícitas de fallback o hard failure.
Preguntas de seguimiento
Pregunta de seguimiento 1: ¿Cómo se relacionan ECH y DoH/DoT?
ECH protege el ClientHello de TLS; DoH/DoT protegen el transporte DNS. Abordan etapas diferentes y pueden combinarse, pero ninguno reemplaza al otro.
Pregunta de seguimiento 2: ¿Por qué es necesario ClientHelloOuter?
Proporciona una estructura de compatibilidad para que los middleboxes que no entienden ECH aún puedan procesar el handshake mientras el destino real permanece en el mensaje interno cifrado.
Pregunta de seguimiento 3: ¿Debe ECH recurrir siempre al fallback ante un fallo?
No. La política depende de los requisitos de privacidad y disponibilidad. Un endpoint sensible a la privacidad puede aplicar un hard failure; un endpoint de compatibilidad puede recurrir al fallback, pero debe hacerlo observable y cuantificable.
Pregunta de seguimiento 4: ¿Cómo se verifica que los middleboxes no rompieron ECH?
Registra la negociación por separado en el cliente, el edge y el servidor, luego compara el éxito, el fallback y los errores de handshake en las rutas del proxy.
Pregunta de seguimiento 5: ¿Qué sucede después del compromiso de una clave?
Revoca o deja de publicar la ECHConfig antigua, acorta el TTL de la caché, despliega una nueva clave y monitorea los fallos de descifrado y el fallback. Los ClientHellos expuestos previamente no pueden volverse privados retroactivamente.
Pregunta de seguimiento 6: ¿Oculta ECH los nombres de dominio en los certificados?
Oculta principalmente el nombre de destino en el handshake. Los certificados, el DNS, la IP y la información de la aplicación aún pueden correlacionar el dominio, por lo que no se puede prometer un ocultamiento completo del dominio.