obfs4, Snowflake ou WebTunnel : choisir un pont Tor en 2026
Quand un censeur bloque les points d'entrée de Tor que tout le monde connaît, la réponse pratique, c'est un pont : un relais tenu à l'écart de l'annuaire public de Tor, associé à un transport enfichable qui change l'allure de la connexion sur le fil. Trois transports portent l'essentiel de cette charge en 2026 : obfs4, Snowflake et WebTunnel. Ils résolvent le même problème — faire ressembler une connexion Tor à du trafic autorisé — mais diffèrent nettement par la manière de les obtenir, leur discrétion et leur vitesse. Mal choisir signifie rarement un échec immédiat ; cela signifie surtout qu'un pont qui fonctionnait hier cessera de fonctionner la semaine prochaine.
Ce que les ponts ont en commun
Le manuel du Navigateur Tor décrit les ponts comme des relais exclus de l'annuaire public de Tor, si bien qu'un censeur ne peut pas les recenser comme il recense les relais ordinaires ; le transport enfichable placé devant le relais se charge du déguisement. Les trois grands types suivent ce schéma, et les trois peuvent être sélectionnés ou demandés depuis les paramètres de connexion du Navigateur Tor, comme le documente la section contournement du manuel avec les options intégrées. L'autre propriété commune est moins rassurante : un pont est une adresse IP comme une autre, et si un censeur la connaît, il peut la bloquer comme une autre. La disponibilité n'est pas l'immunité. C'est pourquoi la distribution fait l'objet de son propre travail d'ingénierie — rdsys, la réécriture de BridgeDB par Tor, existe pour décider quelles lignes de ponts parviennent à quels utilisateurs.obfs4, la valeur sûre éprouvée
obfs4 enveloppe le trafic Tor dans des octets d'apparence aléatoire, sans signature stable, et c'est celui des trois qui affiche la plus longue période de service. La documentation communautaire de Tor résume l'arbitrage en une ligne lorsqu'elle compare les transports : obfs4 est rapide et éprouvé, mais difficile à distribuer. L'aléa tient face à la prise d'empreinte des protocoles, mais l'adresse du pont reste exposée au balayage, et plus une ligne circule longtemps, plus il est probable qu'un censeur l'ait déjà cataloguée. Voilà pourquoi on reproche rarement son débit à obfs4 ; le reproche, c'est que les ponts très utilisés et de longue durée finissent par cesser de fonctionner. Pour un décryptage pas à pas des connexions obfs4, voir notre article précédent.Snowflake, assemblé avec des volontaires
Snowflake emprunte une autre voie vers la survie. Le point d'entrée est un proxy tenu par un volontaire, et le trafic se déguise en WebRTC, la famille de protocoles qui soutient les appels vidéo et vocaux du navigateur. Le site du projet décrit un trafic acheminé par des proxys exploités par des volontaires dans des pays non censurés — un déguisement qui rend l'intervention du censeur coûteuse, puisque le bloquer revient à bloquer les schémas de trafic de la visioconférence quotidienne. L'installation est la plus simple des trois : Snowflake est livré dans le Navigateur Tor comme transport sélectionnable, et le projet recrute de la capacité via une extension de navigateur. Le prix, c'est la performance. Les proxys de volontaires varient en bande passante et vont et viennent, et la documentation communautaire de Tor classe Snowflake comme l'option la plus lente du trio. Attendez-vous à une latence plus élevée et moins prévisible qu'avec un pont dédié, la qualité de chaque session dépendant du volontaire qui la porte à ce moment-là.WebTunnel, Tor déguisé en HTTPS
WebTunnel est le plus récent des trois ; l'implémentation de référence sur le GitLab de Tor date d'août 2022. Il repose sur HTTPT, un protocole de tunnelisation bâti sur HTTP, et la documentation communautaire décrit l'intention sans détour : déguiser le trafic Tor en navigation web HTTPS. Face à l'inspection approfondie des paquets, cela pose au censeur le choix le plus difficile qui soit, car filtrer WebTunnel revient à dégrader le HTTPS ordinaire, le seul protocole que la plupart des réseaux ne peuvent pas se permettre de casser. Les coûts pèsent sur l'opérateur : monter un pont WebTunnel exige un serveur Linux avec accès root, un nom de domaine, des enregistrements DNS, un certificat TLS valide et un proxy inverse comme NGINX, Caddy ou Apache, avec Docker en alternative. La même documentation avertit que les ponts adossés à un domaine coûtent de l'argent et peuvent devenir un point de défaillance unique. Pour l'utilisateur, tout cela n'a aucune importance : un pont WebTunnel arrive sous forme d'une ligne à coller dans le champ prévu.Des attentes réalistes
- obfs4 : le plus rapide et le plus éprouvé. Obtenez de nouvelles lignes via le flux de demande du Navigateur Tor et attendez-vous à ce que les populaires soient bloquées avec le temps.
- Snowflake : installation la plus simple et un déguisement qui surfe sur le trafic des appels vidéo, au prix d'un débit plus lent et plus variable.
- WebTunnel : la meilleure réponse à la prise d'empreinte des protocoles, dépendante d'opérateurs disposés à entretenir domaines et certificats.