China ha comenzado a bloquear las conexiones HTTPS establecidas con TLS 1.3 y ESNI

China implementado bloqueo todas las conexiones HTTPS que utilizan el protocolo TLS 1.3 y la extensión TLS ESNI (Indicación de nombre de servidor cifrado), que proporciona cifrado de datos sobre el host solicitado. El bloqueo se realiza en los enrutadores de tránsito tanto para las conexiones establecidas desde China hacia el mundo exterior como desde el mundo exterior hacia China.

El bloqueo se realiza descartando paquetes del cliente al servidor, en lugar de la sustitución de paquetes RST que se realizaba anteriormente mediante el bloqueo selectivo de contenido SNI. Después de que se activa el bloqueo de un paquete con ESNI, todos los paquetes de red correspondientes a la combinación de IP de origen, IP de destino y número de puerto de destino también se bloquean durante 120 a 180 segundos. Las conexiones HTTPS basadas en versiones anteriores de TLS y TLS 1.3 sin ESNI se permiten como de costumbre.

Recordemos que para organizar el trabajo en una dirección IP de varios sitios HTTPS, se desarrolló la extensión SNI, que transmite el nombre del host en texto claro en el mensaje ClientHello transmitido antes de instalar un canal de comunicación cifrado. Esta característica permite al proveedor de Internet filtrar selectivamente el tráfico HTTPS y analizar qué sitios abre el usuario, lo que no permite lograr una total confidencialidad al utilizar HTTPS.

La nueva extensión TLS ECH (anteriormente ESNI), que se puede utilizar junto con TLS 1.3, elimina esta deficiencia y elimina por completo la filtración de información sobre el sitio solicitado al analizar conexiones HTTPS. En combinación con el acceso a través de una red de entrega de contenidos, el uso de ECH/ESNI también permite ocultar al proveedor la dirección IP del recurso solicitado. Los sistemas de inspección de tráfico solo verán solicitudes a la CDN y no podrán aplicar el bloqueo sin la suplantación de sesión TLS, en cuyo caso se mostrará la notificación correspondiente sobre la suplantación de certificados en el navegador del usuario. DNS sigue siendo un posible canal de fuga, pero el cliente puede usar DNS sobre HTTPS o DNS sobre TLS para ocultar el acceso a DNS por parte del cliente.

Los investigadores ya están identificado Existen varias soluciones para evitar el bloqueo chino en el lado del cliente y del servidor, pero pueden volverse irrelevantes y solo deben considerarse como una medida temporal. Por ejemplo, actualmente solo los paquetes con la extensión ESNI ID 0xffce (encrypted_server_name), que se usó en quinta versión del proyecto de norma, pero por ahora paquetes con el identificador actual 0xff02 (encrypted_client_hello), propuesto en séptimo borrador de la especificación ECH.

Otra solución es utilizar un proceso de negociación de conexión no estándar; por ejemplo, el bloqueo no funciona si se envía por adelantado un paquete SYN adicional con un número de secuencia incorrecto, manipulaciones con indicadores de fragmentación de paquetes, envío de un paquete con FIN y SYN. indicadores establecidos, sustitución de un paquete RST con una cantidad de control incorrecta o envío antes de que comience la negociación de la conexión del paquete con los indicadores SYN y ACK. Los métodos descritos ya se han implementado en forma de complemento para el kit de herramientas. Geneva, desarrollado para eludir los métodos de censura.

Fuente: opennet.ru

Añadir un comentario