Histoire de Tor : du routage en oignon à aujourd’hui

L’histoire de Tor, en bref

L’histoire de Tor commence en 1995 au U.S. Naval Research Laboratory, un laboratoire de recherche de la U.S. Navy. David Goldschlag, Michael G. Reed et Paul Syverson y développent les premiers prototypes de routage en oignon. La chronologie publiée par le Tor Project indique que la question posée était de savoir « s’il était possible de créer des connexions Internet qui ne révèlent pas qui communique avec qui ». Le réseau utilisé aujourd’hui est déployé en octobre 2002, avec un code publié sous une licence de logiciel libre et open source. The Tor Project, Inc. est fondé en tant qu’organisme à but non lucratif en 2006.

Toutes les dates ci-dessous proviennent de la chronologie publiée par le Tor Project, de ses release notes ou de ses propres pages d’assistance. Lorsqu’une affirmation est contestée, par exemple concernant le financement du projet, cette section indique les éléments disponibles et où vous pouvez les vérifier vous-même.

Ce que fait réellement le routage en oignon

Le routage en oignon sépare deux informations que l’Internet associe normalement : votre identité et votre demande. Votre client Tor sélectionne trois relais et établit un circuit à travers eux. Il chiffre votre trafic en trois couches, une par relais. Chaque relais retire une couche, ne connaît que l’adresse du prochain saut, puis transmet le paquet. C’est cette superposition de couches qui explique le nom.

Le premier relais, appelé guard, voit votre adresse IP, mais pas votre destination. Le dernier relais, l’exit, voit votre destination, mais pas votre adresse IP. Le relais intermédiaire ne voit ni l’une ni l’autre. Aucun relais ne détient les deux informations, et c’est tout le principe de sécurité. C’est aussi pourquoi les relais doivent être exploités par des personnes sans lien entre elles. Si une seule organisation exploitait votre guard et votre exit, la séparation disparaîtrait et le chiffrement ne vous apporterait plus rien.

La faiblesse connue est la corrélation du trafic. Un observateur capable de surveiller simultanément les deux extrémités d’un circuit peut comparer le moment et la taille des paquets entrants avec ceux des paquets sortants. Tor ne protège pas contre un attaquant capable de surveiller l’ensemble d’Internet simultanément. L’article de conception de 2004 rédigé par Roger Dingledine, Nick Mathewson et Paul Syverson, « Tor: The Second-Generation Onion Router », le précisait dans son modèle de menace.

Pourquoi un réseau privé aurait été inutile

C’est la partie que les résumés courts omettent, alors qu’elle explique tout le reste de cette page.

Une organisation militaire ou de renseignement ne peut pas obtenir l’anonymat avec un réseau qui transporte uniquement son propre trafic. L’anonymat dépend d’une foule, pas d’un chiffrement. Si chaque connexion qui sort du réseau appartient à un même bureau, un observateur qui voit une connexion sortir connaît déjà la réponse. Le chiffrement fonctionne toujours parfaitement. L’anonymat n’existe pas, car personne ne peut être confondu avec quelqu’un d’autre.

L’architecture devait donc être publique et le trafic devait être mélangé à celui d’autres personnes. Le code a été publié sous une licence de logiciel libre en octobre 2002, et n’importe qui pouvait exécuter un relais. Les journalistes, les militants, les chercheurs et les utilisateurs ordinaires qui cherchaient à éviter un réseau publicitaire sont tous devenus la foule qui protège les autres utilisateurs du réseau. Dingledine et Mathewson ont présenté cet argument en 2006 dans un article intitulé « Anonymity Loves Company: Usability and the Network Effect », présenté lors du Workshop on the Economics of Information Security. La conclusion est que la taille et la diversité de la base d’utilisateurs constituent une propriété de sécurité du système. Ce n’est pas un chiffre marketing.

Du code expérimental à une organisation à but non lucratif

La chronologie du Tor Project et les articles qu’il a publiés retracent les étapes suivantes :

• Octobre 2002 : le réseau Tor est déployé, avec un code « sous une licence de logiciel libre et open source ».
• Fin 2003 : le réseau fonctionne avec « environ une douzaine de nœuds bénévoles, principalement aux États-Unis, ainsi qu’un nœud en Allemagne ».
• 2004 : Dingledine, Mathewson et Syverson publient l’article de conception « Tor: The Second-Generation Onion Router ».
• 2004 : l’Electronic Frontier Foundation (EFF) commence à financer les travaux sur Tor.
• 2006 : The Tor Project, Inc. est fondé en tant qu’organisation à but non lucratif 501(c)(3) pour assurer la maintenance du développement.
• 2007 : le développement des bridges commence, car les pare-feu nationaux ont commencé à bloquer la liste publique des relais.
• 2008 : le développement de Tor Browser commence.

Deux dates ultérieures sont importantes pour comprendre l’utilisation actuelle du réseau. La chronologie du Tor Project situe l’utilisation de Tor pendant le Printemps arabe à la fin de 2010, pour protéger l’identité des utilisateurs et accéder aux sites bloqués. Elle indique également que les documents de Snowden de 2013 ont marqué le moment où le rôle de Tor a été largement compris, et précise que ces documents montraient que Tor n’avait pas été compromis à cette date. Aucun de ces événements n’a modifié le protocole. Tous deux ont modifié le profil des personnes qui l’installaient.

Qui finance Tor et comment le vérifier

Le Tor Project répond à cette question sur ses propres pages d’assistance : « The Tor Project is supported by a mix of government grants, private foundations, and individual donors. » Les financements publics en font partie depuis le début. La page des soutiens cite le U.S. Department of State, ainsi que la Ford Foundation, l’Open Technology Fund, Craig Newmark Philanthropies et des entreprises comme Brave, DuckDuckGo, Mullvad VPN et Fastly. Les comptes financiers audités sont publiés sous forme d’articles de blog, le plus récent couvrant l’exercice financier 2023 à 2024 en décembre 2025. Le projet affirme que « talking openly about our sponsors and funding model is the best way to maintain trust with our community ».

La question utile n’est pas de savoir qui a payé. Il faut déterminer ce que cet argent pourrait acheter. Tor n’est pas un service auquel vous vous connectez. C’est une spécification de protocole, un client dont vous pouvez lire le code source et un réseau de relais gérés par des opérateurs inconnus. Une personne qui voudrait ajouter une backdoor devrait l’introduire à l’un de trois endroits. Chacun peut être vérifié.

• Dans le code source. Le client est open source et le protocole est spécifié publiquement. Des chercheurs universitaires publient régulièrement des attaques contre Tor. Ils ont tout intérêt, sur le plan professionnel, à découvrir une faille les premiers.
• Dans le binaire. Les builds de Tor Browser sont déterministes depuis août 2013. Un builder indépendant peut donc reconstruire une release et la comparer octet par octet au téléchargement publié. Un binaire qui ne correspond pas à son code source est détectable sans faire confiance à la personne qui l’a publié.
• Dans les relais. Le Tor Project n’exploite pas le réseau. « The Tor network relies on volunteers to donate bandwidth », et les guards, les relais intermédiaires, les sorties et les bridges appartiennent à des milliers d’opérateurs indépendants. Compromettre un financeur ne permet pas de les compromettre.

La propre déclaration du projet est concise : « Tor has no backdoors. The software is open source, its code can be independently audited, and every release is signed to protect against tampering. » Cette phrase n’a de valeur que parce que chaque proposition désigne un élément que vous pouvez vérifier vous-même.

Il existe une réserve réelle. Elle concerne les priorités, pas l’intégrité. Les financements par subventions déterminent les travaux traités en premier. Le contournement de la censure a donc été financé plus régulièrement que, par exemple, les performances du réseau. Cette critique du projet est légitime. Elle ne revient pas à dire que « le code est compromis ». Pour y répondre, il faut lire les rapports financiers plutôt que faire confiance aux assurances de qui que ce soit.

Les services cachés deviennent des services onion

Un service onion est un serveur qui ne révèle jamais son adresse IP. Le client et le serveur construisent chacun leur propre circuit vers un point de rendez-vous dans le réseau. Aucun des deux ne connaît donc l’adresse de l’autre. L’adresse n’est pas un nom attribué par un registre. Elle est dérivée de la clé publique du serveur. C’est pourquoi une adresse .onion ressemble à une suite de caractères aléatoires.

La chronologie des services onion indique les versions publiées :

• 8 avril 2004 : les services cachés sont implémentés pour la première fois dans Tor 0.0.6pre1.
• 21 septembre 2007 : les services cachés de version 2 arrivent avec Tor 0.2.0.7-alpha.
• 19 décembre 2016 : le développement de la version 3 commence avec Tor 0.3.0.1-alpha.
• 9 janvier 2018 : la version 3 est publiée avec Tor 0.3.2.9.

Le renommage de « services cachés » en « services onion » s’est fait progressivement, et non à une date précise. La documentation du Tor Project utilise encore les deux termes. L’ancien terme décrivait mal la réalité. De nombreux sites onion sont publics, indexés et annoncés. Ce qui est caché, c’est l’emplacement du serveur, pas le site. L’ancien nom subsiste dans le fichier de configuration. C’est un vestige utile. Voici toujours comment déclarer un service dans torrc :

HiddenServiceDir /var/lib/tor/my_service/
HiddenServicePort 80 127.0.0.1:8080

Le répertoire contient les clés du service et un fichier hostname contenant l’adresse. La ligne port associe un port de l’adresse onion à une adresse locale sur la même machine. Le serveur web peut ainsi rester lié à 127.0.0.1 et ne jamais écouter sur une interface publique. La version 3 est utilisée par défaut. Un service créé aujourd’hui avec ces deux lignes obtient donc une adresse v3.

Une adresse onion n’est pas non plus un nom de domaine. La RFC 7686, publiée en octobre 2015, a réservé .onion comme nom de domaine à usage spécial. Les résolveurs ordinaires ne transmettent ainsi plus ces requêtes au DNS public (domain name system). La règle établie est sans ambiguïté : « Les serveurs faisant autorité DOIVENT répondre NXDOMAIN aux requêtes pour .onion. » Comparez cela à la résolution d’un nom de domaine ordinaire : la différence est précisément là. Un nom DNS vous est attribué par un registre et résolu par des serveurs que vous ne contrôlez pas. Une adresse onion est une clé publique. Elle s’authentifie donc elle-même et aucune résolution n’est nécessaire.

Pourquoi les anciennes adresses .onion ne fonctionnent plus

Les deux formats d’adresse ne sont pas compatibles, et l’ancien a été définitivement désactivé.

[
  {
    "version": "v2 (retired 2021)",
    "address_length_chars": 16,
    "service_key": "RSA-1024",
    "address_hash": "SHA-1, truncated to 80 bits"
  },
  {
    "version": "v3 (current)",
    "address_length_chars": 56,
    "service_key": "Ed25519",
    "address_hash": "SHA3-256"
  }
]

Une adresse v2 comportait 16 caractères, car elle ne contenait que les 80 premiers bits du hash SHA-1 de la clé publique RSA-1024. Une adresse v3 comporte 56 caractères, car elle contient l’intégralité de la clé publique Ed25519, ainsi qu’une somme de contrôle et un octet de version. L’adresse v3 est plus longue, car elle n’est plus tronquée : l’adresse constitue désormais l’identité complète du service.

La dépréciation a suivi un calendrier annoncé :

• 15 septembre 2020, Tor 0.4.4.x : Tor commence à avertir les opérateurs et les clients que v2 est obsolète.
• 15 juillet 2021, Tor 0.4.6.x : la prise en charge de v2 est supprimée du code source.
• 15 octobre 2021 : les nouvelles versions stables des clients, pour toutes les séries prises en charge, désactivent v2.

La raison invoquée était d’ordre cryptographique. « À mesure que les connaissances de l’humanité en mathématiques et en cryptographie ont progressé, les fondations de la version 2 sont devenues fragiles et, à ce stade, dangereuses. » En 2021, un hash SHA-1 tronqué à 80 bits et une clé RSA de 1024 bits étaient tous deux en dessous d’un niveau de sécurité raisonnable. De plus, le format d’adresse ne permettait de remplacer aucun de ces éléments.

Pour le lecteur, la conséquence est simple et mérite d’être formulée clairement. Tout lien .onion de 16 caractères publié avant 2021 est définitivement obsolète, et aucune redirection n’existe. Une adresse v2 ne pouvait pas être mise à niveau, car l’adresse était l’ancienne clé. Les opérateurs devaient créer un nouveau service et publier la nouvelle adresse par un canal auquel leurs utilisateurs faisaient déjà confiance.

Ponts et transports enfichables : la censure s’adapte

La liste des relais publics est publiée volontairement. Le client peut ainsi choisir son propre chemin au lieu de laisser un serveur le choisir à sa place. Cette même liste publiée constitue une liste de blocage prête à l’emploi pour tout pays qui souhaite bloquer Tor. Les travaux sur les bridges ont commencé en 2007. Un bridge est un relais qui ne figure pas dans la liste publique. Vous en demandez un petit nombre par le Web ou par e-mail. Un censeur ne peut pas bloquer des adresses qu’il ne peut pas énumérer.

Le blocage s’est ensuite déplacé des adresses vers la forme du trafic. L’inspection approfondie des paquets reconnaît le protocole Tor sur le réseau, quelle que soit l’adresse IP de destination. La réponse a été les transports enfichables : une couche qui modifie l’apparence du trafic Tor sans modifier son fonctionnement. Dans la version actuelle de Tor Browser, ils sont fournis sous la forme d’un binaire nommé lyrebird, qui succède à obfs4proxy. La configuration côté client tient en trois lignes de torrc :

UseBridges 1
ClientTransportPlugin meek_lite,obfs4,snowflake,webtunnel exec [PATH]/lyrebird
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Remplacez [PATH] par le répertoire qui contient le binaire lyrebird. Copiez l’intégralité de la ligne Bridge depuis le site des bridges du Tor Project au lieu de la saisir manuellement. Chaque transport répond à une méthode de blocage différente :

• obfs4 fait ressembler le trafic à quelque chose d’inidentifiable. Il ne contient aucun en-tête de protocole qu’un filtre puisse reconnaître. Tor recommande de l’essayer en premier, car il s’agit d’un transport qui randomise le trafic et qui fonctionne pour la plupart des utilisateurs.
• snowflake vous fait passer par des proxies éphémères exécutés par des volontaires dans des navigateurs Web ordinaires. L’adresse à laquelle vous vous connectez change donc constamment. Il a été intégré à la version stable de Tor Browser dans la version 10.5, le 6 juillet 2021.
• meek achemine la connexion via un grand fournisseur cloud. Le trafic semble ainsi destiné à ce fournisseur, et le bloquer revient aussi à bloquer le fournisseur.
• webtunnel adopte l’approche opposée à celle d’obfs4. Au lieu de ne ressembler à rien, il ressemble à une connexion HTTPS ordinaire vers un serveur Web, en « encapsulant la connexion de charge utile dans une connexion HTTPS de type WebSocket ». Le Tor Project l’a intégré à la version stable de Tor Browser le 12 mars 2024, pour les réseaux qui n’autorisent qu’une courte liste de protocoles.

Cette séquence décrit l’évolution réelle des vingt dernières années. Chaque nouveau transport existe parce qu’une technique de blocage précise a commencé à fonctionner. Les dates de ces releases indiquent donc ce que faisaient les censeurs cette année-là.

Tor n’est pas un VPN, et un VPS non plus

Beaucoup de personnes découvrent Tor après avoir lu des informations sur les VPN. Il faut donc être précis. Un VPN (virtual private network) envoie votre trafic vers un seul serveur géré par une seule entreprise. Cette entreprise voit alors votre adresse réelle et votre destination. Tor fait passer votre trafic par trois relais gérés par des personnes différentes. Aucun de ces relais ne détient donc à lui seul les deux informations. Ces modèles de confiance sont différents et présentent des modes de défaillance différents. La différence entre un VPS et un VPN explique le rôle de chacun.

Si vous voulez créer un tunnel privé entre des machines que vous contrôlez, plutôt que bénéficier d’un anonymat au sein d’un groupe d’utilisateurs, vous avez besoin d’un VPN que vous gérez vous-même. Vous pouvez auto-héberger un VPN WireGuard sur un VPS avec environ quarante lignes de configuration. Cela protège votre trafic du réseau local et de votre fournisseur d’accès à Internet. Cela ne vous rend pas anonyme vis-à-vis de l’entreprise qui héberge le serveur, car vous avez loué ce serveur avec vos propres informations de paiement. La question distincte de la sécurité de l’hébergement VPS concerne une autre menace : qui d’autre peut accéder à votre machine.

Exécuter un relais est l’autre moyen de contribuer au réseau, qui dépend de ces opérateurs. Les bridges, les guard relays, les middle relays et les exits ont tous besoin d’opérateurs. Le guide des relais du Tor Project indique clairement que « l’exécution d’un relais exige des compétences techniques et de l’implication ». Les exits vous exposent à des risques juridiques, car le trafic d’autres personnes quitte Internet avec votre adresse IP. Votre hébergeur en sera informé. Lisez ce guide avant d’en démarrer un, et non après.

FAQ

Tor a-t-il été créé par le gouvernement américain ?

Le routage en oignon a commencé au U.S. Naval Research Laboratory en 1995. David Goldschlag, Michael G. Reed et Paul Syverson y ont créé les premiers prototypes. Tor était la génération suivante. Sa conception a commencé vers 2001 et 2002 avec Roger Dingledine, Nick Mathewson et Paul Syverson. Le réseau a été déployé en octobre 2002 sous une licence de logiciel libre. The Tor Project, Inc. est une organisation à but non lucratif indépendante, relevant de la section 501(c)(3), depuis 2006. L’origine gouvernementale est réelle. C’est aussi la raison pour laquelle le réseau a dû être ouvert à tous : un réseau qui transporte le trafic d’une seule organisation ne fournit aucun anonymat à cette organisation, car chaque connexion qui en sort identifie l’expéditeur par le simple fait qu’il l’utilise.

Le financement public signifie-t-il que Tor contient une backdoor ?

La réponse de The Tor Project est la suivante : « Tor ne contient aucune backdoor. Le logiciel est open source, son code peut être audité indépendamment et chaque release est signée pour se protéger contre toute modification malveillante. » Ce qui permet de vérifier cette affirmation, plutôt que de la considérer comme une simple promesse, c’est l’ensemble des mécanismes qui l’entourent. Le protocole est spécifié publiquement. Les builds de Tor Browser sont déterministes : un builder indépendant peut donc reconstruire une release et la comparer au binaire publié. Les relays sont exploités par des bénévoles, et non par un financeur. Le financement influence bien les travaux réalisés en priorité. Les rapports financiers audités publiés sur le blog de Tor indiquent également l’origine des fonds. Il s’agit d’une question de priorités, pas du code.

Pourquoi mon ancienne adresse .onion ne fonctionne-t-elle plus ?

C’était une adresse de version 2. Les onion services v2 ont été retirés en 2021. Tor a commencé à afficher des avertissements à ce sujet le 15 septembre 2020. La prise en charge de v2 a été supprimée du code source dans Tor 0.4.6.x le 15 juillet 2021. Elle a été désactivée dans les releases stables le 15 octobre 2021. Une adresse v2 comporte 16 caractères avant .onion, contre 56 pour une adresse v3. Il n’existe aucune redirection ni procédure de mise à niveau, car l’adresse était dérivée de l’ancienne clé. L’opérateur devait donc créer un nouveau service et publier la nouvelle adresse.

Tor est-il identique à un VPN ?

Non. Un VPN envoie votre trafic vers un seul serveur exploité par une seule entreprise. Cette entreprise peut voir simultanément votre adresse IP réelle et votre destination. Tor achemine le trafic par trois relays exploités par des personnes différentes. Le premier relay voit votre adresse, mais pas votre destination. Le dernier voit votre destination, mais pas votre adresse. Tor est plus lent. Il est conçu pour assurer l’anonymat face à un observateur qui ne surveille pas l’intégralité d’Internet. Un VPN est plus rapide. Il est conçu pour protéger votre vie privée vis-à-vis de votre réseau local et de votre fournisseur d’accès à Internet.

Qu’est-ce qu’un pluggable transport et en ai-je besoin ?

Un pluggable transport est une couche qui modifie l’apparence du trafic Tor sur le réseau sans modifier le fonctionnement de Tor. Un filtre capable de reconnaître le protocole Tor ne peut donc pas l’identifier de la même manière. Vous en avez besoin uniquement si une connexion Tor classique échoue. Cela signifie généralement que votre réseau ou votre pays bloque Tor. Tor Browser fournit obfs4, snowflake, meek et webtunnel dans un binaire unique appelé lyrebird. Commencez par obfs4, car il s’agit d’un transport randomisant qui fonctionne pour la plupart des utilisateurs. Essayez webtunnel ou snowflake si la connexion n’aboutit jamais.