4 points par GN⁺ 2025-12-14 | 2 commentaires | Partager sur WhatsApp
  • Le code cœur du réseau Tor est en cours de migration du langage C vers Arti, basé sur Rust
  • Le code C existant présente des vulnérabilités telles que des buffer overflows, des use-after-free et des corruptions mémoire
  • La nouvelle version Arti 1.8.0 élimine les schémas prévisibles grâce à une refonte des délais d’expiration des circuits, ce qui réduit les risques de traçage
  • Une nouvelle commande a été ajoutée pour permettre aux opérateurs de services onion de migrer automatiquement leurs clés de Tor basé sur C vers Arti
  • Cette transition constitue une avancée technique majeure du projet Tor pour améliorer la sécurité et la stabilité

Principaux changements d’Arti 1.8.0

  • Le point central de cette version est l’application d’une refonte des délais d’expiration des circuits (circuit timeout rework)

    • Dans Tor jusqu’ici, le Circuit Dirty Timeout (CDT) contrôlait le moment de fermeture des circuits via un minuteur unique
    • Cette approche était prévisible, ce qui permettait aux observateurs du trafic d’identifier des schémas
    • Arti 1.8.0 introduit des délais d’expiration fondés sur l’usage et des minuteurs individuels, de sorte que les circuits se ferment à des moments aléatoires lorsqu’ils acceptent de nouvelles connexions ou restent inactifs
    • Cela réduit le risque de fingerprinting
  • Ajout d’une nouvelle commande expérimentale arti hsc ctor-migrate

    • Les opérateurs de services onion peuvent migrer des restricted discovery keys depuis Tor basé sur C vers le keystore d’Arti
    • Ces clés sont utilisées pour l’authentification des clients, et la nouvelle commande permet une migration automatique sans intervention manuelle
  • Autres améliorations

    • De nombreux composants internes ont été améliorés, notamment l’architecture de routage, l’implémentation du protocole, la prise en charge du cache d’annuaire et la configuration de l’écouteur de port OR
    • Le détail des changements est disponible dans le journal des modifications officiel d’Arti 1.8.0

Contexte de la transition vers Rust

  • Le réseau Tor fonctionne sur une base en langage C depuis le début des années 2000
  • Mais cette base de code en C a subi des vulnérabilités récurrentes à cause de problèmes de sûreté mémoire
  • Le projet Tor mène donc Arti, un projet de réécriture exploitant la sûreté mémoire de Rust
  • Arti réimplémente les fonctionnalités de Tor en Rust avec pour objectif de renforcer la sécurité, la stabilité et la maintenabilité

Portée technique

  • La transition vers Rust vise à renforcer en profondeur l’architecture garantissant l’anonymat de Tor
  • La suppression des comportements de circuit prévisibles et l’automatisation de la gestion des clés contribuent à améliorer le niveau de protection de la vie privée des utilisateurs
  • Les mises à jour continues d’Arti sont perçues comme un signal d’accélération du remplacement progressif de Tor basé sur C

2 commentaires

 
GN⁺ 2025-12-14
Réactions sur Hacker News
  • J’ai récemment essayé le test Cover Your Tracks de l’EFF et il en est ressorti que seul le navigateur Tor avec JS désactivé résistait complètement au fingerprinting.
    Même Tor avec JS activé n’était évalué que comme « partiellement » résistant, et Firefox ne donnait aucun résultat même avec JS désactivé. C’est assez inquiétant, donc je serais curieux de voir les expériences d’autres personnes.

    • Cet outil a une méthode de mesure de la protection contre le fingerprinting défaillante. Il sous-évalue au contraire les protections qui utilisent la randomisation, et valorise surtout les approches par segmentation (binning).
      À l’inverse, les outils qui ne testent que la persistance, comme fingerprinting.com/demo, posent aussi problème.
      Le vrai signal d’alerte, c’est d’échouer aux deux tests.
    • En testant avec Safari sur macOS, j’ai obtenu le résultat « forte protection contre le pistage web ».
      Cela dit, même si le navigateur Tor est clairement visible, ce seul test ne permet pas vraiment de conclure qu’il est facile de distinguer les empreintes entre utilisateurs de Tor.
    • Le navigateur Tor essaie d’élargir les buckets d’empreintes avec des techniques comme l’arrondi de la taille du canvas. Au final, le bucket le plus large et inévitable reste « utilisateur de Tor » lui-même.
    • En testant sur Debian avec le navigateur Tor en configuration par défaut, j’ai obtenu 8,24 bits d’information identifiante.
      Plus on augmente le niveau de sécurité, plus le nombre de bits identifiants augmente, puis il redescend quand on désactive complètement JS.
      Autrement dit, désactiver JS offre le plus haut niveau d’anonymat.
  • J’aurais aimé que Mozilla poursuive davantage la transition de Firefox vers Rust (oxidizing). Cela aurait aussi été positif pour l’écosystème Rust, ce qui est regrettable.

    • Malgré tout, l’équipe Chrome continue toujours d’adopter Rust.
    • Même après le licenciement massif de développeurs Rust chez Mozilla, la part de Rust dans le code de Firefox a dépassé 12 %. Chromium reste relativement plus bas, à moins de 4 %.
      Si Rust était resté « l’arme secrète » de Mozilla, sa diffusion aurait peut-être au contraire été plus lente.
    • Je pense que l’échec du projet Servo ne venait pas de Rust, mais des limites internes de Mozilla.
  • Si l’usage de Rust les aide à résoudre leurs problèmes, cela me semble être un choix rationnel.
    Un langage est un outil qui s’adapte différemment selon le projet, l’équipe et le problème.

    • Souvent, je trouve plus intéressantes les discussions sur l’optimisation des dépendances ou les améliorations de performances que ces « transitions de langage ».
    • Le billet de blog original ne critiquait pas C, donc je ne pense pas qu’il soit nécessaire de le mentionner à tout prix.
    • Le fait qu’un langage sûr en mémoire soit techniquement supérieur du point de vue de la sécurité est une évidence.
      Ce n’est pas un argument de fanboy Rust, mais un problème de résistance comparable à l’époque où médecins ou pilotes refusaient les check-lists.
    • Rust convient bien à ce cas précis, mais reste inadapté à la plupart des projets UI.
      Pour l’UI, les itérations rapides et le GC sont importants, et les performances le sont moins. Écrire de l’UI en Rust peut devenir un enfer de maintenance.
    • Je n’aime pas l’attitude consistant à dire « réécrivons tout en Rust », mais dans le cas de Tor, Rust est l’outil approprié.
      Tor est un environnement multithread où sécurité et performances sont toutes deux essentielles.
      Zig pourrait aussi être une alternative, mais ce n’est pas encore assez mature. Une approche comme celle de Tigerbeetle, centrée sur le déterminisme (determinism), est également intéressante.
  • Le plus gros reproche fait au projet Tor, c’est sa lenteur. Je ne pense pas qu’un passage à Rust le rende plus rapide.

    • L’onion routing implique un compromis entre vie privée et performances. La latence réseau en est la cause principale.
    • Si Tor est lent, c’est moins à cause du code que du manque de nœuds. La nouvelle version sera surtout plus sûre, pas plus rapide.
    • Le trafic fait l’équivalent de deux fois le tour de la Terre, donc il y a une latence physique inévitable. Au final, c’est la limite de la vitesse de la lumière.
    • Tor sert à garantir l’anonymat, pas à faire du streaming vidéo.
    • Construire un réseau anonyme rapide est extrêmement difficile. Cela dit, Tor est devenu bien plus rapide qu’avant, et rester uniquement dans l’écosystème onion augmente l’anonymat.
  • Cette transition vers Rust a été financée par Zcash Community Grants. Même la R&D crypto peut parfois produire de bons résultats.

    • Cela m’évoque la formule « Pecunia non olet » : l’argent n’a pas d’odeur.
      Avec la blague implicite que les cryptomonnaies sont peut-être pires que l’urine.
  • Je m’inquiète du risque juridique lié à l’exploitation d’un nœud de sortie Tor. Je me demande s’il existe un moyen de ne l’autoriser qu’en mode liste blanche.

    • Le guide officiel pour exploiter un nœud de sortie sur le blog de Tor vaut le détour.
      Si possible, il est recommandé de l’enregistrer au nom d’une organisation, et si l’on veut aider de façon plus sûre, il vaut mieux exploiter un relay.
    • Si vous voulez éviter l’attention juridique, exploiter un bridge est aussi une option.
      Faire tourner un guard relay ou middle relay aide également beaucoup le réseau.
    • Les nœuds de sortie sont compliqués, mais il est aussi possible de donner de la bande passante en hébergeant par exemple des torrents d’ISO Linux ou un serveur de tuiles OpenMap.
      En revanche, il faut bloquer certains ASN chinois. Il y a beaucoup de faux téléchargements.
  • Cette adoption de Rust ressemble à un remplacement des poutres en bois d’une vieille forteresse par de l’acier.
    Le code de Tor basé sur C porte des décennies de compromis de sécurité et de traces d’optimisation, donc une rustification progressive est la manière la plus réaliste d’améliorer la sûreté.
    L’essentiel n’est pas une « réécriture complète », mais la réduction des zones non sûres en mémoire.
    Si seules les parties les plus risquées — parsing, cryptographie, frontières de protocole — passent à Rust, Tor deviendra plus robuste.
    Il sera aussi intéressant de voir si cela évolue vers des transports enfichables basés sur Rust ou un runtime hybride.

  • En réalité, cette décision ne date pas d’hier. Tor a lancé en 2020 le projet Arti, basé sur Rust, et a annoncé Arti 1.0 en 2022.
    L’équipe avait estimé qu’il serait difficile de refactoriser progressivement la base de code en C, et s’est dite satisfaite de Rust sur les plans de la vitesse de développement, de la portabilité et de l’arrivée de nouveaux contributeurs.
    Selon le changelog d’Arti, le développement reste très actif.

    • Arti a été conçu pour pouvoir être embarqué sous forme de bibliothèque dans d’autres applications.
      Par exemple, une application de messagerie pourrait utiliser le réseau sans démon Tor séparé. À mon avis, c’est là le changement le plus important.
    • Certains estiment que le titre est exagéré. L’équipe Tor avance prudemment depuis longtemps.
    • Ce lien est une bien meilleure référence que l’article original. La stratégie y paraît suffisamment claire pour couper court d’avance au débat « pourquoi Rust ? ».
    • Certains s’interrogent aussi sur le fait de savoir si Rust est réellement plus portable entre systèmes d’exploitation que C.
  • Tor n’est pas juste un concept : c’est le nom qui recouvre le protocole (onion routing), le réseau et l’implémentation de référence.

    • L’onion routing est le protocole, et Tor est le réseau et l’implémentation construits dessus.
    • Tor est bien un produit que l’on peut télécharger, composé de plusieurs éléments.
    • Dire qu’on « réécrit Tor en Rust » n’est donc pas vraiment faux.
  • Quelqu’un a suggéré à moitié en plaisantant que compiler Tor avec Fil-C permettrait peut-être d’obtenir la sûreté mémoire gratuitement.

    • Mais cette transition avait commencé avant même l’arrivée de Fil-C.