Suport technique et veille technologique

L'Internet en Chine est censuré par un dispositif souvent décrit sous le nom de GFW (Great FireWall). C'est sans doute le dispositif de censure le plus perfectionné au monde. Il a donc été assez étudié mais rarement autant en détail que dans l'excellent article « How Great is the Great Firewall? Measuring China's DNS Censorship », dont les auteurs ont surveillé le GFW sur une longue période.

Le GFW n'a pas une technique unique de censure. Une de ses forces est de combiner plusieurs techniques. L'une d'elles est la génération, par le réseau lui-même (et pas par un résolveur menteur), de fausses réponses DNS. Vous demandez un nom censuré et paf vous recevez une réponse donnant une adresse IP qui n'a rien à voir avec la question posée. Dans la plupart des pays qui censurent avec le DNS, la réponse mensongère est un NXDOMAIN - code indiquant que le nom n'existe pas - ou bien l'adresse d'un site Web qui affichera un message explicatif. Au contraire, les censeurs chinois sont soucieux de brouiller les pistes et renvoient une adresse réelle, ce qui rendra plus difficile de comprendre ce qui se passe.

Voici un exemple. J'interroge l'adresse IP 113.113.113.113, qui est en Chine, sur le réseau de China Telecom. Autant que j'en sache, aucune machine ne répond à cette adresse (testé avec nmap). Si je l'interroge sur un nom de domaine, je n'ai, logiquement, pas de réponse :

% dig @113.113.113.113 A mit.edu
... 
;; connection timed out; no servers could be reached
  

Mais si je l'interroge sur un nom censuré, là, le réseau génère une réponse mensongère :

%  dig @113.113.113.113 A scratch.mit.edu

...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56267
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
scratch.mit.edu.	248 IN A 157.240.6.18

;; Query time: 210 msec
;; SERVER: 113.113.113.113#53(113.113.113.113)
;; WHEN: Tue Nov 09 08:35:29 UTC 2021
;; MSG SIZE  rcvd: 60

  

L'adresse IP 157.240.6.18 appartient à Facebook (normalement, scratch.mit.edu est chez Fastly), exemple typique des mensonges générés par le GFW.

Pour étudier en détail ce mécanisme, les auteurs de l'article « How Great is the Great Firewall? » ont développé le logiciel GFWatch qui permet de faire des études du GFW sur une longue période, entre autres sur les adresses IP renvoyées par le GFWatch.

GFWatch utilise des listes de noms de domaine dans des TLD importants comme .com, augmentées de noms dont on a appris qu'ils étaint censurés (scratch.mit.edu est censuré - cf. exemple plus haut - mais mit.edu ne l'est pas, donc utiliser les listes de noms sous les TLD comme .edu ne suffit pas). Il interroge ensuite des adresses IP en Chine, adresses qui ne répondent pas aux questions DNS (rappelez-vous que les réponses mensongères sont fabriquées par des middleboxes et qu'il n'y a donc même pas besoin que l'adresse IP en question réponde, comme dans le cas de 113.113.113.113). Toute réponse est donc forcément une action de censure. Le logiciel GFWatch stocke alors les réponses. L'article utilise des données de 2020, collectées pendant neuf mois. (On peut voir les domaines censurés.)

Les résultats ? Sur 534 millions de domaines testés, 311 000 ont déclenché une réponse mensongère du GFW. Les censeurs chinois n'ont pas peur des faux positifs et, par exemple, mentorproject.org est censuré, probablement uniquement parce qu'il contient la chaine de caractères torproject.org, censurée parce que les censeurs n'aiment pas Tor.

GFWatch peut ainsi obtenir une longue liste de domaines censurés, et essayer de les classer, ce qui permet d'obtenir une idée de la politique suivie par les censeurs (inutile de dire que les gérants du GFW ne publient pas de rapports d'activité détaillant ce qu'ils font…). On trouve par exemple des domaines liés à la pandémie de Covid-19 (les autorités chinoises ne veulent pas laisser l'information sur la maladie circuler librement).

Une des particularités du GFW est le renvoi d'adresses IP sans lien avec le nom demandé (comme, plus haut, une adresse de Facebook renvoyée à la place de celle du MIT). Quelles sont ces adresses IP ? Combien sont-elles ? Comment sont-elles choisies ? C'est l'un des gros intérêts d'un système comme GFWatch, de pouvoir répondre à ces questions. L'adresse retournée n'est clairement pas prise au hasard dans tout l'espace d'adressage IPv4. Seules 1 781 adresses IPv4 ont été vues par GFWatch, presque la moitié étant des adresses Facebook. Le GFW renvoie aussi des adresses IPv6 :

%  dig @113.113.113.113 AAAA scratch.mit.edu
...
;; ANSWER SECTION:
scratch.mit.edu.	84 IN AAAA 2001::4a75:b6b7
  

Et toutes appartiennent au préfixe réservé pour Teredo (RFC 4380), une technologie désormais abandonnée.

Quant aux adresses IPv4, leur nombre varie dans le temps (de nouvelles adresses apparaissent de temps en temps), et le choix ne semble pas aléatoire, certaines adresses apparaissant davantage que les autres.

Du fait que les réponses mensongères sont générées par le réseau (plus exactement par une middlebox), et pas par un serveur, le GFW brouille parfois les réponses de serveurs légitimes. Plusieurs cas sont cités par l'article, mais je vais plutôt mentionner un cas très récent, le brouillage des réponses du serveur racine k.root-servers.net car le résolveur d'un FAI mexicain a eu le malheur d'interroger l'instance pékinoise de k.root-servers.net et le GFW a donc envoyé ses réponses mensongères. Le point a été discuté sur la liste dns-operations de l'OARC en novembre 2021 et il semble que l'annonce BGP de l'instance pékinoise ait été transmise bien au delà de sa portée voulue (un problème relativement fréquent avec les serveurs anycastés).

L'article montre d'ailleurs que certains résolveurs DNS publics ont reçu des réponses générées par le GFW et les ont mémorisées. Les réponses de cette mémoire ainsi empoisonnée ont ensuite été servies à d'innocents utiisateurs. Bref, on ne répétera jamais assez qu'il faut utiliser DNSSEC (signer les zones, et vérifier les signatures ; les gros résolveurs publics vérifient tous les signatures mais cela ne marche que si la zone est signée).

Comment lutter contre cette censure ? Déjà, l'article note que le GFW est en général « sur le côté » et pas « sur le chemin ». Il injecte un mensonge mais ne bloque pas la vraie réponse. Parfois, celle-ci arrive même avant le mensonge, si le GFW a été lent à réagir. Une solution possible serait donc d'attendre un peu voir si on ne reçoit pas une autre réponse, plus vraie. Certains motifs dans la réponse mensongère (comme l'utilisation du préfixe 2001::/32, normalement inutilisé, pour les requêtes AAAA) pourraient permettre d'ignorer les réponses de la censure. (Vous pouvez voir les adresses retournées par les menteurs sur le site de GFWatch.) Mais, comme dit plus haut, la solution est évidemment DNSSEC, avec un lien sécurisé vers le résolveur validant (par exemple avec DoT ou DoH). Ne vous fiez pas à ce que raconte l'article sur des soi-disant « problèmes de compatibilité », qui ne sont pas détaillés. Mais attention, cela ne résout que la censure du DNS ; le GFW emploie une combinaison de techniques et y échapper n'est pas facile (et peut, si vous êtes en Chine, attirer l'attention de gens assez désagréables et en uniforme).

Vous pouvez aussi regarder la censure chinoise avec un résolveur situé en Chine et accessible via le fédivers, ResolverCN@mastodon.xyz, par exemple voici ce qu'il voyait pour Scratch. Mais ce n'est même pas nécessaire, comme on l'a vu plus haut, donc vous pouvez aussi vous servir du DNS Looking Glass, par exemple en https://dns.bortzmeyer.org/facebook.com?server=113.113.113.113. Dans les réponses ci-dessous, 162.125.32.5 appartient à Dropbox, pas Facebook :