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. 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é. La même chose a été observé pour un groupe localisé en Inde et un groupe décentralisé. 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. 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). 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 ).

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

Connexion http non chiffrée à www.psychonaut.com sans passer par Tor

Connexion https à www.psychoactif.org sans passer par Tor

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.
• 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). 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

Connexion https à www.psychoactif.org sans passer par Tor

Connexion https à www.psychoactif.org sans passer par Tor

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é

Un service caché est un site en .onion. C'est ce que l'on appelle communément le deep web. L'intérêt d'un service caché réside principalement dans le fait qu'il n'est pas localisable. En effet, c'est l'adresse IP, attribuée par le fournisseur d'accès à internet, qui permet de localiser un site internet. L'accès à un service caché ne fait pas intervenir son IP. De plus, les entités qui ont accès à l'IP (comme le FAI) n'ont pas accès au contenu qui n'est accessible que via le réseau Tor.

Prenons à titre d'exemple le moteur de recherche Grams, inspiré de google (http://grams7enufi7jmdl.onion). Supposons qu'un utilisateur veuille se connecter à ce service caché. Voici comment se déroule l'établissement de la connection.

Etape 1 :

Etape 1

Le service caché va établir quelques circuits et demander aux relais de sortie de servir de point d'introduction (Je n'en ai représenté que deux dans l'exemple). Concrètement, le service caché commence par récupèrer les IP de ces points d'introduction, en l'occurence 198.50.159.155 et 41.231.53.101 (exemples réels d'IP de noeuds de sortie).

Etape 2 :

Etape 2

Le service caché va ensuite demander aux points d'introduction de maintenir la connection. Pendant ce temps, il va établir un circuit TOR vers un Hidden Service Directory (HSDir) et y uploader un descripteur de service caché. En effet, les services cachés ont besoin de signaler leur existence afin d'être contacté. Ce descripteur se compose de :

• Les IP des points d'introduction
• La clé publique du service caché
• La signature des deux éléments précédents, faite avec la clé privée correspondante.

Un HSDir est un relai Tor comme un autre, mais qui va assurer une fonction supplémentaire. Il va recevoir des informations sur les services cachés afin de permettre aux utilisateurs de Tor de les contacter. Un relai acquiert le statut de HSDir via le consensus, au même titre que les noeuds de sortie ou les noeuds gardiens .

Etape 3 :

Etape 3

Supposons maintenant que vous, utilisateur, souhaitiez contacter Grams. Votre machine, après avoir téléchargé le consensus et trouvé dedans les IP des HSDir, va les contacter, toujours en passant par le Réseau Tor. Votre client va télécharger le descripteur de service caché et vérifier la signature. Votre machine connaît maintenant les IP des points d'introduction.

Etape 4 :

Etape 4

Votre machine va maintenant établir un circuit aléatoire. Le noeud de sortie choisi sera le point de rendez-vous. Après avoir établi la connexion, votre machine va communiquer au point de rendez-vous un secret (sous la forme d'un cookie) qui servira à authentifier le service caché.

Etape 5 :

Etape 5

Votre machine va garder la connexion au point de rendez-vous en attente. Elle va ensuite établir un circuit aléatoire vers un des points d'introduction, dont les IP ont été téléchargées depuis le HSDir. Le point d'introduction va ensuite relayer les données jusqu'au service caché.

Concrètement, le client Tor va envoyer au service caché l'IP du point de rendez-vous, la première partie de l'échange de Diffie-Hellman qui servira à négocier une clé symétrique entre le client et le service caché, et le secret qui a été dit au point de rendez-vous. Ces informations sont chiffrées avec la clé publique du service caché (téléchargée depuis le HSDir), et ensuite protégée dans le traditionnel oignon de chiffrement de Tor. Les 3 relais côté client épluchent chacun une couche de l'oignon, et les 3 relais côté service caché en reconstituent chacun une.

Etape 6 :

Etape 6

Le service caché contacte le point de rendez-vous en lui disant le secret qu'il a reçu du client. Ceci permet au point de rendez-vous d'authentifier le service caché.

Etape 7 :

Etape 7

Dernière étape : le client et le service caché s'occupent de la deuxième partie de l'échange de Diffie-Hellman. Ceci aboutit à la création d'une clé symétrique AES qui permettra au client et au service caché de communiquer en chiffré de façon symétrique.

résultat final :

Résultat final.

Voici à quoi ressemble une connexion établie à un service caché. Notez que cette fois, il n'y a pas trois, mais six relais. Quel que soit le sens, les 3 premiers relais épluchent une couche de l'oignon et les 3 dernier en reconstituent une. La présence de six relais au lieu de trois explique pourquoi le deep web est bien plus lent que le web classique.

Vulnérabilités de Tor

Javascript

Javascript est un langage de programmation qualifié de "client side". Concrètement, quand vous vous connectez à un site hébergé sur un serveur, vous êtes le client et le code s’exécutera de votre côté. Javascript est un langage extrêmement répandu sur internet au point que beaucoup de sites internet ne puissent tout simplement pas fonctionner s'il est désactivé.

Javascript est sans doute l'un des points les plus sensibles lorsqu'on utilise Tor. D'un côté, comme on vient de le voir, beaucoup de sites ne fonctionnent pas sans. De l'autre côté, il existe des exploits javascript qui peuvent être envoyés par le serveur pour faire exécuter du code malicieux par votre ordinateur.

C'est de cette façon qu'une vulnérabilité affectant le navigateur firefox qualifiée de critique par Mozilla a été publiée en 2013. Etant donné que le Tor browser est un firefox customisé, il est donc également concerné. Cette vulnérabilité concerne en théorie tous les systèmes d'exploitation, et comme elle permet de faire exécuter du code arbitraire sur votre ordinateur, il est en théorie possible d'en prendre le contrôle.

Concrètement, cette vulnérabilité a été exploitée en 2013 par le FBI pour démanteler un ensemble de services cachés pédopornographiques. L'attaque consistait à faire injecter le code javascript exploitant la vulnérabilité par l'hébergeur de service cachés (en l'occurence Freedom hosting). Ensuite, le code éxécuté par la machine cible de l'utilisateur (le payload) récupérait le nom de la machine et l'adresse mac, et l'envoyait sur un serveur via une connexion non torrifiée, ce qui permettait également de récupérer l'IP réelle .

En 2016, une nouvelle vulnérabilité javascript inconnue à ce jour (On appelle ça une faille 0-day) a été exploitée 2016 pour desanonymyser des utilisateurs de Tor . Aujourd'hui, nous ne connaissons pas encore l'identité des attaquants. Cependant, le payload étant extrêmement proche de celui de 2013, il est possible qu'il s'agisse encore une fois d'une organisation gouvernementale.

Il est cependant très facile de prévenir cette attaque. Il suffit d'interdire le Javascript via le plugin "NoScript" installé par défaut sur le TorBrowser. Cependant, comme expliqué ci dessus, beaucoup de sites du clearweb ne fonctionnent pas sans Javascript. En revanche, à cause de ces vulnérabilités maintenant connues, aucun service caché sérieux n'incluera de Javascript dans le code source de sa page. En d'autres termes, vous pouvez (vous devriez) désactiver Javascript sur le deep web sans vous poser de questions. Si un service caché a besoin de Javascript pour fonctionner, n'y allez pas.

Analyse de traffic

Le concept d’une attaque par analyse de traffic est assez simple. Supposons que deux personnes s’échangent des messages chiffrés et qu’un attaquant surveille cet échange. Etant donné que les messages sont chiffrés, l’attaquant n’a pas accès au contenu. En revanche, la fréquence d’échange des messages ainsi que leur taille sont des indications qui permettent à un attaquant de faire des déductions quant à leur contenu ou leur destination.

Prenons un exemple très concret. Normalement, Tor est censé réactualiser le circuit Tor toutes les 10 minutes. Or il existe quelques exceptions à cette règle : lorsque vous maintenez un échange de données ininterrompu avec un serveur en passant par Tor (par exemple, en téléchargeant ou en uploadant), le circuit ne peut pas être réactualisé pendant l’échange . Supposons que vous téléchargiez vraiment un gros fichier, genre un film de 2h30 en full HD de 10Go sur youtube via le logiciel youtube-dl, et que ça prenne, mettons, 5 heures. Pendant 5 heures, vous allez garder le même circuit (Exemple quasi réel : j’ai déjà de cette façon réalisé des téléchargements qui ont duré plus de 10 minutes). Si un attaquant qui controle des relais Tor voit que le serveur de youtube fait rentrer par un relai un énorme fichier pendant 5 heures, et qu’à un autre endroit, un autre relai envoie à un utilisateur un autre gros fichier pendant 5 heures, il peut raisonnablement en conclure que vous êtes en train de télécharger un film sur youtube (sans pour autant avoir accès au fichier en question). Quant à vous, vous êtes grillés !

Il y a de multiples façons de faire de l’analyse de traffic. La plus simple est par exemple de regarder les demandes de connexions entrantes et sortantes et de les corréler entre elles . Il est également possible de compter les paquets entrant et les paquets sortant. D’autres attaques un peu plus sophistiquées impliquent de router un traffic initié par l’attaquant à travers un relai Tor spécifique et à destination d’un serveur controllé par l’attaquant. Ce traffic va devoir être processé par le relai Tor en question, ce qui va influencer la latence de tous les traffics qu’il doit processer, leur imprimant à tous un pattern de débit. Il suffit ensuite au serveur compromis d’analyser le pattern de débit qui lui est personnellement destiné, et de voir où est ce que ce pattern se retrouve dans le réseau pour en déduire que ces traffics sont passé par ce relai spécifique

Il existe des tas et des tas d’autres façon de faire de l’analyse de traffic. Je terminerai en expliquant une dernière attaque très compromettante. Il s’agit d’imprimer activement des perturbations de débit dans les connexions à destination ou en provenance d’un serveur (comme un site web) en détournant le traffic avant qu’il n’entre dans le réseau Tor. Il suffit de voir ensuite où est ce que ces perturbations se retrouvent pour desanonymiser les gens qui ont contacté ce serveur, y compris à travers Tor. C’est de cette façon que 81% des utilisateurs de Tor peuvent être desanonymisés avec un taux de faux positifs de 6%.

C’est réellement un problème car les solutions qui permettraient de fixer ce problème risquent de gravement nuire à l’utilisabilité de Tor. Par exemple on pourrait imaginer introduire du traffic “parasite” qui serait trié de façon transparente directement par le client et le serveur, mais on augmenterait alors drastiquement la bande passante de Tor. On pourrait également introduire des perturbations aléatoires de débit, mais celà ralentirait considérablement les connexions Tor qui sont déjà réputées être lentes. Cependant, le TorProject a mitigé les résultats de l’analyse par perturbation de traffic en argumentant que 6% de faux positifs, celà peu sembler peu, mais c’est en réalité énorme, suffisemment pour rendre l’attaque inexploitable en tant que tel .

C’est précisément pour cette raison qu’il est dangereux d’utiliser un VPN en entrée du réseau Tor. Malgré ce que peuvent dire les conditions d’utilisation et la politique de confidentialité des prestataires de VPN, vous n’avez que leur seule parole qu’ils ne conservent pas de logs et qu’ils n’analysent pas votre traffic. Tor est un logiciel open source maintenu par le Torproject, une association à but non-lucratif. De plus, le TorProject fait activement la chasse aux relais qui analysent ou interagissent avec le traffic comme on l’a vu dans la rubrique “Noeuds sortants”, et l’analyse de traffic nécessite justement bien souvent de controller au préalable des relais (idéalement, les deux tiers, c’est à dire les relais d’entrée et de sortie). Or les VPN échappent complètement à la surveillance du TorProject et n’ont de compte à rendre qu’à ceux qui font pression sur eux. Le VPN devient donc de fait le maillon faible de la chaîne, ce qui réduit le nombre de relais Tor à controller. Si on prend l’attaque par injection de pattern temporel dans le débit et qu’il y a un VPN en entrée, il n’y a même pas besoin de controller un seul relai pour desanonymiser.

Fingerprinting de la souris

Lorsque vous naviguez sur internet, votre façon de cliquer, de scroller et de déplacer la souris est unique. Ceci est particulièrement vrai lorsqu’on utilise un pavé tactile. Une part dépend de votre matériel (toutes les souris n’ont pas le même nombre de boutons, petit clin d’oeil aux gamers (-; ), et une pârt dépend purement de vous.

Un chercheur a récemment mis en évidence qu’il était possible de récupérer les données relatives à la souris, à ses mouvements et à sa façon d’interagir avec l’unité centrale

Voici une démonstration de ce qu’il est possible de faire (nécessite que javascript soit activé). Allez sur cette page :

http://jcarlosnorte.com/assets/fingerprint/

Cette page a été réalisée par le chercheur en question. Mettez votre souris dans le carré rouge, et scrollez jusqu’à ce qu’elle en sorte. Le premier et le troisième graphique représentent la même chose : en abscisse le nombre de fois où vous avez scrollé, et en ordonnée le temps écoulé entre deux scroll. Le deuxième graphique représente le delta, c’est à dire la quantité de défilement par incrément de scroll. Si vous utilisez une vraie souris, ce nombre est une constante et est souvent égal à 3.

Voici une autre page qui montre ce qu'on peut obtenir comme information :

http://jcarlosnorte.com/assets/ubercookie/

Cette autre page montre d’autres informations qu’il est possible d’obtenir, à savoir la vitesse de défilement de la souris, mais aussi d’autres statistiques annexes comme la position exacte d’un élément en particulier dans la fenêtre ou encore la puissance du processeur. Autant d’éléments qui peuvent servir à vous tracer.

Pour l’instant, cette attaque est purement théorique et n’a jusqu’à aujourd’hui jamais été utilisée en pratique pour desanonymiser des utilisateurs de Tor. Cependant, La preuve de concept apportée par ce chercheur met en lumière une grave faille de sécurité de Tor. Si un attaquant commence à établir des bases de données relative à la souris des utilisateurs sur le clearweb (donc non-anonyme) et fait la même chose pour les utilisateurs de Tor, il peut par corrélation desanonymiser ses utilisateurs.

Et devinez quoi ? Tout ces processus de tracking utilisent… Javascript !!!

Il est donc extrêmement important d’interdire le Javascript à chaque fois que c’est possible, et systématiquement sur le Deep Web.

Faiblesse des clés d’authentification

NB : Ce chapitre nécessite d’avoir lu et compris l’annexe “Protocoles cryptographiques”.

Lors de l’étape d’autentification entre le client et le serveur (c’est à dire le relai), le relai utilise une clé de 1024 bits https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt , ce qui est trop faible et crackable avec un supercalculateur https://www.cs.tau.ac.il/~tromer/papers/tromer-phd-dissertation-11pt.pdf . Concrètement, un attaquant qui arrive à casser ces clés peut usurper l’identité d’un relai Tor et obliger les connexions à transiter par sa machine au lieu du relai Tor légitime. Ceci est du au fait que 90% des relais Tor tournent sur des vieilles version du protocole et ne sont pas mise à jour. Les machines utilisant la version 2.4 du protocole utilisent des courbes elliptiques pour l’autentification, ce qui est plus sécurisé.

De plus, des recherches ont montré que beaucoup de relais Tor ont des vulnérabilités dans leurs clés publiques servant au processus d’autentification. En particulier, des relais Tor possèdent des clés qui partagent certaines caractéristiques mathématiques rendant théoriquement possible la reconstruction des clés privées https://www.cs.princeton.edu/~pwinter/pdf/kadianakis2017a.pdf .

Enfin, et le plus inquiétant, ces recherches ont montré que 122 noeuds utilisaient des clés ne répondant pas aux standards mathématiques imposés par le protocole Tor et normalement codé en dur dans chaque relai. Ces relais Tor ont donc volontairement été modifiés afin de desanonymiser des services cachés. Il a été montré qu’une des cibles était Silk Road https://www.cs.princeton.edu/~pwinter/pdf/kadianakis2017a.pdf

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*