La empresa Mozilla ha anunciado la inclusión para los usuarios de la rama estable de Firefox del mecanismo ECH (Encrypted Client Hello), que continúa desarrollando la tecnología ESNI (Encrypted Server Name Indication) y está destinado a cifrar información sobre los parámetros de las sesiones TLS, como el nombre de dominio solicitado. El código para trabajar con ECH se agregó inicialmente en la versión 85 de Firefox, pero estaba desactivado por defecto. En Chrome, el soporte para ECH comenzó a habilitarse gradualmente, a partir de la versión 115 de Chrome.
Dado que además de la conexión con el servidor la filtración de datos sobre los dominios solicitados ocurre a través de DNS, para una protección completa además de ECH es necesario implementar tecnología DNS over HTTPS o DNS over TLS para cifrar el tráfico DNS. Firefox no utilizará ECH sin la activación de DNS over HTTPS en la configuración. Se puede comprobar el soporte de ECH en el navegador en esta página.
Uno de los factores que llevó a la activación por defecto del soporte de ECH en Firefox fue la inclusión, hace unos días, del soporte de ECH en su red de entrega de contenido por parte de Cloudflare. Desde un punto de vista práctico, dado que los datos sobre los hosts solicitados están ocultos al análisis al aplicar ECH, para filtrar y bloquear sitios no deseados que utilizan CDN de Cloudflare, ahora será necesario bloquear toda la red de Cloudflare, bloquear todas las solicitudes con ECH o organizar la intercepción de HTTPS mediante certificados raíz falsificados en el sistema del usuario.
Inicialmente, para habilitar el funcionamiento de varios sitios HTTPS en una misma dirección IP se utilizaba la extensión SNI de TLS, en la que el nombre del host solicitado se indicaba en el mensaje ClientHello, enviado antes de establecer el canal de comunicación cifrado. Esta característica permitía, en una etapa temprana del procesamiento de la conexión, distribuir las solicitudes a través de hosts virtuales, pero también permitía al proveedor de internet filtrar selectivamente el tráfico HTTPS y analizar qué sitios visita el usuario, lo que impedía alcanzar la plena confidencialidad al utilizar HTTPS.
Para abordar este problema y evitar la filtración de información sobre el sitio web solicitado, se propuso posteriormente la extensión ESNI, que implementa el cifrado de datos con el nombre del host. Durante la implementación de ESNI, se descubrió que el mecanismo propuesto no cubría todas las posibles fuentes de filtración de datos sobre el host, y su aplicación no era suficiente para garantizar la completa confidencialidad de las sesiones HTTPS. En particular, al reanudar una sesión previamente establecida, el nombre de dominio en texto claro seguía apareciendo entre los parámetros de la extensión TLS PSK (Pre-Shared Key). Además, los intentos de implementar ESNI revelaron problemas de compatibilidad y escalabilidad que impedían la adopción generalizada de ESNI.
Teniendo en cuenta las deficiencias identificadas en ESNI, se desarrolló un nuevo mecanismo universal llamado ECH, que permite el cifrado de los parámetros de cualquier extensión TLS. Técnicamente, la principal diferencia entre ECH y ESNI es que, en lugar de campos separados, se cifra todo el mensaje ClientHello de una vez. ECH implica la separación del ClientHello en dos mensajes distintos: el mensaje cifrado ClientHelloInner (SNI Inner) y el mensaje base no cifrado ClientHelloOuter (SNI Outer). En el SNI Outer no cifrado se transmiten datos que no afectan la confidencialidad, como la versión de TLS y la lista de cifrados utilizados, así como el nombre de dominio general, que no se cruza con el nombre del dominio solicitado. Por ejemplo, para todos los clientes de Cloudflare, en el SNI Outer no cifrado se indica el host general "cloudflare-ech.com", mientras que el nombre real del host solicitado se transmite en el SNI Inner cifrado y no está disponible para análisis.
ECH también utiliza un esquema diferente de distribución de claves para el cifrado: la información sobre la clave pública se transmite en el registro DNS HTTPSSVC, y no en un registro de tipo TXT. Para obtener y cifrar la clave se emplea cifrado de extremo a extremo autenticado basado en el mecanismo HPKE (Hybrid Public Key Encryption). ECH también admite la retransmisión segura de la clave desde el servidor, lo que puede aplicarse en caso de rotación de claves en servidor y para abordar problemas al obtener claves obsoletas del caché DNS.
Fuente: opennet.ru
