- Le Great Firewall (GFW) de la Chine a déployé, à partir de début novembre 2021, une nouvelle technique de censure permettant de détecter passivement et de bloquer en temps réel le trafic de contournement entièrement chiffré
- Même les protocoles "looks like nothing" comme Shadowsocks, VMess et Obfs4, conçus pour faire paraître l’intégralité de leur charge utile comme aléatoire, sont devenus des cibles de blocage
- Sans déchiffrer le trafic chiffré lui-même, le GFW commence par filtrer les connexions qui semblent normales à l’aide d’heuristiques d’exception telles que les empreintes de protocoles courants, les proportions de bits, ainsi que le taux et la position des caractères ASCII
- En appliquant l’algorithme de détection inféré à du trafic réel, environ 0,6 % des connexions légitimes pourraient être bloquées ; il apparaît donc que le GFW réduit les dommages collatéraux en ne surveillant que 26 % de l’ensemble des connexions et uniquement certaines plages d’IP de datacenters
- Les stratégies de contournement issues de cette analyse ont été partagées avec les principaux outils d’évasion de la censure, largement déployées à partir de janvier 2022, et restaient encore efficaces en Chine en février 2023
Blocage par détection passive apparu en novembre 2021
- Les protocoles de contournement entièrement chiffrés ne commencent pas par une poignée de main en clair comme TLS ; ils sont conçus pour que tous les octets de la connexion soient indiscernables du hasard
- VMess, Shadowsocks et Obfs4 sont des protocoles représentatifs utilisant cette approche "looks like nothing"
- Le 6 novembre 2021, des internautes chinois ont signalé le blocage de serveurs Shadowsocks et VMess, et le 8 novembre, les développeurs d’Outline ont constaté une chute brutale de l’usage en provenance de Chine
- Le calendrier de ce blocage coïncide avec la 6e session plénière du 19e Comité central du Parti communiste chinois, tenue du 8 au 11 novembre 2021
- Depuis mai 2019, la Chine utilisait déjà à la fois l’analyse passive du trafic et la détection active pour identifier les serveurs Shadowsocks, mais ce cas constitue le premier exemple de blocage massif en temps réel fondé uniquement sur l’analyse passive du trafic visant des proxies entièrement chiffrés
Méthode de détection du GFW
- Le GFW ne définit pas directement ce qu’est un « trafic entièrement chiffré » ; il commence par exclure les connexions qui ont de fortes chances de ne pas en être
- Au moins cinq groupes d’heuristiques d’exception grossières mais efficaces sont utilisés
- les empreintes de protocoles courants
- des tests d’entropie approximatifs fondés sur des proportions de bits prédéfinies
- la proportion de caractères ASCII imprimables dans la première charge utile TCP
- la position des caractères ASCII
- le nombre maximal de caractères ASCII consécutifs
- Le trafic restant, qui n’entre dans aucune règle d’exception, devient une cible de blocage
- Comme le GFW est un système en boîte noire, les règles inférées peuvent ne pas être complètes
Résultats de mesure et risques de dommages collatéraux
- Les chercheurs ont utilisé des scans Internet pour déterminer quel trafic et quelles adresses IP le GFW inspecte
- Ils ont appliqué l’algorithme de détection du GFW inféré à du trafic réel collecté sur le network tap de CU Boulder afin d’évaluer sa couverture et son risque de faux positifs
- Les règles inférées se sont révélées largement recouper celles effectivement utilisées par le GFW
- Si cet algorithme de détection était appliqué largement, environ 0,6 % de l’ensemble des connexions du network tap pourraient être bloquées alors qu’il s’agit de trafic Internet légitime
- Probablement pour réduire le surblocage dû aux faux positifs, le GFW ne surveille stratégiquement que 26 % de l’ensemble des connexions et ne cible que certaines plages d’IP de datacenters populaires
Détection active et stratégies de contournement
- Cette nouvelle méthode de censure passive fonctionne en parallèle du système existant de détection active (active probing) du GFW
- Le système de détection active s’appuie lui aussi sur cet algorithme d’analyse du trafic, en y ajoutant des règles basées sur la longueur des paquets
- Les stratégies de contournement capables d’éviter ce nouveau blocage peuvent aussi empêcher le processus par lequel le GFW identifie d’abord les serveurs proxy puis les soumet à une détection active
- Les chercheurs ont partagé de manière responsable leurs résultats et propositions de contournement avec les développeurs de plusieurs outils d’évasion de la censure, dont Shadowsocks, V2Ray, Outline, Lantern, Psiphon et Conjure
- Ces stratégies de contournement ont été largement adoptées et déployées à partir de janvier 2022, ont aidé des millions d’utilisateurs à contourner cette nouvelle méthode de censure, et les stratégies adoptées restaient encore efficaces en Chine en février 2023
2 commentaires
On dirait que l’article résumé ne correspond pas au texte ni aux commentaires.
Avis sur Hacker News
L’article ne parle pas du tout de VPN, donc je me suis demandé s’il ne suffisait pas simplement d’en utiliser un ; mais l’entrée de Wikipedia sur le GFW indique que, si l’usage d’un VPN en Chine permet d’accéder à l’Internet international, il peut aussi entraîner des risques juridiques.
En 2017, le gouvernement chinois a déclaré illégaux tous les services VPN non autorisés. À titre d’exemple, l’étudiante de l’University of Washington Vera Zhou aurait été envoyée dans un camp d’internement au Xinjiang d’octobre 2017 à mars 2018, puis placée en résidence surveillée, après avoir utilisé un VPN pour accéder à ses devoirs universitaires lorsqu’elle rendait visite à ses parents hui au Xinjiang ; elle n’aurait pas pu rentrer aux États-Unis avant septembre 2019.
Zhou Yueming (Vera Yueming Zhou) semble avoir été envoyée dans un camp d’internement chinois moins parce qu’elle avait utilisé un VPN pour accéder au site de l’University of Washington que parce qu’elle appartenait à une minorité religieuse.
À l’époque, la police de Kuytun avait détecté, via des outils de surveillance numérique, que Vera utilisait un VPN pour accéder à des sites comme son compte Gmail universitaire ; du fait de son statut de membre d’une minorité musulmane, cela pouvait être considéré comme un « signe d’extrémisme religieux ».
Comme la police a gardé mon passeport pendant toute l’année où j’étais au Vietnam, je faisais attention ; mais quelques jours plus tard, j’ai simplement ouvert le NYT pendant quelques minutes, et Internet a été coupé pendant environ 3 heures. La fois suivante, la coupure a duré 24 heures, ce qui m’a fait comprendre que ce n’était pas une panne fortuite.
Ce n’était pas instantané, cela prenait quelques minutes, et j’étais assez convaincu qu’une personne à moitié dédiée surveillait mon trafic.
Je n’utilisais pas de VPN et je laissais volontairement mon trafic visible ; mais sachant qu’une connexion via VPN ne ferait qu’accroître les soupçons, je n’ai ensuite utilisé un VPN pour consulter mes e-mails que brièvement, dans des cafés.
Certains les utilisent pour réduire la latence quand ils jouent à des jeux à l’étranger ; le problème est plutôt que les connexions VPN sont facilement bloquées, et l’ambiance n’est pas vraiment à s’inquiéter fortement de problèmes juridiques.
Cela dit, lors des « manifestations de la feuille blanche », il me semble que, dans certaines régions, la police est allée chez des gens vérifier si leur téléphone contenait un VPN.
J’avais l’impression que la plupart des jeunes technophiles avaient un VPN, et que c’était aussi courant et bénin que rouler environ 10 mph au-dessus de la limite sur l’autoroute.
La plupart des gens ne sont pas persécutés pour le simple usage d’un VPN ; cela semble plutôt servir de prétexte pour détenir quelqu’un que le gouvernement voulait déjà persécuter.
Ce cas ressemble moins à un exemple de risque juridique lié à l’usage d’un VPN qu’à un exemple de sanction infligée à une personne ciblée pour d’autres raisons.
Autrement dit, même si toutes les lois interdisant les VPN étaient abrogées, il est très probable que, dans les faits, rien ne changerait.
Avant la pandémie, j’ai passé de longues périodes en Chine et j’ai beaucoup expérimenté face au GFW ; j’étais toujours surpris de voir à quelle vitesse il rattrapait shadowsocks ou des tunnels SSH arbitraires.
En général, il fallait changer d’IP en moins de 48 heures, mais ce rapport semble indiquer que c’est désormais détecté immédiatement.
La méthode la plus fiable consistait à s’appuyer sur une liaison physique de Shenzhen vers Hong Kong, puis, lors de déplacements en Chine, à se connecter en VPN à cette passerelle de Shenzhen.
Dans mon souvenir, cela fonctionnait toujours ; j’en avais donc déduit que l’essentiel de l’analyse et du blocage du trafic VPN par le GFW se faisait aux frontières, et beaucoup moins à l’intérieur, mais cette information est peut-être dépassée aujourd’hui.
Il a été bloqué immédiatement, le client n’a pas pu se connecter, et même avant la tentative, plusieurs IP inconnues essayaient déjà de s’y connecter.
J’ai été surpris de voir à quel point le GFW est hermétique, et c’est vraiment dommage : j’aimerais travailler tout en voyageant en Chine, mais c’est difficile quand on a besoin d’une connexion Internet stable.
Le trafic en roaming est tunnelisé vers l’opérateur du pays d’origine et, pour une raison quelconque, ce tunnel n’est pas inspecté du tout.
Avec l’arrivée des eSIM, on peut acheter une SIM en roaming en quelques minutes et l’utiliser immédiatement sur son téléphone.
Cela donnait l’impression d’une interférence à l’intérieur du réseau plutôt qu’à la frontière, mais je ne sais pas exactement comment cela fonctionnait.
Vu les capacités techniques de Hangzhou, il est possible que l’ISP local ait été plus compétent et doté de contre-mesures plus récentes.
Je me souviens avoir dû faire face aux débuts du GFW il y a environ 20 ans, quand je travaillais pour une entreprise qui avait du personnel sur site à Shanghai.
Chaque matin, quand nos collègues chinois ouvraient leur client mail, ils se connectaient à nos serveurs à l’étranger ; la première personne n’avait généralement pas de problème, mais les suivantes voyaient la connexion échouer.
À l’époque, on savait très peu de choses sur le GFW, et il n’était pas aussi malin qu’aujourd’hui. On avait constaté que les connexions POP étaient rapidement bloquées au bout de quelques minutes ; on avait l’impression qu’une règle de pare-feu lente se déclenchait au milieu, et comme c’était assez aléatoire, on en avait déduit que la configuration du pare-feu n’était pas uniforme.
Passer à POPS/SMTPS a amélioré les choses pendant un temps, mais les blocages aléatoires continuaient. Au final, on a configuré le serveur pour accepter les connexions POP/SMTP sur plusieurs ports arbitraires au lieu des ports bien connus, et le problème a disparu jusqu’à ce que nous changions de système quelques années plus tard.
Je n’ai pas creusé en profondeur, mais j’ai supposé que la connexion était détournée à des fins d’inspection ; si c’est bien le cas, il ne serait pas surprenant qu’ils fassent aussi de l’espionnage industriel avec les données consultées.
Il est intéressant qu’ils s’attaquent à Shadowsocks avec des plugins d’obfuscation.
Quand je suis allé en Chine entre 2017 et 2019, la combinaison SS + v2ray était quasiment devenue un standard de fait.
À l’époque, il y avait des campagnes contre les VPN à certaines périodes, comme début juin ou lors de grandes réunions gouvernementales. Procéduralement, il est difficile de les bloquer avec précision, mais ils semblaient appliquer un blocage large et approximatif à tout ce qui ressemblait à un VPN.
En général, la connexion s’établissait, mais elle était bridée au point de ne pratiquement plus pouvoir rien faire.
J’avais l’impression qu’un VPN dépassant un certain niveau de complexité était officieusement toléré, et qu’ils s’intéressaient surtout aux cibles faciles, utilisables sans effort par le grand public.
Quant à la petite minorité de geeks utilisant des outils plus sophistiqués, ils savaient probablement déjà qui les utilisait et préféraient aller les voir directement si cela devenait un problème.
La Chine ne semble pas se rendre compte à quel point elle se freine elle-même en investissant du temps et de l’expertise dans ce genre de choses inutiles.
La part de son PIB consacrée aux organisations de répression interne est presque équivalente à la part que les États-Unis consacrent à l’armée.
Brûler autant de talents et de richesse pour ajouter de l’inefficacité aux échanges d’information internes est peut-être une bonne chose pour le reste du monde.
Si la RPC dispose d’un écosystème informationnel domestique, c’est précisément parce qu’elle a eu la clairvoyance de filtrer les contenus extérieurs, et ce système s’est déjà rentabilisé plusieurs fois.
Il faut aussi noter que la RPC ne consacre pas une part si élevée de son PIB à l’armée.
S’il y a gaspillage, c’est dans le fait que la RPC dépense autant que les États-Unis pour la sécurité intérieure ; et quand on voit à quel point la police américaine est militarisée, ce n’est pas bon signe.
En revanche, les dépenses de défense de la RPC sont inférieures à 2 %, contre environ 3,5 % pour les États-Unis ; même en incluant les estimations de budgets fantômes, on serait autour de 3 % contre 6 %.
Il suffit de voir comment les réseaux sociaux ont abîmé les démocraties partout dans le monde.
La démocratie américaine est, dans une certaine mesure, prise dans une spirale de mort : https://www.theatlantic.com/ideas/archive/2021/04/how-stop-m...
Je n’aime pas la répression, mais la Chine fait ce genre de choses depuis des milliers d’années, et il est désormais difficile d’être sûr que nous avons quelque chose de meilleur. Il y a aussi des exemples comme Citizens United, Roe v. Wade ou l’affirmative action, et l’espérance de vie en Chine vient de dépasser celle des États-Unis.
Les usages sont limités, mais pour transférer des informations vers ou depuis ce type de système, on pourrait utiliser le chaffing and winnowing : https://en.m.wikipedia.org/wiki/Chaffing_and_winnowing
Certaines réactions de gens qui n’ont visiblement jamais mis les pieds dans un pays à accès restreint sont assez drôles.
Il existe sans doute quelques fournisseurs de VPN qui fonctionnent, proches de services de l’ombre approuvés, mais j’ai du mal à croire que ce soit parce qu’ils sont plus intelligents que le GFW.
Je suis convaincu qu’ils sont autorisés, non sanctionnés et surveillés.
Si vous n’avez aucun problème avec le gouvernement, très bien ; mais vous ne savez pas si vous en avez un tant qu’il ne s’est pas réellement produit.
Des choses comme socks5, shadowsocks ou WireGuard sont inutiles depuis longtemps.
C’est un peu comme être dans une maison, invisible de tous, et essayer d’en sortir : quels que soient vos efforts, la tentative elle-même se voit et vous fait prendre.
Sortir du GFW, c’est pareil : le meilleur choix reste un VPN approuvé ou une session RDP qui reste longtemps en place sans être mesurée.
Je ne sais pas si je suis plus malin que le GFW, mais mes outils maison de contournement de la censure ont toujours bien fonctionné, et même les méthodes les plus paresseuses passaient.
Je n’ai jamais utilisé de fournisseur de VPN.
À titre de référence, WireGuard non modifié fonctionne toujours, même s’il semble exister une analyse du trafic hors ligne pour le détecter : environ une fois par semaine, je me réveillais avec la connexion VPN coupée et je devais changer le ListenPort du serveur.
Personnellement, ce qui m’agace le plus, ce sont les coûts de trafic sortant d’AWS, beaucoup trop élevés.
Ils peuvent peut-être savoir qu’on utilise un VPN, mais j’ai l’impression qu’ils ne pourraient pas surveiller le contenu du trafic.
Cet article est bon, mais il entre dans des détails assez techniques.
Il ne parle pas du GFW lui-même, mais des projets comme https://github.com/salesforce/ja3 expliquent comment on peut identifier par empreinte du trafic entièrement chiffré (TLS/HTTPS).
La section « How it works » du README l’explique bien.
Si même des pare-feu open source le font, il serait plutôt étonnant que le GFW ne le fasse pas.
On peut toutefois toujours créer une empreinte à partir des paramètres TLS annoncés en commun, en ignorant l’ordre.
L’article lié mentionne un cas où des connexions Tor-obfs ont été détectées à partir de la liste des suites de chiffrement[2][3].
[1] https://www.fastly.com/blog/a-first-look-at-chromes-tls-clie...
[2] https://gitlab.torproject.org/legacy/trac/-/issues/4744
[3] https://blog.torproject.org/ethiopia-introduces-deep-packet-...
L’algorithme découvert est tellement contre-intuitif que je me demande s’il n’a pas été trouvé par une IA.
En gros, si la première charge utile TCP envoyée par le client satisfait l’une des conditions d’exception, la connexion continue d’être autorisée ; sinon, elle est bloquée.
Les exceptions sont : un ratio popcount/longueur en dehors d’une certaine plage ; les 6 premiers octets ou plus dans la plage [0x20,0x7e] ; plus de 50 % des octets dans cette plage ; plus de 20 octets consécutifs dans cette plage ; ou une correspondance avec une empreinte de protocole TLS/HTTP.
L’objectif est de filtrer le trafic chiffré atypique.
La première règle exploite la propriété IND-CPA de la plupart des chiffrements, pour tuer le trafic qui « ressemble à du hasard », avec environ 4 bits à 1 par octet.
Les règles suivantes sont des exceptions pour du trafic chiffré ou compressé acceptable.
La compression n’est pas IND-CPA, mais elle produit une forte entropie et peut donc déclencher la première règle.
Cette approche peut assez bien fonctionner, et les chercheurs de l’article l’ont confirmé.
Si c’est le PCC, il est très probable qu’il l’ait généré à partir d’une analyse statistique de base, puis ajusté pour ramener les effets secondaires et dommages collatéraux sous un seuil acceptable.
Le niveau correspond à environ 0,6 % du trafic mondial bloqué involontairement.
Si ce sont les chercheurs, l’article décrit en détail l’analyse statistique de base utilisée pour découvrir ces règles.
Dans les données à forte entropie, la distribution des 1 et des 0 converge vers la moyenne, et les données chiffrées ressemblent à des données à forte entropie.
C’est une méthode grossière, mais très efficace à calculer pour du matériel embarqué.
Ex2 à Ex4 traitent comme exceptions le texte ASCII utilisé par de nombreux protocoles non chiffrés, par exemple IMAP, et ce texte peut lui aussi avoir une entropie suffisante pour échouer statistiquement assez souvent au premier test.
Ex5 est nécessaire parce que TLS est par nature chiffré et donc à forte entropie ; HTTP semble aussi être exempté pour éviter de bloquer les uploads compressés, par exemple des images ou des vidéos.
Il n’est pas du tout surprenant que la clé pour contourner le GFW soit une « faible entropie ». Une forte entropie est presque une caractéristique indispensable de la plupart des méthodes de chiffrement.
En théorie, comme le chiffrement n’ajoute pas d’information, on pourrait imaginer un chiffrement qui préserve l’entropie selon plusieurs métriques objectives si l’on ne compresse pas avant de chiffrer ; mais je ne connais rien d’autre qu’une méta-approche consistant à compresser avant chiffrement puis à ajouter un bourrage stéganographique au texte chiffré.
Bien sûr, cela divulgue autant d’information que la négentropie du message, mais il s’agit généralement d’informations impossibles à déduire du contexte, par exemple le simple fait que le message soit du HTML+texte.
Du coup, il suffirait d’encoder TLS en base64 ?
C’était déjà évident il y a 10 à 12 ans.
Quand j’étudiais en Chine, le VPN de l’école ne tenait que quelques jours.
Mais un tout petit logiciel VPN circulait, et, vrai ou faux, je me souviens qu’il était censé venir du Falun Gong en coopération avec la CIA.
À l’époque, il parvenait à éviter la détection, probablement en faisant tourner les IP en permanence.
Ce qui était intéressant, c’est la vitesse à laquelle cet outil s’est diffusé « hors ligne » parmi les étudiants étrangers.
Des Chinois l’avaient aussi, mais il était moins connu parmi eux.
Je ne sais pas s’il fonctionne encore : https://en.m.wikipedia.org/wiki/Freegate
[Edit] Un ancien commentaire HN indiquant qu’il ne fonctionne plus, ainsi que d’autres options elles aussi difficiles : https://news.ycombinator.com/item?id=10101965