Version du 19 mars 2018 à 17:41

Présentation générale

Description

Logo de Tor

Notre projet s’intitule "Exploration du réseau d'anonymisation Tor" et consiste à découvrir le principe de fonctionnement de ce dit réseau pour ensuite le mettre en pratique et enfin l’analyser en profondeur. Tor (Acronyme de "The Onion Router", le routage en oignon), est un réseau mondial décentralisé apparu en 2002 en version alpha et qui permet de lutter contre la surveillance et la censure. Sous le terme décentralisé se cache des milliers de serveurs mis à disposition par des bénévoles. Ces machines, appelées noeuds, agissent comme des relais pour permettre une anonymisation des connexions internet. Lorsqu’on fait référence à Tor, l’amalgame est souvent fait avec le logiciel Tor Browser, qui lui n’est qu’un navigateur (basé sur Firefox) qui envoie les connexions dans le réseau Tor. L'appellation du protocole “routage en oignon” fait référence à la manière dont les données sont encapsulées puis “épluchées” au cours d’un trajet dans un circuit tor.

Tor est utilisé dans deux situations :

• Accéder au web "normal" : la requête émise par l'utilisateur est transférée jusqu'au serveur ciblé par un circuit composé de trois nœuds.
• Accéder aux services cachés : l'utilisateur et le serveur ciblé s'entendent sur un point de rendez-vous pour communiquer.

Objectifs

Ce projet peut se découper en trois grandes parties. En premier lieu, nous commencerons par un travail bibliographique afin de nous forger des connaissances solides sur le réseau Tor. Suivra une partie où nous mettrons en application notre savoir au travers de trois expériences qui seront : la navigation sur Internet avec le réseau Tor, la création d’un noeud et finalement l’hébergement d’un service caché. La troisième partie sera consacrée à des tests d’efficacité du réseau. Nous visualiserons les requêtes reçues par un serveur web (sous notre administration) lorsqu’on accède à celui-ci via Tor. Nous évaluerons ensuite la vulnérabilité des nœuds du circuit. Enfin, nous nous attaquerons à une autre particularité de Tor, à savoir les services cachés. A nouveau, nous testerons les limites de cette fonctionnalité pour voir par exemple s’il est possible de déterminer la localisation du serveur hébergeant le service. Evidemment, s'agissant d'un projet d'exploration, cette liste d’objectifs est sujette au changement et pourra se voir allongée par la suite, du moins nous l'espérons.

Analyse du projet

Positionnement par rapport à l'existant

A l’heure d’aujourd’hui, quand on parle d’anonymisation, Tor est souvent le seul service évoqué. Bien que ce ne soit pas le cas, il est vrai qu’il possède une place de leader dans son domaine. Ce qui le rend si populaire est sans doute la simplicité des applications gravitant autour de ce réseau, le tout accompagné d’une communauté très active. Pour ne citer qu’un exemple, Tor Browser s’installe en quelques minutes de la même manière que Firefox. Sa seconde force réside dans sa capacité à pouvoir accéder au web "normal" sans que le serveur ciblé ne connaissent l’origine de la connexion. Tor a été conçu pour ce genre d'utilisation, c’est pour cela que les connexions aux services cachés sont plus lentes que sur d'autre réseau d'anonymisation. Mis à part les aspects purement techniques et les raisons ci-dessus, rien d'autre ne pourrait distinguer Tor de ses concurrents.

Analyse du premier concurrent

Logo d'I2P

I2P et Tor sont conçus pour permettre la mise en relation de deux machines sans révéler leur adresse IP réelle et sont donc assez similaire sur le principe. Bien qu’il soit également possible d’accéder au web "normal" avec I2P, ce n’est pas son but premier. Ce réseau privilégie l’utilisation des services cachés, de ce fait il est plus rapide d’y naviguer dessus. En terme de différence technique, on peut citer le fait que les tunnels (équivalent des circuits Tor) sont unidirectionnels contrairement à Tor.

Analyse du second concurrent

Logo de Freenet

Freenet possède quant à lui un autre type d’usage en proposant le partage de fichiers de manière anonyme et résistante à la censure. En effet, contrairement à Tor et I2P, Freenet assure la pérennité des données grâce à une redondance des fragments de fichiers. Freenet est sur ce point similaire au protocole BitTorrent puisqu’un utilisateur téléchargeant un fichier est susceptible de le redistribuer plus tard à condition de toujours l’avoir en cache. En plus de sa bande passante, l’utilisateur est libre d’allouer une partie de son disque dur pour stocker les fichiers du réseau. Un fichier populaire, de par ce procédé, a plus de chance de rester disponible. Pour garantir l’anonymat, un client possède une liste de vingt nœuds qu’il peut interroger. Si aucun des nœuds ne possède ce fichier, ces vingts nœuds interroge à leur tour leurs voisins et ainsi de suite. Ainsi quand le fichier transite vers le client, aucun nœud ne sait si celui qui le précède est le demandeur.

Scénario d'usage du produit ou du concept envisagé

Alice est une journaliste dans un pays où les libertés individuelles sont bafouées, mais elle souhaite partager avec le reste du monde son quotidien en s’assurant que, dans un premier temps son gouvernement ne sache pas ce qu’elle envoie comme information, mais aussi qu’il ne sache pas à qui elle les envoie.

Alice peut donc utiliser le réseau Tor, afin dans un premier temps de crypter sous plusieurs couches SSL son message, mais également en passant par plusieurs noeuds pour brouiller les pistes qui voudraient remonter à elle ou au serveur avec qui elle communique.

Seulement, deux problèmes se posent à Alice, si elle communique avec Bob sur un réseau Tor Web classique, alors tout le trafic entre le nœud 3 et Bob sera en clair (il peut être crypté via https bien évidemment, mais il ne sera pas crypté d’un point de vue Tor), ainsi, on peut lire le contenu du message envoyé à Bob, et le corréler avec le contenu qui trafique dans les nœuds Tor pour remonter à Alice.

Ensuite, les nœuds du réseau sont publics, un gouvernement peut donc très bien en bloquer l’accès, voire pire, le rendre illégal et imposer des sanctions lourdes en dissuasion. Pour régler ce problème, Tor project propose d’envoyer dans un premier temps le software par un média non suspect (CD par exemple), et aussi dans un second temps d’allouer à Alice un bridge, un nœud d’entrée Tor complètement secret, réservé pour l’accès au réseau Tor dans les pays peu libres.

Ainsi, du point de vue du gouvernement qui essaierait de sniffer les paquets envoyés et reçus par Alice, ils ne verraient que du charabia sous SSL entre elle et un serveur qui n’a rien de suspect si c’est un bridge.

Réponse à la question difficile

La question difficile posée durant la présentation orale de notre sujet nous amène à analyser le comportement de Tor concernant le ciblage publicitaire mis en oeuvre par l’utilisation des cookies. Premièrement, il est bon de savoir que ce navigateur n'est qu'un fork du très connu Mozilla Firefox sur lequel il est possible d'utiliser le réseau d'anonymisation TOR. Rien que par ce premier point, on comprend rapidement que le réseau en tant que tel n'est nullement responsable du ciblage publicitaire. Tor n'est qu'un réseau permettant l'acheminement de paquets TCP, paquets pouvant encapsuler entre autres du HTTP/S. Il est donc tout à fait possible de retrouver une en-tête HTTP/S de type Set-Cookie ou Cookie qui permettra dans le meilleur des cas de faciliter la navigation de l'utilisateur ou pire de le cibler. Le ciblage, opéré principalement par les régies publicitaires, utilise ce que l'on appelle les cookies tierce partie. Lorsqu'on se connecte à une page web, notre client effectue des requêtes au serveur web qui sont dites internes quand le domaine correspond à celui sur lequel on se trouve ou tierce partie quand la cible est un domaine différent. Les cookies tierce partie désignent donc les cookies envoyés par ce tiers. Dès lors, peu importe le site consulté, le client sera en état de transmettre des infos d'un site interrogé auparavant à condition qu'ils aient la même régie. Les navigateurs Internet actuels permettent de désactiver les cookies tierce partie et Tor Browser a fait ce choix par défaut, n'autorisant que les cookies internes.

Préparation du projet

Cahier des charges

Choix techniques : matériel et logiciel

Ce projet purement informatique ne nécessite aucun matériel à l'exception d'un serveur connecté sur le réseau de l'école et ayant accès à la ligne SDSL. Du coté des logiciels, nous commencerons par exploiter Tor Browser et Firefox afin de naviguer sur Internet en passant par le réseau Tor. Nous verrons ainsi l'utilité d'utiliser la navigateur de la fondation Tor. Dans un second temps, nous créerons des machines virtuelles sur le serveur Chassiron afin d'ajouter un nœud au réseau Tor ou encore d’héberger un service caché (sur un serveur web tel que Nginx ou Apache). La mise en place de ces machines nécessitera les logiciels Xen (pour la virtualisation) et LVM (pour la création de volume logique). Finalement, nous installerons Tor pour être en mesure de communiquer sur ce réseau que nous contrôlerons totalement, et nous pourrons réaliser divers test (tcpdump par exemple) sur les machines virtuelles.

Concernant la partie analyse et sécurité, Wireshark ou tcpdump se révéleront être des outils pratiques pour analyser les paquets reçus sur une interface réseau.

Liste des tâches à effectuer

• État de l'art technique : les recherches documentaires s’effectueront tout au long du projet mais beaucoup d'importance y sera consacré dans un premier temps. 🔨

• Installation de Tor Browser et comparaison avec un Firefox classique. ✅

• Création et configuration d'un machine virtuelle connecté sur la ligne SDSL. ✅

• Ajout d'un nœud au réseau. ✅

• Installation d'un serveur web sur une autre VM pour héberger un service caché. ✅

• Mise en place d'un réseau privé Tor pour avoir la main sur l'ensemble de la chaîne de transmission. 🔨

Calendrier prévisionnel

Faire un Gantt

Réalisation du Projet

La segmentation en semaine ne se prêtant pas très bien à ce genre de projet, nous avons choisi de rester synthétique dans cette partie. Tous les points sont ou seront évidements explicités dans la suite de Wiki, ce listing permet juste de faire une chronologie des tâches effectuées et de décrire les problèmes rencontrés accompagnés de réponses courtes.

Feuille d'heures

Prologue

Nous avons passé de nombreuses heures à nous documenter et à rassembler des documents sur le design de Tor.

Semaine 1

Après des explications sur l'architecture réseau de l'école et plus précisément celle du serveur Chassiron, nous avons débuté l'installation de notre première machine virtuelle. Notre curiosité nous a ensuite amené à nous documenter sur la virtualisation en général, sujet passionnant au passage. Quelques commandes après, notre machine était prête. S'en est suivi une étape de configuration permettant de connecter notre VM à ligne SDSL.

Semaine 2

• Configuration de la carte réseau virtuelle de la VM pour se connecter à la ligne SDSL
• Installation de quelques paquets : Lynx, TCPdump
• Installation d'Apache2
• Installation de Tor Browser sur tutur02
• Comparaison Tor / Web classique avec Wireshark
• Mise en place d'un service caché sur la VM

Semaine 3

• Problème : le serveur web de la VM est accessible de l'extérieur du réseau Lille 1 mais pas de l'intérieur (problème indépendant de notre volonté et résolu dans la semaine)
• Documentation en liens avec Tor et la sécurité. Nous avons trouvé beaucoup de publications sur : https://www.freehaven.net/anonbib/
• Mise en place d'un nœud public sur une VM.

Semaine 4

• Analyse des trames émises / reçues avec Wireshark
• Comparaison Tor Browser / Firefox classique en passant par Tor : Fuites DNS si l'on oublie de rediriger les requêtes DNS par le proxy SOCKS
• Lecture d'articles de recherche

Semaine 5

• Lecture de documentation sur la création de circuit
• Recyclage de 3 VMs sur Chassiron pour bâtir le réseau privée Tor. Deux seront des nœuds et la troisième sera à la fois un nœud, un serveur web et un directory server
• Passage des IPs en static : 172.26.145.31-32-33
• Installation de Tor sur les 3 VMs
• Mise en en place du directory server, du relay et serveur web apache2 sur grolem
• Configuration du relay sur grodoudou et goupix en spécifiant l'adresse du directory server (grolem)
• Le réseau est en place, manque plus qu'à configurer le torrc du client, une tutur par exemple

Semaine 6

• Le client est configuré mais doit néanmoins être considéré comme un nœud (à comprendre)
• Lecture du Tor Design
• Problème au niveau de l'implémentation du réseau privé (non résolu)
• Le client communique bien avec le processus Tor sur le SocksPort 9011 comme configuré
• Le client communique avec le Directory Server sur le port 7000 mais jamais avec un nœud sur le port 5000 (wireshark)
• En revanche, le nœud Grolem effectue des connexions avec deux autres nœuds
• Pourquoi un tel manque de sens ?

Semaine 7

Sockets ouvertes (nœud public)

Nous rencontrons les mêmes problèmes que durant la semaine 6 à savoir le client n'arrive toujours pas établir un circuit. En revanche les nœuds du réseau entretiennent une connexion TCP entre eux ce qui selon nous est insensé si le réseau possède des milliers de nœuds. On a également remarqué que chaque nœud écoute sur un port UDP mais aucune documentation nous a éclairé sur l'utilité de ceci. Pour comparer avec un nœud public, nous avons relancé notre première VM (DurotDuq). Comme la capture d'écran le montre, nous remarquons que notre nœud est bel et bien utilisé par le réseau (écoute sur le port 9001 et connexion avec des IPs qui sont des nœuds). Nous faisons donc parti de quelques circuits mais nous n'avons pas de milliers de connexions établies. De plus, Tor n'écoute sur aucun port UDP. Nous essayerons de tirer au clair ces différences la semaine prochaine.

En parallèle nous continuons à nous documenter, notamment sur le rôle des deux paires de clés privés/publiques par nœud, sur le protocole TLS et les certificats numériques.

Semaine 8

Pour revenir sur le port UDP ouvert, nous avons eu un début de réponse sur le Stack Exchange de Tor qui nous disait de regarder au niveau des requêtes DNS. Il s'avère que notre nœud public (ne pouvant pas être utilisé en sortie d'un circuit) n'écoute pas sur un tel port. En revanche, nous n'avons pas imposé cette politique de sortie sur les VMs du réseau privé. On en déduit que par défaut les nœuds ouvre un port UDP pour résoudre les domaines dans l'éventualité où il serait utiliser en sortie. Étrangement, et sans rien avoir changé, les nœuds n'établissent plus de connexion TCP entre eux. Ce résultat est rassurant et rentre en concordance avec les documents étudiés. Ce comportement semble néanmoins être celui du réseau il y a quelques années comme expliqué dans le Tor Design.

Sockets ouvertes (Réseau privé)

Le nombre de nœuds ayant explosé, le fonctionnement a du être changé afin d'éviter des milliers de connexions TCP établies. Nous avons également fait des recherches sur le protocole TLS employé pour les échanges client-nœud et nœud-nœud. Nous avons par la suite cherché les raisons de son utilisation. Celle-ci est claire pour la partie "création de circuits" en revanche nous avons encore quelques interrogations sur son utilité quand il s'agit de transmettre des données par le circuit.

Notre réseau privé Tor a toujours un comportement étrange :

Les machines semblent se parler alors que nous ne demandons pas de création de circuit, et le routage des messages au travers Tor semble étrange.

Nous nous sommes rendus compte que les machines virtuelles ne font pas tourner la même version de Tor malgré une installation à la même période. Il s'agit d'une piste de réflexion à creuser pour la semaine prochaine.

Suite à une incompréhension du comportement de notre réseau privé, et après de la lecture sur Internet, nous nous résolvons à utiliser Chutney pour la semaine prochaine, qui est vivement conseillé.

Cette semaine, encore plus de documentation a été réalisée sur Diffie-Hellman et TLS suite à une compréhension partielle antérieure.

Semaine 9

Au vu des problèmes que nous rencontrons pour mettre en place le réseau privé, nous avons commencé à nous intéresser à l'alternative Chutney. Conjointement nous sommes en train de rédiger une partie du wiki sur le protocole TLS que nous pensons nécessaire pour la compréhension globale de Tor.

Travail réalisé

État de l'art

Présentation générale

Rédaction en cours

Le routage en Oignon (dont Tor n'est qu'un exemple d'implémentation) est un réseau de surcouche distribué avec l’objectif d'anonymiser les applications basées sur TCP comme la navigation sur le web, les connexions SSH, et les discutions instantanées. Le client qui souhaite utiliser l'application à travers un routage en Oignon doit choisir un chemin à travers le réseau pour y construire un circuit, en pratique dans le cas de Tor, le client passera par trois nœuds (ou routeurs oignon), chaque nœud connaît son prédécesseur et son successeur, mais aucun des autres nœuds dans le circuit, si bien que le circuit réalisé au sein de Tor est semblable à une liste chaînée. Chaque nœud passant le message de son prédécesseur à son successeur.

Les messages circulent sur le réseau au travers de cellules de tailles fixes dont nous discuterons plus tard. Le message est déchiffré couche par couche à chaque passage d'un nœud avant de passer au suivant, d'où la présence du nom "oignon" pour l’analogie de l’épluchage.

Tor n'est pas le premier logiciel à utiliser le routage en Oignon. En vérité Tor, sorti en 2002, est le routeur oignon de seconde génération, succédant au routeur oignon original qui n'a jamais été utilisé pratiquement, seulement en théorie et pour des tests. Tor a apporté beaucoup au routage en Oignon, y compris ses heures de gloires, comme l'indique sa popularité. Mais aussi beaucoup de fonctionnalités qui n'existaient pas avant, comme les serveurs d'autorité, le contrôle de congestion, le contrôle d'intégrité ou encore des politiques pour les nœuds de sortie. Il apporte aussi un élément important jusque-là absent du routage en Oignon : les services cachés, dont nous parlerons plus tard.

De plus, d'autres réseaux de surcouches ayant pour but l'anonymat existent, comme nous l'avons évoqué dans l'introduction, ils ont des approches différentes, bien que l'idée de faire "rebondir" la connexion en la chiffrant avec différentes couches est tout de même assez commune. Dans le monde des réseaux d'anonymat, Tor fait partie de ceux à faible latence, ce qui lui permet de supporter la navigation sur internet, tandis que d'autres à haute latence ne permettent que des choses peu "temps réel", comme l'envoi de mail ou le partage de fichier.

Il faut tout de même savoir que la faible latence a un coût, elle implique que le réseau soit robuste aux attaques passives et actives que nous verrons par la suite. Mais toujours est-il qu'un réseau à faible latence attire plus d'utilisateurs, et plus d'utilisateurs implique plus de nœuds, donc plus de sécurité. C'est d'ailleurs la raison pour laquelle Tor se veut très portable et utilisable, l’équipe du Tor Project tiens absolument à ce que Tor soit standard, et qu'il ne nécessite aucun patch de noyau. Tor fonctionne sur le réseau Internet tout à fait classiquement et utilise plus précisément sur les streams TCP. Il faut noter qu'il existe des réseaux d'anonymat qui fonctionne sur les protocoles applicatifs, comme Crowds qui utilise HTTP, ou même directement sur IP. Tor Project se place donc au milieu, il a le défaut de ne supporter que TCP, mais il n'a pas besoin de patch noyau pour faire fonctionner des protocoles inconnus des développeurs, et il permet de plus une flexibilité pour toutes toutes les applications basées sur TCP (ce qui n'est pas non plus négligeable).

Tor fonctionne grâce à deux routines, l'une coté client appelée le proxy oignon qui se charge d’interroger les serveurs répertoires afin d'avoir le consensus périodiquement, à établir des circuits au travers du réseau, et à gérer les connexions requises par les applications de l'utilisateur, et l'autre coté noeud se connecte aux destinations requises, relaie les données, et réponds aux requête de Diffie-Hellman (cf Annexe).

A propos des serveurs d'autorités, appelés aussi serveurs répertoires, il s'agit de serveurs de confiances dont le but est de communiquer à qui souhaite l'entendre le consensus, qui est le fichier qui contient l'ensemble des informations sur le réseau Tor, à savoir la liste des nœuds, leur adresse ip, leur clef publique d'identifiant, ainsi que leur politique de sortie si il s'agit d'un nœud de sortie. Il est donc important de noter que les noeuds du réseau Tor sont divulgés publiquement ! Ce n'est pas le cas des bridges que nous verrons plus tard.

Cellules

L'unité de communication au sein du réseau Tor sont les cellules, il s'agit d'une trâme de 512 octets de long, avec un en-tête (on vient rajouter une encapsulation à TCP/IP, on encapsule l'application TCP, HTTP par exemple, dans une cellule Tor). En fonction du bit CMD, une cellule est soit une cellule de données, soit une cellule de contrôle. Dans le cas de cellule de contrôle, elle sera interprétée par le routeur Oignon qui la lira, en cas de cellule de données, elle sera juste transmise et servira de communication point à point au sein du réseau.

Les cellules de contrôle plusieurs rôles, elles peuvent être utilisées pour créer un nouveau circuit, faire du remplissage (padding) afin de garder la connexion active, ou bien décruire un circuits.

Les cellules de relai quand à elles ont une en-tête supplémentaire, comportant un ID de stream servant à identifier le stream correspondant au message ( car plusieurs streams TCP peuvent avoir lieu sur le même circuit ), un checksum pour vérifier l'intégrité du message à chaque noeud, la longeur des données, ainsi qu'une commande de relai.

Noeuds

Chaque noeud possède une clef d'identifiant à longue durée de vie, et une clef oignon à courte durée de vie. La clef d'identifiant sert à signer les certificats TLS et le "router descriptor" ( un ensemble d'informations tels la clef publique oignon, de son adresse ip, de sa bande passante, de sa politique de sortie ). Le "router descriptor" sera envoyé aux serveurs repertoires, qui l'enverront à leur tour aux clients.

La clef oignon est utilisée pour decrypter les requetes des utilisateurs désirant établir un circuit et négocier des clefs de session.

Établissement d'un circuit

A relire

Établissement du circuit tor

Le proxy oignon du client va tout d'abord devoir négocier des clefs symétriques avec les trois nœuds du circuit qu'il souhaite créer. Pour se faire, les clefs vont être négociées les unes après les autres.

Tout d'abord Alice va envoyer une cellule de contrôle à un routeur oignon Bob, la cellule de contrôle aura pour commande de créer un circuit, la donnée de cette première cellule contiendra la première moitié de l’échange de clef Diffie-Hellman entre Alice et Bob, et cette donnée sera encryptée en TLS grâce à la clef publique de Bob. Ainsi, seul Bob avec sa clef privée peut déchiffrer le message et donc il n'y a pas d'usurpation d'identité. Bob répond avec une cellule de contrôle "created cell", contenant sa partie du Diffie-Hellman, ainsi qu'un hash de la clef symétrique. Ainsi Alice peut comparer la clef symétrique qu'elle obtient, la hasher, et la comparer avec la clef symétrique que Bob a obtenu, si il n'y a pas eu d'erreur, les clefs sont identiques, alors le hash également. Il s'agit ici d'une procédure permettant de verifier qu'Alice et Bob se sont bien mis d'accord sur la clef symétrique à utiliser.

Une fois que le circuit C(AB) a été crée, Alice et Bob peuvent s'envoyer l'un et l'autre des cellules de relai cryptées avec la clef symétrique précédemment calculée. (En réalité la clef symétrique calculée va être utilisée pour recalculer deux clefs symétriques, une pour encrypter de Alice vers Bob et l'autre dans le sens contraire).

Pour étendre le circuit formé, Alice envoie à Bob une cellule de relai avec une commande "extend cell", spécifiant dans les données l'adresse ip du prochain routeur oignon, qu'on appellera Carole, et une moitié de Diffie-Hellman. Bob va copier cette moitié dans les données d'une cellule de controle "create cell" qu'il va passer à Carole. Carole répondra de la même manière que Bob a répondu précedemment, avec une celulle de controle "created cell". Bob va transferer les données de cette cellule de controle dans une cellule de relai "extended cell", et la transferer à Alice.

Echange de clefs Diffie-Hellman

Principe simplifié de l'échange de clefs Diffie-Hellman

Lorsqu'on veut sur internet communiquer de façon chiffrée, il faut une clef de chiffrement, seulement il se pose le problème de savoir comment cette clef de chiffrement est envoyée, car si elle circule sur le réseau en clair, une simple attaque passive de "man in the middle" (MITM) permet de récuperer la clef de chiffrement et donc d'intercepter et de décrypter les données échangées. C'est un vrai problème d’œuf et de la poule, il faut du chiffrement pour pouvoir échanger la clef de chiffrement.

Ce problème est réglé grâce à l'échange de clefs Diffie-Hellman, il s'agit d'une manière pour Alice et Bob de se mettre d'accord sur la même clef de chiffrement symétrique, en échangeant des informations en amont afin de pouvoir calculer la clef. Sans qu'Eve ne soit capable de connaître la clef même en écoutant le trafic. Plus simplement, on peut vulgariser ça en deux personnes qui crient au milieu d'une foule, les deux personnes se sont mises d'accord sur une chose commune, mais il est impossible pour la foule de deviner ce dont les deux personnes se sont mis d'accord. Ce "miracle" nous vient de Whitfield Diffie et Martin Hellman en 1976. Et c'est la base de tout chiffrement sur le web (HTTPS, SSH, SFTP, etc...).

Le principe est le suivant :

1. Alice choisit un nombre premier p et une base g, dans notre exemple p = 23 et g = 3 (g est connur d'Alice et de Bob)
2. Alice choisit un nombre secret, a = 6
3. Alice envoie à Bob A = g^a [mod p] = 3⁶ [mod 23] = 16
4. Bob choisit à son tour un nombre secret b = 15
5. Bob envoie à Alice la valeur B = g^b [mod p] = 3¹⁵ [mod 23] = 12
6. Alice peut maintenant calculer la clé secrète : (B)a [mod p] = 12⁶ [23] = 9
7. Bob fait de même et obtient la même clé qu'Alice : (A)b [mod p] = 16¹⁵ [23] = 9

Alice et Bob se sont bien mis d'accord sur la même clef sans la faire transiter en clair.

Malheureusement, cette méthode d'échange ne permet pas de se prémunir des attaques actives d'un MITM. En effet, cette tierce personne va servir de relais entre Alice et Bob. Autrement dit, une clé symétrique K1 sera négocié entre Alice et Eve et une autre K2 entre Bob et Eve. Ainsi, quand Alice parlera à Bob (en chiffrant son message avec K1), son message sera en fait reçu et déchiffré par Eve avant d'être à nouveau chiffrer avec K2 et transmis à Bob qui sera en mesure de le déchiffrer. Donc Alice et Bob pense se parler directement et ignore complètement l'attaquant interposé dans leur communication. Nous verrons dans le paragraphe suivant qu'il est possible de garantir l'authenticité de la réponse obtenue au moyen d'un protocole très connu dans son application au web ; il s'agit de TLS.

Le protocole TLS

Changer le screenshot

Ajouter des captures Wireshark

Handshake TLS

Nous avons vu que les échanges entre deux nœuds successifs s'effectuent toujours au moyen d'une connexion TLS (Transport Layer Security). Avant d'expliquer la nécessité d'une telle connexion, il est nécessaire d'expliquer brièvement son fonctionnement sans non plus s'attarder sur tous les détails. Nous connaissons d'avantage ce protocole sous le nom de SSL (Secure Sockets Layer) qui n'est ni plus ni moins que son prédécesseur aujourd'hui désapprouvé par l'IETF dans toutes ses versions. En plus de garantir la confidentialité des données grâce à l'utilisation d'algorithme de chiffrement, son usage permet également l'authentification du serveur vis à vis du client ainsi que l'intégrité des données échangées. Pour éviter les longues phrases, prenons un exemple de communication entre Bob et Alice.

Nous considérons dans cet exemple la suite cryptographique : TLS_DHE_RSA_WITH_AES_256_CBC_SHA.

Ce qui signifie qu'on utilise l'algorithme DHE pour l'échange de clés, RSA pour l'authentification, AES (256bits) en mode CBC pour le chiffrement par bloc et enfin SHA256 pour le calcul du MAC. Nous reviendrons évidemment sur tous ces termes dans la suite mais il était important de stipuler cette donnée dès maintenant car elle influencera l'échange.

1. Alice (le client) souhaite communiquer de manière confidentielle avec Bob (le serveur). Elle envoie pour cela un Client.Hello contenant une liste de suite cryptographique (plus connu sous le terme anglais de cipher suit) rangée par ordre de priorité décroissant, la version de TLS utilisée ainsi qu'un mot de 32 octets généré aléatoirement.
2. Bob fait de même est envoie pour commencer un Server.Hello contenant la suite cryptographique retenue (il essaye dans la mesure du possible de prendre la suite favorite du client), un mot de 32 octets aléatoire et un identifiant de session. Ce paquet contient également le certificat électronique X.509 du serveur qui est pourvu de différentes informations comme les dates limites de validité, l'algorithme de signature du certificat, le type et la clé publique du serveur ou encore le nom de l'autorité de certification lorsque celui-ci n'est pas auto-signé. En fin de certificat se trouve la signature qui est générée en chiffrant le condensat du certificat avec la clé privée. Le paquet se compose ensuite de la Server.KeyExchange (en réalité cette clé peut être optionnelle selon la cipher suit choisie). Dans le cadre d'un échange de clé suivant la méthode DHE (Ephemeral Diffie-Hellman), le serveur envoie sa partie du DH c'est à dire la base g choisie, le nombre premier p ainsi que le résultat g^a [mod p] avec a une valeur aléatoire. Finalement, un Server.Done est envoyé indiquant simplement la fin de la procédure Hello coté serveur.
3. Le client est maintenant en mesure de vérifier l'authenticité du certificat. Pour cela, il commence par générer un condensat selon la fonction choisie par le serveur (cette fonction est présente dans le certificat et peut être différente de celle indiquée dans la suite cryptographique). Après avoir déchiffré la signature avec la clé publique, Bob peut comparer les deux condensats et attester de la validité du certificat. En réalité, un problème peut se poser à cette étape. Comment peut-on garantir que le certificat reçu n'est pas celui d'un attaquant venu s'intercaler au milieu de l'échange et gérant ainsi deux connexions avec Alice et Bob. Sur le web, les administrateurs de sites font appel à des Autorités de Certification (CA). Rapidement, les certificats sont émis de ces autorités et lorsque les clients les reçoivent, leur navigateur est en mesure de vérifier leur provenance en parcourant une liste de clés publiques de ces CA. Dans le cas de Tor, ces serveurs d’autorités n'existent pas directement. Néanmoins même si un MITM venait s'ajouter, il serait incapable de déchiffrer le véritable message (post TLS) car celui-ci est également chiffré avec la clé publique de Bob (cf. paragraphe sur la création de circuits). Recentrons-nous. Bob va générer sa partie du DH en choisissant son nombre b et sera ainsi en mesure de connaitre sa pre-master key sous la forme g^ab [mod p] dont nous verrons l'utilité ensuite. Il termine en envoyant à Alice sa partie du DH (g^b [mod p]) suivi d'un Client.ChangeCipherSuite indiquant que la suite des échanges sera chiffrée avec la clé symétrique AES calculée et finalement un Client.Finished.
4. Le serveur connait maintenant (grâce à la partie du client) le secret commun du DH qui sera sa pre-master key. Il va donc pouvoir générer la clé symétrique AES de son côté également. Ensuite, même procédure que le client, il envoie son Server.ChangeCipherSuite et son Server.Finished.

Le déroulement et la chronologie maintenant fixés, nous pouvons revenir sur certaines parties laissées dans l'ombre avec notamment la génération de la, ou plutôt des, clés AES. Repartons de l'étape 3, où le client à toutes les cartes en sa possession. Il va commencer par calculer le master secret. L’intérêt d'une telle clé est d'harmoniser la longueur des clés (pre-master keys) qui dérivent des méthodes d'échange en formant un secret d'une taille fixe de 48 octets. Comme indiqué dans le RFC 5246, le calcul est le suivant :

Derrière la fonction PRF (Pseudo Random Function) se cache une formule permettant la génération d'un mot de taille souhaitée selon une fonction de hachage itérative (plus exactement une HMAC de l'anglais keyed-hash message authentication code). Le PRF découle de la formule ci-après :

Le protocole recommande l'utilisation de la fonction de hachage SHA256. Le secret est notre pre-master secret, le label est la chaine de caractère "master secret" et enfin le seed correspond à la concaténation des deux valeurs aléatoires de 32 octets du client et du serveur.

Expliquer pourquoi DHE est nécessaire et pourquoi pas simplement utiliser la clé publique pour générer une clé symétrique : PFS

Rédaction en cours

Web classique torifié

Les services cachés

Les failles connues

Expérimentations

Navigation sur le réseau Tor

Refaire le screenshot

Pour naviguer sur le réseau Tor, nous avons téléchargé la dernière version de Tor Browser disponible sur le site web de la fondation :

• https://www.torproject.org/projects/torbrowser.html.en.

Il s'agit de la méthode la plus simple d'obtenir un ordinateur connecté à Tor de la manière la plus sécurisée possible. Tor Browser est un clone du projet Firefox de Mozilla, sous licence GPL. Il s'agit d'un simple navigateur modifié pour tout faire transiter par Tor.

Tor Browser - nœud de sortie

En pratique, Tor Browser va faire transiter les requêtes par un proxy SOCKS version 5 sur le localhost via le port 9050, sur lequel tourne le logiciel d'onion routing (Tor en lui même). En plus du navigateur, Tor Browser inclut divers logiciels purement sécuritaires, comme Privoxy, un proxy HTTP qui va filtrer toutes les fuites HTTP qui pourraient ne pas transiter par Tor, et par conséquent compromettre l'anonymat de l'utilisateur. Ce navigateur est également pourvu de deux extensions nativement : NoScript et HTTPS Everywhere. Par défaut, NoScript bloque l'exécution des scripts JavaScript, Java, Flash, Silverlight et les autres contenus exécutables mais l'utilisateur est libre de les réactiver sur les site qu'il estime de confiance. Nous verrons dans une autre partie de ce Wiki, pourquoi certains scripts peuvent se révéler dangereux pour l'anonymat. HTTPS Everywhere permet quant à lui de forcer l'usage du protocole HTTPS quand le site consulté utilise encore le HTTP par défaut.

Première remarque, il ne faut pas être pressé lorsqu'on navigue sur Tor. C'est loin d'être inutilisable mais il faut bien entendu oublier les téléchargements de fichiers lourds. A titre de comparaison, les deux images ci-dessous montre la différence de temps de téléchargement pour un fichier de 5 MiB hébergé sur un serveur public et sur un service caché. On constate des temps respectif de 25s contre 70s, ce qui donne des débits de 210 ko/s et 75 ko/s. Si l'on rapporte ces temps pour le chargement d'une page web, comme par exemple le site duckduckgo (468 Ko environ pour la page d'accueil), on obtient un délai de réponse de 2.2s. A l'heure d'aujourd'hui cela peut paraître ridicule néanmoins de tels débits suffisent pour de la navigation classique. Les deux autres images expliquent en partie cette faiblesse. En effet, le nombre d’utilisateurs est passé en un an de 2 millions à 4 millions alors que le nombre nœuds a régressé. Pour ne rien arranger, la dernière image montre une baisse en 2017 et 2018 de la bande passante théorique disponible. Nous avons fait quelques recherches pour voir si ce constat tenait la route et il s’avère que de nombreux utilisateurs se plaignent sur les forums de discussion de la lenteur du réseau ces derniers mois. Enfin, l'implémentation de Tor, de part la création de circuits, rend les communications variables. Il suffit d'un nœud avec une bande passante très faible pour ralentir toute la chaîne de transmission.

• 

  Vitesse de téléchargement - Serveurs publics

• 

  Vitesse de téléchargement - Services cachés

• 

  Nombre d'utilisateurs

• 

  Nombre de nœuds sur le réseau

• 

  Bande passante théorique et consommée

Nous avons ensuite visité le hidden wiki, service caché dont l'adresse est trouvable publiquement et qui référencie les principaux sites en .onion, qu'ils soient légaux ou non. On y retrouve beaucoup de forums, de réseaux sociaux, des plateformes de e-commerce centré sur le marché noir mais également des sites dont la pérennité est en danger tels que KickassTorrents ou ThePirateBay. D'autres services comme Facebook ont fait le choix de mettre en place un service caché. Venant d'une entreprise qui vit grâce à nos informations, on est en droit de se demander l’intérêt d'une telle initiative. La réponse est pourtant simple, Facebook a développé ceci pour permettre aux habitants des pays encore censurés de naviguer sur Facebook sans restriction. Pour faciliter la mémorisation du nom de domaine en .onion (facebookcorewwwi.onion), ils ont du déployer une importante puissance de calcul. En effet, les 16 caractères visibles proviennent de la moitié du hash (avec SHA-1) de la clé RSA 1024 bits du service caché passé en base 32. A titre informatif, Scallion permet grâce à la puissance des GPUs de générer entre autre des noms de domaine en .onion suivant un certain paterne. Une formule statistique annonce une durée de 1min30 (avec une GTX 1080) pour un pattern de 8 caractères. Ce temps monte à 27h pour 10 caractères. D'après les dires d'Alec Muffett, ingénieur logiciel en charge du déploiement du service caché, seul le pattern facebook était recherché, le reste se devait simplement d'être mémorisable, chose faite avec corewwwi.

Recentrons nous un peu. Après avoir regardé la configuration réseau de Tor Browser, nous nous sommes dits qu'il devait être possible de naviguer sue Tor via n'importe quel navigateur prenant en charge le SOCKS4/5. Sans grande surprise, cela s'est avéré fonctionnel. Il faut cependant faire preuve de vigilance. En configurant le proxy rapidement, on s'est aperçu que notre processus Firefox, plus précisément notre onglet, utilisé deux sockets. Le premier était effectivement à destination du processus Tor sur son port d'écoute (SocksPort) 9050 alors que le second avait établi une connexion UDP avec le serveur DNS de l'école. On appelle cela une fuite DNS. Nous avons ensuite découvert une option à cocher permettant la résolution de domaine par le proxy, ce qui a résolu ce soucis d'Anonymat. A noter également, que la version 4 de SOCKS ne permet pas cette option. Pour résumer, il est plus simple et sûr pour un utilisateur lambda d'utiliser le logiciel fournit par le projet Tor.

Ajout d'un nœud

Nous avons ajouté un noeud Tor directement relié à la ligne SDSL de Polytech, pour ce faire, comme annoncé dans l'introduction, nous avons réalisé une machine virtuelle sur la machine Chassiron qui était libre et reliée à la ligne SDSL.

Création de la machine virtuelle

Avant de s’intéresser à notre nœud, il nous faut créer une machine virtuelle qui va le contenir, pour ce faire nous utilisons les logiciels xen ainsi que lvm. Xen est un hyperviseur de type un "bare-metal", il s'agit d'une couche entre le hardware et le kernel. Xen va être une sorte de passerelle, qui permet donc de faire tourner plusieurs versions de kernel en parallèle.

Pour la création de la machine virtuelle, nous utilisons Xen, avec la commande suivante:

xen-create-image --hostname=DurotDuq --dhcp --size=10Gb --swap=128Mb --lvm=gis4-pokedex

Cette commande crée deux volumes logiques : DurotDuq-disk et DurotDuq-swap sur le volume de groupe gis4-pokedex, de taille 10Gb et 128Mb respectivement, ces volumes logiques vont servir de disque pour la machine virtuelle. A savoir que aurions très bien pu les volumes virtuels en amont d'autant plus, un swap n'étant pas forcément nécessaire, nous aurions pu avoir strictement le même résultat en rentrant la commande :

lvcreate -L10 -nDurotDuq-disk gis4-pokedex

Puis en utilisant la partition ainsi réalisée dans la configuration de la machine virtuelle. La machine virtuelle étant créée, on peut la configurer via le fichier "/etc/xen/DurotDuq.cfg", où on peut modifier les interfaces réseaux de la machine virtuelle, leurs adresses mac, etc ... En particulier, nous connectons la carte réseau virtuelle sur le bridgeAlternate, qui contient la Vlan47 sur laquelle est la ligne SDSDL

• 

  Volumes logiques sur Chassiron

• 

  Configuration de la machine virtuelle

Il ne nous reste plus qu'à modifier le fichier /etc/network/interfaces de la sorte :

auto eth0
iface eth0 inet static
 address 5.23.44.84
 netmask 255.255.255.248
 gateway 5.23.44.81

Notre VM est maintenant connecté à Internet sans passé par le réseau interne de la FAC.

Ajout du nœud effectif

Pour que notre machine virtuelle fonctionne comme un nœud, il faut premièrement installer Tor sur la machine. Pour se faire, nous avons récupéré le package Tor via les dépôts officiels Debian. Pour être reconnu comme un nœud Tor, il faut qu'elle communique diverses informations aux serveurs d’autorité de Tor, comme son nom, son adresse IP, sa politique (ports TCP autorisés) ...

Voici un exemple de configuration, celui que nous avons utilisé, du fichier /etc/torrc :

SocksPort 0 #1
DataDirectory /var/lib/tor
Nickname nom_au_choix #2
Address ip_publique #3
ContactInfo ail@domaine.tld #4
ORPort 9001 #5
RelayBandwidthRate 20 KBytes #6
RelayBandwidthBurst 35 KBytes #7
ExitPolicy reject *:* #8

Exemple de nœuds sur Tor Metrics

Dans le cas d'un nœud, le SocksPort (1) peut être mis à 0 car aucun autre processus de la machine ne va communiquer avec Tor. Le Nickname est le nom qui sera attribué à notre nœud, celui sera visible sur les annuaires de recherche de relais comme sur le site officiel Tor Metrics. En (3), nous retrouvons l'IP publique de la machine et en (4) éventuellement une adresse mail afin que le Project Tor puisse nous contacter. Ensuite, ORPort (5) représente le port sur lequel on va communiquer avec notre nœud. L’échange de clefs Diffie-Hellman et le traffic Tor passeront par ce nœud et auront pour destination ce port. Pour limiter ce traffic justement, il nous est possible de choisir la bande passante moyenne et maximale que l'on accorde à notre nœud. En revanche, il faut savoir que la bande passante minimale est de 75 ko/s. Nous indiquons finalement (8) que nous ne souhaitons pas être un nœud de sortie car ce sont les plus vulnérables dans la mesure où ce sont eux qui se connectent "effectivement" aux sites.

Après cette opération effectuée, il faut compter quelques heures pour que le consensus soit mis à jour au niveau des serveurs d'autorité. Mais en pratique, notre nœud a peu de chance d’être choisi lors du routage, ses ressources étant très limitées.

• 

  Fiche Tor Atlas de notre noeud

• 

  Capture des paquets transitant sur notre noeud

Création d'un service caché

Ajouter des images

Pour cette partie, nous travaillons toujours sur notre VM DurotDuq avec le paquet Tor installé. La première étape consiste à y installer un serveur web, apache2 dans notre cas, sans configuration particulière. Nous avons ensuite déposé un simple fichier html de test dans le dossier défaut utilisé par apache, à savoir /var/www/html. Vient ensuite la configuration du torrc, pour lequel il faut dé-commenter les lignes suivantes :

DataDirectory /var/lib/tor
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80

Pour rafraîchir la configuration, on reload le service : service tor reload

Ceci étant fait, Tor va générer dans le dossier /var/lib/tor/hidden_service/ deux fichiers, hostname et private_key. Ce qui nous intéresse dans cette partie, c'est de récupérer le nom de domaine en .onion de notre service caché situé dans le fichier hostname.

Il ne reste plus qu'à configurer apache en faisant en sorte qu'il n'écoute que les communications provenant du processus Tor, empêchant ainsi l'accès à quiconque souhaitant accéder au site par son IP.

Dans le fichier /etc/apache2/ports.conf, nous avons changé la ligne Listen 80 par Listen 127.0.0.1:80. On fait de même pour la configuration du site hébergé par défaut /etc/apache2/sites-enabled/000-default.conf en remplaçant <VirtualHost *:80> par <VirtualHost 127.0.0.1:80>. Finalement, on relie notre nom de domaine : ServerName NomDeDomaine.onion.

Après un restart du service apache2, le service caché est opérationnel.

Réseau privé Tor

Rédaction en cours

L'état de l'art du réseau Tor passe par une analyse de la sécurité. De part l'architecture de Tor, nous avons su de nous même déterminer des potentielles failles dans le fonctionnement du réseau. Par la suite, nous avons consulté des articles de recherche portant sur le sujet qui nous ont appris bien d'autres vulnérabilités toujours d'actualité ou non. Pour vérifier ces théories, nous avons eu l'idée de mettre en place un réseau privé Tor sur Chassiron. En effet, ceci nous donnera accès à tous les acteurs de la transmission du client vers le serveur web (par exemple) avec notamment un contrôle total des nœuds depuis lesquels nous pourront analyser les entrées / sorties de données.

Du point de vu technique, des solutions existantes répondent à nos attentes comme Chutney et Shadow mais nous avons trouvé préférable et plus confortable de bâtir le notre. Sur le serveur Chassiron, nous avons "recyclé" 3 VMs existantes. Deux d'entre elles occupent le rôle de nœud alors que la troisième est à la fois un serveur WEB, un serveur d’autorité et un nœud [Ajouter schéma réseau].

Dans un premier temps, nous avons installé Tor sur les 4 machines du réseau sans s'occuper de la configuration.

Bibliographie

• https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf
• https://www.torproject.org/docs/documentation.html.en
• https://www.usenix.org/system/files/conference/foci12/foci12-final2.pdf
• https://www.freehaven.net/anonbib/cache/abbott-pet2007.pdf
• https://witestlab.poly.edu/blog/anonymous-routing-of-network-traffic-using-tor/
• https://research.torproject.org/techreports.html

Et bien d'autres à rajouter.

Documents Rendus