Resumen

  • El ClientHelloInner cifrado, el contenedor exterior y el public_name pertenecen a capas distintas. El último nombra al servidor orientado al cliente, no al origen privado.
  • Configuración DNS, aceptación de ECH, autenticación TLS y éxito de la aplicación necesitan recibos separados; ninguno hereda automáticamente la conclusión del anterior.

RFC 9849 divide el saludo en dos formas. El cliente pone los valores privados en ClientHelloInner, deja valores inocuos en ClientHelloOuter y cifra el primero con una clave pública ECH. Los dos mensajes quedan ligados para impedir una manipulación específica del exterior conservando el mismo interior. Esa propiedad protege la envoltura. No dice que el registro DNS, la dirección pública, el proveedor frontal, el backend y el principal de la aplicación sean el mismo actor.

El nombre que permanece visible tiene un trabajo limitado. public_name es el nombre DNS del servidor que recibe al cliente y que está autorizado, dentro del modelo ECH, a actualizar la configuración y a ayudar a recuperar una configuración obsoleta. Normalmente aparece en el SNI exterior. No es el nombre secreto del backend, ni una declaración de propiedad, ni una prueba de que todos los nombres de un conjunto anónimo comparten operador.

La topología hace que esa cautela sea necesaria. En modo compartido, el frontal y quien termina TLS pueden coincidir. En modo dividido, el servidor frontal reenvía al backend que termina TLS. RFC 9849 supone un canal autenticado entre ambos y supone que el atacante no puede correlacionar los dos tramos; el mecanismo concreto para evitar esa correlación queda fuera de alcance. Un paquete ECH observado no audita esas condiciones.

La aceptación tampoco completa la cadena. El servidor acepta ECH y usa el interior, o lo rechaza y usa el exterior. Tras un rechazo, la conexión no sirve para datos de aplicación del cliente ECH y puede iniciar una recuperación con configuración nueva. La aceptación responde a una pregunta de negociación. No registra que el cliente validó un certificado con su almacén de confianza, que el nombre esperado coincidió, que una política autorizó una solicitud ni que el servicio terminó una operación.

RFC 8446 mantiene la independencia: TLS negocia parámetros, puede autenticar pares y crea claves; la semántica de la aplicación permanece fuera. La validación de certificados depende de anclas de confianza distribuidas por separado y de decisiones locales. Por eso ECH no sustituye a la validación de identidad, y un certificado visible no demuestra por sí solo el camino DNS ni la gobernanza del backend.

RFC 9460 añade que SVCB y HTTPS pueden entregar claves y extremos alternativos, incluso con capacidades u operadores distintos. Un registro puede explicar la instrucción disponible para el cliente, no el extremo realmente seleccionado ni el resultado final.

La revisión operativa debe conservar columnas separadas para origen/TTL de ECHConfig, resolutor y caché, aceptación, identidad esperada, validación, canal frontal-backend, extremo elegido y respuesta de la aplicación. La privacidad gana precisión cuando no se la obliga a contar una historia institucional que no contiene.

Fuentes