La feuille de route du retrait de C tor : dates d'extinction, état d'Arti et ce que les opérateurs doivent surveiller
Le retrait de l'implémentation C d'origine de Tor est passé du principe au calendrier. Le 23 juin 2026, le projet Tor a annoncé son intention de mettre fin à la compatibilité réseau pour Tor 0.4.8 et toutes les versions antérieures : après le 1er septembre 2026, ces versions « ne fonctionneront plus du tout sur le réseau ». L'annonce, adossée au projet Arti Relay en cours, est le signal public le plus clair à ce jour de la façon dont la transition de C tor vers Rust est échelonnée.
Pourquoi Tor est réécrit en Rust
Arti est l'implémentation de nouvelle génération des protocoles Tor en Rust, décrite dans le README du projet comme un effort pour construire une base de code embarquable et de qualité production. Les raisons avancées sont pratiques et non cosmétiques. L'équipe estime qu'au moins la moitié de ses failles de sécurité répertoriées auraient été impossibles dans un langage à sécurité mémoire. La base C, en développement continu depuis 2002, a accumulé ce que le même document appelle des relations spaghetti inutiles entre composants. Et une bibliothèque Rust peut être embarquée dans des applications d'une manière que la conception d'origine, pensée comme proxy SOCKS, n'avait jamais envisagée — de quoi accélérer le travail futur, espèrent les développeurs. Le calendrier de migration a été esquissé en février 2023 par Nick Mathewson, cofondateur de Tor et l'un des architectes principaux d'Arti, dans une discussion tor-dev :À moyen terme, nous déprécierons l'implémentation du client Tor en C. Cela n'arrivera qu'un certain temps après qu'Arti sera un client tor complet avec la prise en charge des services onion, et avec une solution complète d'embarquement/FFI/RPC.À long terme, a écrit Mathewson, Arti doit remplacer entièrement C tor, ce qui exige aussi des relais et des autorités d'annuaire en Rust. Il a souligné qu'aucun calendrier n'était engagé et que toute échéance future semblerait agaçamment longue de certains points de vue et agaçamment courte d'autres. Trois ans plus tard, la séquence se déroule globalement comme prévu : le client achevé en premier, les rôles centraux du réseau en dernier.
Ce qu'Arti sait faire aujourd'hui, et ce qu'il ne sait pas
En tant que client, Arti est en bonne forme. Le README, mis à jour en août 2026, le présente comme un client Tor complet, adapté à un usage général : il fonctionne comme proxy SOCKS, se connecte aux services onion et prend en charge les bridges avec transports enfichables, dont obfs4 et Snowflake. Les versions suivent un rythme régulier. Arti 2.0.0 est arrivé en février 2026, et la version actuelle, Arti 2.7.0, est parue le 1er octobre 2026 avec davantage de travaux de fond sur les relais et les autorités d'annuaire ainsi qu'une série de correctifs de sécurité. Nous avons examiné cette progression côté client plus en détail dans notre précédente couverture d'Arti. Au-delà du client, le tableau honnête est plus mince. Exécuter Arti comme relais ou autorité d'annuaire n'est pas encore pris en charge, comme le stipulent directement les notes de version 2.0.0, et le README relais porte un avertissement permanent : la prise en charge des relais est expérimentale et « pas du tout prête pour un déploiement général », avec consigne de ne pas faire tourner de relais Arti sur le réseau public. La liste interne du projet montre de réels progrès — canaux entrants, gestion de CREATE2 et EXTEND2, écoute sur ORPort — tandis que le contrôle de congestion, la publication des descripteurs, les politiques de sortie et les défenses contre les dénis de service restent à faire. Les services onion sont dans une situation semblable côté service. La documentation du projet indique qu'un service hébergé sur Arti est adapté aux seuls tests et expérimentations : il manque l'autorisation client, les relais vanguard, de véritables protections contre les dénis de service et le padding de circuits, avec l'avertissement que son exploitation pourrait même compromettre la confidentialité des autres usages de la même instance Arti. Se connecter à des services onion depuis Arti comme client relève en revanche du fonctionnement client normal.L'extinction de septembre, expliquée
La coupure du 1er septembre est une mesure de compatibilité, pas une échéance de sécurité. Tor 0.4.8 a déjà atteint sa fin de vie le 1er juin 2026 selon le calendrier des versions du projet et ne reçoit plus de mises à jour. Ce qui change après septembre, c'est le comportement du protocole d'annuaire : la série 0.4.9 retire des données d'annuaire les anciennes clés onion TAP et les lignes de familles de relais, conformément aux propositions 350 et 321, ce qui réduit la bande passante client et accélère l'amorçage pour tous. Comme les clients et relais en 0.4.8 ou antérieur s'attendent à trouver les clés TAP, ils cessent de fonctionner une fois ces champs supprimés. Une motivation secondaire est assumée : l'implémentation d'autorité d'annuaire d'Arti a besoin d'une intégration réseau rapide, et il est plus simple de l'écrire sans champs obsolètes. Ce n'est pas non plus la fin de C tor lui-même. Le même calendrier liste 0.4.9, déclaré stable en février 2026, dont la propre fin de vie reste à décider, ainsi qu'une série 0.5.0 dont la fenêtre de fusion s'est ouverte en mars 2026. L'équipe décrit la maintenance actuelle de C tor comme incluant des fonctionnalités choisies pour faciliter la transition vers Arti. Les projets en aval qui embarquent encore d'anciennes versions sont contactés directement, avec un suivi dans un ticket network-health qui accepte aussi les demandes d'opérateurs ayant besoin de plus de temps.Ce que les opérateurs doivent surveiller
- Opérateurs de relais : passez en 0.4.9.x avant le 1er septembre 2026 ; toute version antérieure sortira du réseau. Il n'existe pas encore de relais Arti vers lequel migrer — traitez toute affirmation contraire avec scepticisme et suivez le changelog d'Arti.
- Opérateurs de services onion : C tor reste la façon prise en charge d'exploiter un service. Les marqueurs qui signaleront la maturité d'Arti côté service sont les pièces manquantes énumérées plus haut : restricted discovery, prise en charge vanguard, défenses contre les dénis de service et padding de circuits.
- Développeurs d'applications : l'état final visé est l'embarquement et RPC plutôt qu'un démon SOCKS empaqueté. Arti 2.0.0 a déclaré expérimentales les API du crate arti de premier niveau, tandis qu'arti-client reste l'interface prise en charge, et 2.7.0 a ajouté le contrôle de configuration par RPC.