Tor, conception, fonctionnement et limites
PAGE EN COURS D'ECRITURE !!!
Tor (Acronyme de "The Onion Router", le routage en oignon), est un réseau mondial décentralisé de serveurs mis à disposition par des bénévoles, et dont l'objectif est l'anonymisation des connexions internet. Il ne faut pas confondre Tor et le Tor browser. Tor désigne le réseau de serveurs. Le Tor browser est un client firefox modifié qui envoie les connexions dans le réseau Tor. L'origine de l'appellation "routage en oignon" fait référence à l'encapsulation des données envoyées ou reçues à l'intérieur de plusieurs "couches" de chiffrement qui sont "épluchées" ou reconstituées au fur et à mesure du trajet dans le cuircuit tor, à l'instar des couches d'un véritable oignon.
Histoire
- A VENIR*
Conception
Généralités
Tor est un réseau mondial décentralisé de serveurs mis à disposition par des bénévoles et dont l’objectif est d’anonymiser les connexions à Internet. Tor est devenu assez populaire depuis les révélations d’Edward Snowen en 2013. En Juin 2017, on estime le nombre d’utilisateurs de Tor à 2 375 000 par jour. La plupars de ces utilisateurs sont situés aux états unis (20,62% du total), aux Emirats Arabes Unis (21,52%, Alors que Tor est illégal là bas, voir chapitre légalité), et en Russie (10,64%). La France arrive en 5ème position avec 4,65% des utilisateurs. L’idée de base, c’est que lorsque votre machine voudra accèder à Internet via le réseau Tor, elle va sélectionner au hasard 3 serveurs (Appelés des relais ou des noeuds) dans ce réseau, elle va chiffrer 3 fois cette requête, et va l’envoyer aux serveurs qui vont la relayer en “pelant” chacun au passage une couche de chiffrement. Il existe donc 3 types de relais, chacun d’entre eux assurant des missions distinctes et ayant des modes de fontionnement différents :
→ Le noeud d’entrée - Noeud Gardien - Bridge → Le noeud intermédiaire → Le noeud de sortie
Tor assure l’anonymat dans un sens (Protection du client), mais pas nécessairement celui du serveur. Par exemple, quand vous vous connectez sur www.psychoactif.org, le serveur n’est pas anonyme puisqu’il est indexé dans les serveurs DNS. Tor permet également d’assurer l’anonymat d’un serveur hébergeant un site web qui sera alors typiquement en .onion (au lieu d’être en .fr .com .org, etc). Par exemple, certains moteurs de recherches tels que duckduckgo (https://duckduckgo.com) peuvent utiliser ce mécanisme (en l’occurence : https://3g2upl4pq6kufc4m.onion/). Un tel site web est alors appellé un “service caché” (sous entendu : dans le réseau Tor) et ne peut pas être tracé. L’ensemble de tous les services cachés est communément appellé le “Deep Web”, bien que cette appellation ne soit pas appréciée par de nombreux hacktivistes qui la jugent trop péjorative. Le nombre de services cachés, c’est à dire la taille du “Deep Web”, est estimée à 60000 à la date d’aujourd’hui (*Date d’aujourd’hui*)
Cette animation montre le flux Tor à travers le monde et au cours des années : https://torflow.uncharted.software/#?ML=34.98046875,31.12819929911196,3&C=ru,RUS
Le noeud d'entrée
Cette catégorie comporte deux sous-catégorie : les noeuds gardiens et les bridges. Dans les deux cas, ce noeud va servir de point d’entrée dans le réseau Tor. Concrètement, votre machine se connectant à Internet via Tor va envoyer la requête au noeud d’entrée, lequel va la transmettre au noeud intermédiaire. La différence entre un noeud gardien et un bridge, c’est que la liste des noeuds Tor (hors bridges) est publique, tandis que la liste des bridges est tenue secrète par le Tor Project. Ceci a pour conséquence que le bridge masque le fait que vous utilisiez Tor auprès de votre FAI ou de toute personne qui se placerait entre vous et le bridge. Si vous utilisez un noeud gardien (ce qui est le cas par défaut), votre FAI verra que vous utilisez Tor et pourra potentiellement vous bloquer (même s’il ne connaîtra ni la destination, ni le contenu de la requête). L’utilisation de bridge est intéressante dans les pays ou Tor est bloqué ou illégal (voir chapitre légalité). Pour utiliser un bridge, il faut en faire la demande au Tor project, qui distribue une ou deux IP de bridges à la demande. Vous pouvez par exemple obtenir des bridges ici : https://bridges.torproject.org/bridges.
Par sécurité, Tor renouvelle le circuit toutes les 10 minutes pour brouiller les pistes et limiter les information qu’un attaquant controllant un noeud pourrait récupérer. Cependant, Le noeud d’entrée, qu’il soit bridge ou gardien, est fixe et ne change que tous les 2 à 3 mois pour un noeud gardien. Ce temps est appellé la “période de rotation”. Le Tor Project est même en train de réfléchir pour faire passer la période de rotation à 1 an. Alors, pourquoi ça ? C’est vrai que ça peut sembler contre-intuitif comme ça. Mais il y a des bonnes raisons :
1 : Supposons qu’un attaquant fasse tourner plusieurs relais en vue d’analyser le traffic pour desanonymiser les utilisateurs de Tor et ce qu’ils font sur internet. Si jamais votre connexion Tor entre et sort par des relais contrôlés par cet attaquant, c’est l’un des pires scénarios qui puisse arriver car il peut faire des corrélations et vous griller (Voir chapitre “vulnérabilités”). Le fait d’avoir un noeud d’entrée (bridge ou gardien) qui soit fixe, et un noeud de sortie mobile, bien que ne changeant pas le risque que ce scénario se produise pour un circuit donné, diminue le risque cumulatif au fur et à mesure que vous changez de circuit.
2 : Supposons qu’un attaquant veuille faire passer les connexions à travers des relais qu’il contrôle. On pourrait immaginer que cet attaquant va faire une attaque DoS (Denial of Service) sur des relais qu’il ne contrôle pas, par exemple en les saturant de requêtes pour les planter. Si le noeud d’entrée n’était pas fixe, l’attaquant pourrait alors augmenter les probabilités que ses machines soient choisies pour concentrer le traffic Tor et l’analyser. Le fait que les noeuds d’entrée soient fixes permet d’éviter ce scénario.
3 : Un noeud ne devient pas bridge ou gardien comme ça. Si un serveur veut acquérir le statut de gardien, il doit remplir certaines conditions, notamment de bande passante, de stabilité, et surtout d’ancienneté. De plus, une fois que le serveur a acquit le statut de gardien, il faudra encore du temps pour que les clients Tor le choisissent en fonction de leurs périodes de rotation respectives.
Le noeud de sortie
Le noeud de sortie est le plus critique des 3 noeuds. En effet, le noeud de sortie va “peler” la dernière couche de chiffrement et va donc avoir accès à la requête en clair, dans laquelle peut se trouver des informations sensibles telle que des identifiants, des mots de passe, des informations personnelles, les fichiers téléchargés, etc. Ca veut dire que même si le noeud de sortie ne connaît pas l’IP de votre machine, vous pouvez quand même être desanonymisé. Pire : il est même théoriquement possible de modifier le contenu, voire de pirater purement et simplement votre machine en y insérant des virus, des backdoors ou d’autre saloperies de ce genre. Le problème se pose aussi pour les sites en https car il est possible de modifier les requêtes pour les rediriger en http. Bref, pour un attaquant (Un pirate ou un gouvernement), contrôler un noeud de sortie, c’est du pain béni.
Pour cette raison, le Tor Project surveille très étroitement les noeuds de sortie. Un projet de recherche appellé “Spoiled Onions” conduit en octobre 2013 et publié en janvier 2014 avait pour objectif de trouver les “oignons pourris” du réseau Tor[1]. Pour celà, ils ont dévelloppé deux outils de scan de noeud de Sortie : Exitmap et HoneyConnector.
Exitmap permet de détecter les manipulations du traffic en établissant une connexion Tor vers un leurre controllé par le Torproject (En sécurité informatique, on appelle ça un “pot de miel”, référence à un véritable pot de miel pour pièger les insectes). On sait ce qu’on envoie dans le réseau, et on regarde ce qui arrive sur le pot de miel. Si le traffic a été modifié, alors ça veut dire que le noeud de sortie modifie les trames réseau.
Honeyconnector permet de détecter le sniffage passif du traffic (C’est à dire la récupération des information sans les modifier). Concrètement, on envoie via Tor un couple unique “identifiant/mot de passe” sur un pot de miel toujours controllé par le Torproject. Ensuite, si une tentative de connexion a lieu ulterieurement sur ce pot de miel, alors on sait que le noeud de sortie par lequel ce couple d’identifiant est passé l’a intercepté.
Ce projet de recherche a mis en évidence 65 oignons pourris sur 1000 analysés, 40 qui modifiaient activement le traffic, 27 qui le sniffaient passivement, et 2 qui faisaient les deux. Le tor project fait régulièrement tourner Exitmap et Honeycollector pour trouver et bannir les oignons pourris. Pour la petite histoire sordide, sachez que cette étude a mis en évidence que les oignons pourris avaient beaucoup de similitudes et qu’on pouvait les classer en groupes. Un de ces groupes était constitué de 20 oignons pourris localisés en Russie qui collaboraient entre eux et étaient contrôlés par la même entité[1]. La même chose a été observé pour un groupe localisé en Inde et un groupe décentralisé[1]. De plus, les attaques ne sont pas systématique, mais avaient des destinations cibles spécifiques. Ainsi, le groupe russe ciblait exclusivement les connexions à Facebook[1]. Ca veut dire que les oignons pourris ne sont pas tenus par des scripts kiddies ou des loups solitaires, mais par des entités organisées qui ont les moyens de faire tourner plusieurs dizaines de serveurs et d’analyser le gros paquet de données qui en résulte.
Le consensus
A la date du 06/06/2017, le réseau Tor comporte 7199 noeuds dont 2439 noeuds gardiens, 814 noeuds de sortie, ainsi que 3541 bridges (non comptabilisés dans ce total)[2]. Cet inventaire est actualisée tous les jours sur le site de Tor Metrics. La liste de tous les noeuds Tor disponibles, à l’exception des bridges, est publique et consultable librement (Voici la référence du consensus du 04/06/2017 à 21h00 contenant les IPs de tous les noeuds disponibles à ce moment [3]).
Un tel nombre de noeud, associé à leur volatilité (Les noeuds peuvent rentrer et sortir à leur gré du réseau, ou changer d’état et passer noeud gardien, ou alors être bannis parce que ce sont des oignons pourris) pose un problème de maintenance. Le Torproject a donc déployé une poignée de serveurs particuliers appellés les autorités d’annuaire. Les IPs de ces autorités d’annuaires sont codées en dur à l’intérieur de chaque client Tor. Elles sont au nombre de 9 :
IP | Nom de code | Localisation |
---|---|---|
171.25.193.9 | Maatuska | Stockolm, Suède |
86.59.21.38 | Tor26 | Vienne, Autriche |
199.254.238.52 | Longclaw | Seattle, USA |
194.109.206.212 | Dizum | Amsterdam, Pays-Bas |
131.188.40.189 | Gabelmoo | Erlangen, Allemagne |
128.31.0.39 | Moria1 | Cambridge, Massachusetts, USA |
193.23.244.244 | Dannenberg | Hambourg, Allemagne |
154.35.175.225 | Faravahar | Washington, USA |
37.218.247.217 | Bifroest | Amsterdam, Pays-Bas |
Le rôle de ces autorités d’annuaire est de maintenir toutes les heures un annuaire de tous les relais Tor disponible. Cet annuaire est appellé le consensus. Sur ces 9 serveurs, 8 gèrent les relais publics et 1 (Bifroest) gère les bridges.
Concrètement, toutes les heures, les 8 autorités d’annuaires vont :
1 : Compiler chacun de leur côté une liste de tous les relais connus, avec leurs informations respectives. En effet, les relais envoient périodiquement leurs données aux autorités.
2 : Calculer toujours séparément des informations relatives à ces relais, et décider si les relais sont “bons pour le service”. C’est notamment à ce moment là que les noeuds peuvent se voir attribuer le statut de gardien, et les oignons pourris recevoir le statut de “Bad Exit”.
3 : Se concerter et voter pour atteindre un consensus au niveau de l’annuaire ainsi créé.
4 : Publier le consensus (l’annuaire) à la disposition de tous les clients Tor.
Du coup, quand votre machine voudra utiliser Tor pour se connecter à Internet, elle va commencer par télécharger le consensus, et elle va établir un circuit aléatoire à partir des informations contenue dans le consensus.
Fonctionnement
Connexion classique non torrifiée
Supposons que vous vouliez vous connecter à www.psychoactif.org. Par exemple, vous rentrez sur un moteur de recherche “psychoactif” et vous cliquez sur le lien correspondant. Votre ordinateur va envoyer l’URL www.psychoactif.org à votre fournisseur d’accès à internet (FAI). Le problème, c’est que le FAI ne sait pas ce que veut dire www.psychoactif.org. Il ne comprend que les IP. Il faut donc qu’il convertisse l’URL en IP. Il fait donc appel pour cela à ce qu’on appelle un serveur DNS (Domain Name Server) via ce qu’on appelle une “Requête DNS”. Un serveur DNS, c’est en gros une sorte d’annuaire qui converti une URL (www.psychoactif.org) en IP (178.33.8.209) avec les informations correspondantes (Hébergé chez OVH). Une fois que le FAI a récupéré tout ça, il envoie à OVH la requête “A.B.C.D (votre IP) souhaite avoir le contenu de 178.33.8.209 qui est chez toi”. Une fois que OVH a envoyé les informations demandées, le FAI transfère les données sur votre poste.
On peut immédiatement voir que :
- Le FAI peut voir ce que vous faites sur internet.
- Le FAI peut, sous décision judiciaire par exemple, refuser de vous fournir le contenu de telle ou telle IP.[4]
- Le FAI peut, sous décision judiciaire ou à des fins publicitaires, modifier les requêtes DNS ou avoir recourt à des DNS menteurs pour vous donner du contenu alternatif sans que l’utilisateur ne s’en apperçoive.
- 178.33.8.209 et par extension, OVH peut voir que vous êtes allé chez lui.
- Si le site n’est pas en https, tout transite en clair sur internet depuis votre ordinateur jusqu’au site que vous contactez. Le FAI, OVH, ou tout pirate placé entre les deux extrémités peuvent donc intercepter vos identifiants et mot de passe, et les donner/revendre à la police. Ce problème ne se pose pas avec Psychoactif qui est en https. En revanche, il se pose avec psychonaut.com.
Connexion à l'internet classique via Tor
Etablissement d'un circuit Tor
Voici ce que fait votre machine quand vous voulez accéder à www.psychoactif.org via Tor :
1 : Télécharger le consensus 2 : Sélectionner aléatoirement un noeud gardien, un noeud intermédiaire et un noeud de sortie à partir du consensus
Une fois que c’est fait, c’est là que ça se complique un peu, parce qu’il va falloir négocier des clés de chiffrement avec chacun des relais de façon anonyme, au moins pour le 2èm et le 3èm. Votre machine va donc :
3 : Récupérer les 3 clés publiques des 3 relais depuis un serveur de clés. Ces clés vont servir pour l’authentification
Négociation avec le noeud gardien
4 : Entamer un handshake avec le noeud gardien. Au cours de cette poignée de main, le noeud gardien va s’autentifier en signant la poignée de main avec sa clé privée (l’algorithme utilisé par Tor est RSA 1024 bits. Tor est actuellement en train de migrer vers une courbe elliptique Curve25519 plus sécurisée)[5]. Le client (votre machine) va vérifier la signature à l’aide de la clé publique récupérée en 3. 5 : Négocier une clé de chiffrement symétrique (AES 128), qu’on appelle une clé de session (Clé1), avec le premier noeud suivant le protocole d’échange de Diffie-Hellman. Le protocole de Diffie Hellman permet de négocier une clé symétrique sans avoir à se l’échanger directement.
Négociation avec le noeud intermédiaire. Un peu plus difficile car il ne faut pas que le noeud intermédiaire connaisse le client.
6 : Handshake avec le noeud intermédiaire (NI) à travers le noeud gardien (NG). Le client envoie une demande de connexion au NG chiffré avec Clé1 en lui demandant de la transmettre au NI. Le NG déchiffre avec la clé de session et découvre qu’il doit transmettre au NI. Le NI répond au NG en signant avec sa clé privée (toujours RSA 1024 ou Curve25519). Le NG chiffre avec la clé de session Clé1 et transmet ensuite au client. Le client déchiffre la réponse avec Clé1 et vérifie la signature. 7 : Négociation de Diffie-Hellman pour une deuxième clé de session symétrique (Clé2), toujours en passant par le NG.
Négociation avec le noeud de sortie (NS). Encore plus difficile parce que le NS ne doit connaitre ni le client, ni le NG, et le NG ne doit pas connaitre le NS non plus.
8 : Handshake avec le NS à travers les 2 noeuds précédents. Le client envoie une demande de connexion chiffrée 2 fois avec Clé1 et Clé2 et l’envoie au NG. Le NG déchiffre la première couche avec clé 1, mais ne peut toujours pas lire le contenu puisqu’il est chiffré aussi avec Clé2 et qu’il n’a pas cette clé. Il envoie donc le contenu chiffré avec Clé2 au NI. Le NI déchiffre avec Clé2 et transmet au NS. Le NS signe et renvoie au NI. Le NI chiffre avec Clé2 et envoie au NG. Le NG chiffre avec Clé1 et renvoie au client. Le client déchiffre avec Clé1 et Clé2 et vérifie la signature avec la clé publique du NS. 9 : Négociation de Diffie Hellman avec le NS.
Echange des données
Supposons que vous vouliez vous connecter à www.psychonaut.com
Votre machine va d’abord établir un circuit Tor comme expliqué ci dessus. Ensuite, il faudrait normalement faire la résolution DNS (Rapellez vous, c’est ce qui permet de convertir psychonaut.com, incompréhensible pour une machine, en adresse IP). Or il n’est pas possible de faire cette résolution DNS soi même pour des raisons évidentes d’anonymat. En effet, celà voudrait dire que vous devriez envoyer la requête (www.psychonaut.com) au FAI pour demande aux serveurs DNS, et le FAI saurait alors quels sites vous visitez. Notez que ce petit problème s’est déjà présenté avec certains utilisateurs de Tor, et surtout de VPN. On appelle ça un DNS leak (fuite DNS). Du coup, impossible de faire la requête DNS. Le client va donc envoyer la requête telle quelle dans le réseau TOR et c'est le NS qui va se charger de la résolution DNS.
Connexion à un service caché
Etablissement d'un circuit
- A VENIR*
Echange des données
- A VENIR*
Vulnérabilités de Tor
Javascript
- A VENIR*
Time pattern
- A VENIR*
Fingerprinting de la souris
- A VENIR*
Légalité
Emirats Arabes Unis
- A VENIR*
Chine
- A VENIR*
Annexe : protocole cryptographique
Authentification du serveur
Algorithme RSA
- A VENIR*
Courbes Elliptiques
- A VENIR*
Echange de Diffie-Hellman
- A VENIR*
Advanced Encryption Standard
- A VENIR*
References
- ↑ 1,0 1,1 1,2 et 1,3 [https://www.cs.kau.se/philwint/spoiled_onions/pets2014.pdf Winter Köwer Spoiled Onions: Exposing Malicious Tor Exit Relays]
- ↑ https://metrics.torproject.org/networksize.html
- ↑ https://collector.torproject.org/recent/relay-descriptors/consensuses/2017-06-04-21-00-00-consensus
- ↑ http://www.europe1.fr/faits-divers/djihad-premier-blocage-d-un-site-pour-apologie-du-terrorisme-2400861
- ↑ https://gitweb.torproject.org/torspec.git/plain/tor-spec.txt