Firefox y Cloudflare habilitan la compatibilidad con ECH para ocultar dominios en el tráfico HTTPS

Mozilla ha anunciado la inclusión de soporte para los usuarios de la rama estable de Firefox para el mecanismo ECH (Encrypted Client Hello), que continúa el desarrollo de la tecnología ESNI (Encrypted Server Name Indication) y está diseñado para 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ó originalmente a la versión Firefox 85, pero estaba deshabilitado de forma predeterminada. Chrome gradualmente comenzó a incluir soporte ECH a partir del lanzamiento de Chrome 115.

Ya que además de conectar con servidor La información del dominio solicitada se filtra a través de DNS. Para una protección completa, además de ECH, debe usar DNS sobre HTTPS o DNS sobre TLS para cifrar el tráfico DNS. Firefox no usará ECH sin habilitar DNS sobre HTTPS en la configuración. Puede consultar la compatibilidad de ECH en su navegador en esta página.

Uno de los factores que habilitó el soporte ECH de forma predeterminada en Firefox fue la inclusión del soporte ECH por parte de Cloudflare en su red de entrega de contenido hace unos días. Desde el punto de vista práctico, dado que los datos sobre los hosts solicitados cuando se usa ECH están ocultos para el análisis, filtrar y bloquear sitios no deseados usando Cloudflare CDN ahora requerirá bloquear toda la red de Cloudflare, bloquear todas las solicitudes de ECH u organizar la interceptación HTTPS usando certificados raíz falsos. en el sistema del usuario.

Inicialmente, para organizar el trabajo en una dirección IP de varios sitios HTTPS, se utilizó la extensión TLS SNI, en la que el nombre del host solicitado se indicaba en el mensaje ClientHello transmitido antes de establecer un canal de comunicación cifrado. Esta característica hizo posible distribuir solicitudes entre hosts virtuales en una etapa temprana del procesamiento de la conexión, pero también hizo posible que el ISP filtrara selectivamente el tráfico HTTPS y analizara qué sitios abre el usuario, lo que no permitió lograr una total confidencialidad al usar. HTTPS.

Para solucionar este problema y evitar la filtración de información sobre el sitio solicitado, posteriormente se propuso una extensión ESNI que implementa el cifrado de datos con el nombre del host. Durante la implementación de ESNI, se reveló que el mecanismo propuesto no cubre todas las fuentes posibles de fuga de datos del host y su uso no es suficiente para garantizar la total confidencialidad de las sesiones HTTPS. En particular, al reanudar una sesión previamente establecida, el nombre de dominio en texto claro seguía estando especificado entre los parámetros de la extensión TLS PSK (Pre-Shared Key). Además, los esfuerzos para implementar ESNI han identificado problemas de compatibilidad y escalamiento que han impedido la adopción generalizada de ESNI.

Teniendo en cuenta las deficiencias identificadas de ESNI, se desarrolló un nuevo mecanismo ECH universal que permite cifrar los parámetros de cualquier extensión TLS. Técnicamente, la principal diferencia entre ECH y ESNI es que, en lugar de campos individuales, todo el mensaje ClientHello se cifra a la vez. ECH implica dividir ClientHello en dos mensajes separados: el mensaje ClientHelloInner cifrado (SNI Inner) y el mensaje ClientHelloOuter subyacente no cifrado (SNI Outer). Un SNI Outer sin cifrar contiene datos que no son de privacidad, como la versión TLS y una lista de cifrados utilizados, así como un nombre de dominio común que no se superpone con el nombre real del dominio solicitado. Por ejemplo, para todos los clientes de Cloudflare, el SNI externo no cifrado especifica el host común "cloudflare-ech.com", pero el nombre real del host solicitado se transmite en el SNI interno cifrado y no está disponible para su análisis.

Firefox y Cloudflare habilitan la compatibilidad con ECH para ocultar dominios en el tráfico HTTPS

ECH también utiliza un esquema diferente de distribución de claves de cifrado: la información de la clave pública se transmite en registros DNS HTTPSSVC en lugar de registros TXT. Para obtener y cifrar la clave, se utiliza un cifrado de extremo a extremo autenticado basado en el mecanismo HPKE (cifrado híbrido de clave pública). ECH también admite la retransmisión segura de claves desde el servidor, que puede utilizarse en caso de rotación de claves. servidor y resolver problemas con la recuperación de claves obsoletas de la caché DNS.

Fuente: opennet.ru

Compre alojamiento confiable para sitios con protección DDoS, servidores VPS VDS 🔥 Compra alojamiento web fiable con protección DDoS, servidores VPS VDS | ProHoster