Comment les bridges Tor sont distribués : BridgeDB, rdsys, Moat et la logique de la rareté
Un bridge est un relais Tor non publié : il ne figure pas dans la liste publique des relais, si bien qu'un censeur doit le découvrir avant de pouvoir le bloquer. Cette propriété ne tient que tant que le bridge reste difficile à obtenir, ce qui fait du système de distribution lui-même un élément de la résistance à la censure de Tor. En octobre 2024, le Projet Tor a retiré BridgeDB, le système qui distribuait des bridges depuis plus d'une décennie, et a achevé la migration vers rdsys, son système de distribution de nouvelle génération. La manière dont ces systèmes décident qui reçoit quel bridge en dit long sur les raisons pour lesquelles les bridges fonctionnent encore dans les réseaux fortement censurés.
De BridgeDB à rdsys
BridgeDB a été publié il y a plus de onze ans comme un prototype et a fonctionné bien au-delà de sa durée de vie prévue. Selon les ingénieurs à l'origine de la migration, il proposait des demandes par le web, des demandes par e-mail et une API du navigateur Tor appelée Moat, et les trois canaux ont fini sous pression : les censeurs parcouraient les sites de demande de bridges, inondaient le système de messagerie pour récolter des adresses et contournaient les captchas en recourant à des services humains de résolution de captchas. Des années de rustines contre ces tactiques se sont transformées en dette technique ; le projet a donc commencé vers 2020 à développer un remplaçant : rdsys. rdsys, abréviation de resource distribution system, est délibérément plus large que son prédécesseur. Il distribue toutes sortes de ressources de contournement : des bridges Tor, des proxys Snowflake, des points d'accès VPN, voire des liens de téléchargement de logiciels de contournement. Sur le plan architectural, c'est un processus backend qui collecte les ressources et plusieurs processus distributeurs qui les remettent. Le backend tient l'inventaire et attribue chaque ressource à exactement un distributeur ; la tâche du distributeur, comme le dit la documentation de rdsys, est de distribuer les ressources intelligemment, d'offrir une interface utilisable et de contrer les attaques Sybil. Les canaux de distribution
La documentation d'assistance du Projet Tor résume la prémisse sans détour : "Les adresses des bridges n'étant pas publiques, vous devez les demander vous-même." Aujourd'hui, il existe plusieurs canaux parallèles, chacun avec son propre filtrage d'accès. - Moat est intégré au navigateur Tor : l'utilisateur clique sur "Demander des bridges" dans les paramètres de connexion, résout un captcha, et les bridges sont ajoutés automatiquement.
- Le distributeur HTTPS exploite le site web des bridges, qui propose une option en un clic ("Just give me bridges!") à côté de choix avancés comme le type de transport ou des adresses IPv6.
- Le distributeur e-mail répond aux messages envoyés à bridges@torproject.org depuis une adresse Gmail ou Riseup, avec "get transport obfs4" dans le corps du message.
- Le distributeur Telegram sert des bridges via le @GetBridgesBot, avec des commandes comme /obfs4 ou /webtunnel. Pour distinguer les vrais utilisateurs des comptes créés en masse, il pondère l'historique du compte et sépare les anciens comptes des comptes fraîchement enregistrés ; le Projet Tor y voit une réponse à la censure croissante en Russie.
- Lox, encore en développement, est un mécanisme respectueux de la vie privée et fondé sur la réputation : il détecte les bridges bloqués et récompense les utilisateurs dont les bridges restent débloqués.
Il existe aussi deux non-canaux à connaître. Un pool réservé (Reserved) est mis de côté pour une distribution manuelle aux ONG et aux personnes aux besoins particuliers, et les bridges marqués None sont laissés à leurs opérateurs, qui les distribuent à leur guise. Un bridge fraîchement enregistré affiche None pendant environ un jour avant de rejoindre le pool qui lui est attribué. Moat et le compromis du captcha
Moat mérite un examen plus attentif, car c'est la voie que la plupart des nouveaux utilisateurs rencontrent d'abord. Le captcha était la manière dont le système prouvait qu'une demande venait d'un humain et non du robot d'un censeur, et en résoudre un reste le parcours documenté dans le navigateur Tor. Mais l'appréciation du Projet Tor lui-même est sans appel : les captchas sont devenu un mauvais calcul. Ils sont frustrants d'inaccessibilité pour les personnes utilisant des lecteurs d'écran ou des appareils anciens, parfois impossibles à cause des barrières linguistiques, et de moins en moins efficaces puisque les censeurs emploient des outils automatisés ou des services de résolution humaine qui les traversent sans peine. C'est pourquoi rdsys s'éloigne des captchas, et pourquoi Moat est remplacé par le distributeur Settings, une API qui configure automatiquement les paramètres de contournement, y compris le type de bridge à essayer, selon le pays de l'utilisateur. Pourquoi la rareté est l'essentiel
Chaque bridge distribué est un bridge qu'un censeur pourrait apprendre ; la distribution est donc délibérément rationnée plutôt que publiée. Le backend de rdsys ne remet que des ressources dont le fonctionnement est établi : le service bridgestrap teste les transports enfichables de chaque bridge et les marque fonctionnels ou défectueux, un service distinct mesure la bande passante, et chaque bridge Tor est retesté dès que son minuteur d'expiration de dix-huit heures arrive à terme. Les opérateurs peuvent consulter l'état de leur propre bridge via une page de statut publique, par empreinte. Les bridges bloqués ou défaillants sont retirés de la circulation au lieu d'être poussés vers d'autres utilisateurs de la même région, et un mécanisme comme Lox est précisément conçu pour détecter les bridges bloqués et acheminer des bridges neufs vers ceux qui en ont encore besoin. Un problème de recherche ouvert
La tension sous-jacente est ancienne. Dans un article de 2016, les chercheurs à l'origine du protocole TorBricks l'ont formulé sans détour : les méthodes actuelles de distribution des bridges sont vulnérables aux utilisateurs malveillants qui obtiennent des adresses de bridges pour les bloquer. Leur proposition rationnait un budget logarithmique de bridges par utilisateur adverse, afin qu'en présence d'un nombre inconnu de demandeurs contrôlés par le censeur, les utilisateurs honnêtes obtiennent encore un bridge fonctionnel après quelques rounds de communication. Une décennie plus tard, le problème général reste non résolu ; la réponse de rdsys est pragmatique plutôt que mathématique : de nombreux petits canaux, chacun avec ses propres heuristiques, pour qu'aucun scraping ni aucun flood isolé ne vide le vivier. Pour le pendant pratique de cet article, notre guide des bridges dans les régions censurées explique comment les demander et les configurer aujourd'hui. À retenir
La distribution des bridges est un exercice d'équilibre entre joignabilité et rareté. Publier trop librement, et les censeurs collectent la liste ; filtrer trop étroitement, et les utilisateurs légitimes restent dehors. Le passage de BridgeDB à rdsys n'a pas mis fin à cet arbitrage, mais il a rendu le système assez modulaire pour continuer à tester de nouveaux canaux, de Telegram et Lox aux réglages par défaut selon la localisation, à mesure que les anciens s'érodent. Pour les utilisateurs censurés, le conseil n'a pas changé : demandez quelques bridges, testez-les, et préparez-vous à en redemander.
