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

Bref historique de Tor

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 ont développé les premiers prototypes d’onion routing. La chronologie du Tor Project indique que la question posée était de savoir s’il « existait un moyen de créer des connexions Internet qui ne révèlent pas qui communique avec qui ». Le réseau utilisé aujourd’hui a été déployé en octobre 2002, et son code a été publié sous une licence de logiciel libre et open source. Le Tor Project, Inc. a été créé en tant qu’organisation à but non lucratif en 2006.

Toutes les dates ci-dessous proviennent de la chronologie publiée par le Tor Project, de ses notes de version ou de ses propres pages d’assistance. Lorsqu’une affirmation est contestée, par exemple concernant le financement du projet, la section indique ce que montrent 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 généralement : votre identité et ce que vous demandez. Votre client Tor sélectionne trois relais et établit un circuit entre eux. Il encapsule votre trafic dans trois couches de chiffrement, 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 a donné son nom au procédé.

Le premier relais, appelé guard, voit votre adresse IP, mais pas votre destination. Le dernier relais, appelé 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 même organisation exploitait votre guard et votre exit, la séparation disparaîtrait et le chiffrement ne vous apporterait plus aucune protection.

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 faire correspondre 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 en même temps. L’article de conception de 2004 écrit par Roger Dingledine, Nick Mathewson et Paul Syverson, « Tor: The Second-Generation Onion Router », le précise 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, et elle explique tout le reste de cette page.

Une organisation militaire ou de renseignement ne peut pas obtenir l’anonymat d’un réseau qui ne transporte que son propre trafic. L’anonymat dépend d’un groupe, pas d’un chiffrement. Si chaque connexion sortant du réseau appartient à un seul 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 chacun pouvait exécuter un relais. Les journalistes, les militants, les chercheurs et les personnes ordinaires qui voulaient éviter un réseau publicitaire sont ainsi devenus le groupe qui protège tous les autres utilisateurs. Dingledine et Mathewson ont exposé cet argument en 2006 dans un article intitulé « Anonymity Loves Company: Usability and the Network Effect », présenté au 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 indicateur marketing.

Du code alpha à 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 maintenir le développement.
• 2007 : le développement des bridges commence, car les firewalls 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 publiés en 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é cassé à cette date. Aucun de ces événements n’a modifié le protocole. En revanche, ils ont tous deux changé 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 fonds 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. Les plus récents couvrent l’exercice 2023 à 2024 et ont été publiés 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 l’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 consulter le code source et un réseau de relais exploités par des tiers. Quelqu’un qui voudrait ajouter une backdoor devrait l’insérer à 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 publient régulièrement des attaques contre Tor. Ils ont tout intérêt, sur le plan professionnel, à trouver 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 exits et les bridges appartiennent à des milliers d’opérateurs sans lien entre eux. La compromission d’un financeur ne compromet pas ces opérateurs.

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 subventions déterminent les travaux réalisés en priorité. 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 est différente de l’affirmation selon laquelle « le code est compromis ». Pour y répondre, consultez les rapports financiers au lieu de vous fier 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 jusqu’à un point de rendez-vous à l’intérieur du réseau. Aucun des deux ne découvre 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, ce qui explique 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 apparaissent dans Tor 0.2.0.7-alpha.
• 19 décembre 2016 : le développement de la version 3 commence dans Tor 0.3.0.1-alpha.
• 9 janvier 2018 : la version 3 est publiée dans Tor 0.3.2.9.

Le remplacement de « services cachés » par « 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, comme un vestige utile. Voici encore 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. Sur un serveur loué, il faut surtout laisser nginx sur la loopback, puis supprimer les fuites qui permettraient de relier l’adresse à votre IP publique. C’est ce que montre étape par étape l’hébergement d’un site .onion sur votre propre VPS.

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 doivent ainsi plus divulguer ces requêtes au DNS public (domain name system). La règle établie est explicite : « 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 la clé publique Ed25519 complète, ainsi qu’une somme de contrôle et un octet de version. L’adresse v3 est plus longue parce qu’elle n’est plus tronquée. L’adresse représente donc désormais l’identité complète du service.

La fin de la prise en charge a suivi un calendrier annoncé :

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

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

Pour l’utilisateur, la conséquence est simple et mérite d’être énoncée clairement. Chaque lien .onion de 16 caractères publié avant 2021 est définitivement inutilisable. Il n’existe aucune redirection. 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 sa nouvelle adresse par un canal auquel leurs utilisateurs faisaient déjà confiance.

Ponts et transports enfichables : la censure évolue constamment

La liste des relais publics est publiée volontairement. Le client peut ainsi choisir son propre chemin au lieu de faire confiance à un serveur pour le choisir à sa place. Cette même liste publiée constitue une liste de blocage prête à l’emploi pour tout pays qui veut empêcher l’utilisation de 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 sur le Web ou par e-mail. Un censeur ne peut pas bloquer des adresses qu’il ne peut pas recenser. Cette ressource existe uniquement parce que des bénévoles continuent d’en ajouter. Exécuter un bridge obfs4 sur un VPS bon marché nécessite seulement quelques directives torrc et une règle de pare-feu, pas un projet à part entière.

Le blocage s’est ensuite déplacé des adresses vers la forme du trafic. La DPI 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 enveloppe 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 seul 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 la ligne Bridge complète 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’innommable, sans en-tête de protocole qu’un filtre puisse identifier. 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 de courte durée exécutés par des bénévoles dans des navigateurs Web ordinaires. L’adresse à laquelle vous vous connectez change donc régulièrement. Il a été intégré à la version stable de Tor Browser dans la version 10.5, le 6 juillet 2021.
• meek fait transiter la connexion par un grand fournisseur cloud. Le trafic semble donc destiné à ce fournisseur, et le bloquer revient aussi à bloquer ce 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 données dans une connexion HTTPS similaire à 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 montre l’évolution réelle de ces 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 est donc important d’être précis. Un VPN (réseau privé virtuel) envoie votre trafic vers un seul serveur exploité par une seule entreprise. Cette entreprise voit votre adresse réelle et votre destination au même moment. Tor fait passer votre trafic par trois relais exploités par des personnes différentes. Aucun relais ne détient donc à lui seul ces deux informations. Ces modèles de confiance sont différents et leurs modes de défaillance le sont aussi. La différence entre un VPS et un VPN explique dans quel cas utiliser chacun.

Si vous voulez un tunnel privé entre des machines que vous contrôlez, et non l’anonymat au sein d’un groupe d’utilisateurs, il vous faut un VPN que vous exploitez 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. Vous n’êtes 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 sur VPS concerne une autre menace : qui peut également accéder à votre machine.

Exploiter un relais est l’autre direction, et le réseau en dépend. Les bridges, les gardes, les relais intermédiaires et les sorties ont tous besoin d’opérateurs. Le guide des relais du Tor Project précise que « l’exploitation d’un relais exige des compétences techniques et un engagement durable ». Les sorties vous exposent à des risques juridiques, car le trafic d’autres personnes quitte Internet avec votre adresse IP et votre fournisseur d’hébergement en sera informé. Lisez ce guide avant d’en démarrer un, et non après.

FAQ

Tor a-t-il été développé 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 construit les premiers prototypes. Tor est la génération suivante, dont la 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 de type 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 lui fournit aucun anonymat, 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 empêcher toute falsification. » Ce qui rend cette affirmation vérifiable, plutôt que de simples promesses, c’est l’organisation qui l’entoure. Le protocole est spécifié publiquement. Les builds de Tor Browser sont déterministes : un compilateur indépendant peut reconstruire une release et la comparer au binaire publié. Les relays sont exploités par des bénévoles, et non par un bailleur de fonds. 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 ?

Il s’agissait d’une adresse de version 2, et les services onion v2 ont été retirés en 2021. Tor a commencé à l’indiquer le 15 septembre 2020, a supprimé v2 du code source dans Tor 0.4.6.x le 15 juillet 2021, puis l’a désactivé dans les releases stables le 15 octobre 2021. Une adresse v2 comporte 16 caractères avant .onion, tandis qu’une adresse v3 en comporte 56. Il n’existe ni 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 la même chose qu’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 fait transiter 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 fournir de l’anonymat face à un observateur qui ne surveille pas l’ensemble 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 transport enfichable et en ai-je besoin ?

Un transport enfichable est une enveloppe 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 simplement faire correspondre ce trafic. Vous en avez besoin uniquement si Tor ne parvient pas à se connecter normalement. Cela signifie généralement que votre réseau ou votre pays bloque Tor. Tor Browser inclut obfs4, snowflake, meek et webtunnel dans un binaire unique appelé lyrebird. Commencez par obfs4, car il s’agit d’un transport qui randomise le trafic et qui fonctionne pour la plupart des utilisateurs. Essayez webtunnel ou snowflake si cette connexion n’aboutit jamais.