Chine toutes les connexions HTTPS qui utilisent le protocole TLS 1.3 et l'extension TLS ESNI (Encrypted Server Name Indication), qui assure le cryptage des données sur l'hôte demandé. Le blocage est effectué sur les routeurs de transit aussi bien pour les connexions établies depuis la Chine vers le monde extérieur que depuis le monde extérieur vers la Chine.
Le blocage est effectué en supprimant les paquets du client vers le serveur, plutôt qu'en remplaçant les paquets RST précédemment effectués par le blocage sélectif du contenu SNI. Après le déclenchement du blocage d'un paquet avec ESNI, tous les paquets réseau correspondant à la combinaison de l'IP source, de l'IP de destination et du numéro de port de destination sont également bloqués pendant 120 à 180 secondes. Les connexions HTTPS basées sur les anciennes versions de TLS et TLS 1.3 sans ESNI sont autorisées comme d'habitude.
Rappelons que afin d'organiser le travail sur une adresse IP de plusieurs sites HTTPS, l'extension SNI a été développée, qui transmet le nom d'hôte en texte clair dans le message ClientHello transmis avant d'installer un canal de communication crypté. Cette fonctionnalité permet du côté du fournisseur d’accès Internet de filtrer sélectivement le trafic HTTPS et d’analyser les sites ouverts par l’utilisateur, ce qui ne permet pas d’obtenir une confidentialité totale lors de l’utilisation de HTTPS.
La nouvelle extension TLS ECH (anciennement ESNI), qui peut être utilisée avec TLS 1.3, élimine cette lacune et élimine complètement la fuite d'informations sur le site demandé lors de l'analyse des connexions HTTPS. En combinaison avec l'accès via un réseau de diffusion de contenu, l'utilisation d'ECH/ESNI permet également de cacher au fournisseur l'adresse IP de la ressource demandée. Les systèmes d'inspection du trafic ne verront que les demandes adressées au CDN et ne pourront pas appliquer de blocage sans usurpation de session TLS, auquel cas une notification correspondante concernant l'usurpation de certificat sera affichée dans le navigateur de l'utilisateur. Le DNS reste un canal de fuite possible, mais le client peut utiliser DNS sur HTTPS ou DNS sur TLS pour masquer l'accès DNS du client.
Les chercheurs sont déjà Il existe plusieurs solutions pour contourner le blocage chinois côté client et côté serveur, mais elles peuvent devenir inutiles et ne doivent être considérées que comme une mesure temporaire. Par exemple, actuellement, seuls les paquets portant l'ID d'extension ESNI 0xffce (encrypted_server_name), qui était utilisé dans , mais pour l'instant les paquets avec l'identifiant actuel 0xff02 (encrypted_client_hello), proposés dans .
Une autre solution consiste à utiliser un processus de négociation de connexion non standard, par exemple, le blocage ne fonctionne pas si un paquet SYN supplémentaire avec un numéro de séquence incorrect est envoyé à l'avance, des manipulations avec des indicateurs de fragmentation de paquet, l'envoi d'un paquet avec à la fois FIN et SYN. drapeaux définis, substitution d'un paquet RST avec une quantité de contrôle incorrecte ou envoi avant le début de la négociation de connexion de paquet avec les drapeaux SYN et ACK. Les méthodes décrites ont déjà été implémentées sous la forme d'un plugin pour la boîte à outils , pour contourner les méthodes de censure.
Source: opennet.ru