Anonymisation de connexions TCP grâce à TOR

Présentation

Généralités

TOR est, à la fois, un logiciel libre et un réseau ouvert qui permet de se défendre contre une forme de surveillance de réseau qui menace les libertés individuelles et l'intimité, les activités commerciales, les mises en relations, ainsi que la sécurité de l'État. Cette surveillance est connue sous le nom d'analyse de trafic. La défense que TOR procure se fait par l'anonymisation des connexions TCP sous-jacentes.

Le terme onion que l'on retrouve dans son nom The Onion Router se traduit littéralement par routage en oignon, et ce n'est pas une coincidence. Cette référence à l'oignon se retrouve dans le fonctionnement de TOR, qui est abordé dans la partie suivante. Ce réseau est un réseau au-dessus du réseau existant qu'est Internet, qui est distribué : il est constitué de noeuds qui correspondent à des serveurs et des utilisateurs.

Objectifs de conception

TOR a été conçu dans l'optique respecter les contraintes suivantes :

Certains problèmes, certaines dimensions ont cependant été écartées :

Utilisation

Le logiciel TOR est une application haut niveau, qui n'a pas besoin de droits particuliers pour être exécutée (bien que selon certaines distributions de Linux, l'application soit installée en tant que service, mais c'est alors un choix de cette distribution).

Cette application repose sur l'utilisation de SOCKS, qui est un protocole défini au niveau de la couche session du modèle OSI. Ce protocole permet de faciliter le routage de paquets entre des applications de type client/serveur via un serveur proxy. Dans le cas de TOR, l'application utilisée localement joue alors le rôle de proxy. Les applications devant utiliser TOR doivent alors être configurées pour utiliser ce serveur proxy. Selon les applications, cette configuration peut être très simple, comme par exemple dans le cas de Firefox où il suffit d'indiquer, dans la configuration réseau, le port du serveur TOR local :

Configuration de Firefox pour utiliser TOR

Dans ce cas, Firefox est configuré pour se connecter au port 9050 de l'application locale, qui est le port client par défaut de TOR.

Un peu de terminologie...

Les noeuds du réseaux peuvent être de plusieurs types.

Lorsqu'un client désire contacter un serveur quelconque, par exemple un serveur Web - externe au réseau TOR -, le client va construire un circuit qui lui permettra d'atteindre sa destination. C'est donc l'OP (le client), qui va consulter les Directory Servers, pour connaître les ORs disponibles, puis construire un circuit. L'OP a également pour rôle de gérer les connexions des applications clientes, comme par exemple celles de Firefox pour la navigation Web.

Les noeuds du réseau ont une connaissance limitée. Les ORs qui constituent le circuit construit par l'OP ne connaissent que leur précédent et leur suivant dans le circuit. Les Directory Servers ne connaissent pas les circuits construits dans le réseau.

Exemple

TOR réduit les risques d'analyses de trafic simples ou sophistiquées, en répartissant les transactions entre plusieurs endroits de l'Internet. On ne peut donc pas, en observant un seul point, associer l'utilisateur à son destinataire. C'est comme utiliser un chemin tortueux et difficile à suivre pour semer un poursuivant (tout en effaçant de temps en temps ses traces) . Au lieu d'emprunter un itinéraire direct entre la source et la destination, les paquets de données suivent une trajectoire aléatoire à travers plusieurs relais qui font disparaître les traces de connexion. Personne ne peut donc déduire de l'observation d'un point unique, d'où viennent, ni où vont les données.

Nous allons maintenant voir comment un client, Alice, va procéder pour accéder à un serveur, Bob, de façon anonyme. Alice va d'abord commencer par obtenir une liste des noeuds du réseaux susceptibles d'être utilisés pour construire son circuit. Elle va donc demander à un Directory Server, un serveur annuaire, de lui fournir cette liste. Dans ce cas, ce serveur est appelé Dave :

Exemple de fonctionnement de TOR 1

Pour définir un trajet privé à travers le réseau TOR, l'OP détermine au fur et à mesure un circuit de connexions chiffrées à travers les relais du réseau, les ORs. Le circuit est construit étape par étape, et chaque relais le long du chemin ne connaît que celui qui lui a transmis les données, et celui auquel il va les retransmettre. Aucun relais ne connaît à lui tout seul le chemin complet pris par un paquet de données. Le client négocie indépendamment une paire de clé de chiffrement avec chaque serveur du circuit. Aucun d'eux ne peut donc intercepter la connexion au passage.

Alice va maintenant construire un circuit à partir de la liste d'ORs qu'elle connait. Le dernier noeud constituant son circuit à l'intérieur du réseau sera alors responsable de contacter la destination d'Alice, Bob :

Exemple de fonctionnement de TOR 2

Une fois le circuit établi, différents types de données peuvent être échangées, et plusieurs sortes d'applications peuvent être utilisées via le réseau TOR. Etant donné que chaque serveur ne voit pas plus d'une étape dans le circuit, ni un éventuel intermédiaire, ni un noeud compromis ne peuvent analyser le trafic pour établir une relation entre la source et la destination d'une connexion.

Pour des raisons d'efficacité, le logiciel TOR utilise le même circuit pour des connexions qui ont lieu dans un même intervalle de dix minutes. Les requêtes ultérieures utiliseront un nouveau circuit, afin d'éviter que l'on puisse faire le lien entre les actions précédentes, et les nouvelles.

Exemple de fonctionnement de TOR 3

Afin d'observer le résultat simple de l'utilisation de TOR, à savoir la dissimulation de l'adresse IP source d'une connexion TCP, j'ai effectué un test simple en utilisant un service Web permettant de connaître son adresse IP ainsi que sa géolocation. Ce service est disponible à l'adresse http://whatismyipaddress.com/. Je me suis d'abord connecté sans utiliser TOR, et ai observé le résultat suivant :

Adresse IP non dissimulée

Il s'agit de l'IP utilisée chez moi, dans l'Est de la France. Maintenant, après avoir configuré Firefox pour utiliser TOR, le service donne le résultat suivant :

Adresse IP dissimulée

On constate effectivement que l'adresse IP trouvée par le service n'est plus la même, et que le noeud de sortie qui m'a permis de contacter le service Web est situé en Allemagne.

Services cachés

Les services cachés permettent d'anonymiser le côté destinaire d'une connexion TCP. Dans ce que nous avons vu jusqu'à maintenant, seule la source était cachée du destinaire. Les services cachés permettent de cacher la destination. Cependant il faut noter que s'il n'est possible de cacher que la source d'une connexion TCP avec TOR, il n'est pas possible de ne cacher que la destination. En effet, pour l'utilisation des services cachés impose également la dissimulation de la source, de par l'obligation d'utiliser le client TOR pour accéder à ce service.

En utilisant les "points de rendez-vous" TOR, les autres utilisateurs de TOR peuvent se connecter à ces services cachés de manière à ce que ni celui qui publie l'information ni celui qui la consulte ne puisse connaître leur identité respective.

Un service caché doit afficher son existence dans le réseau TOR avant que des clients puissent le contacter. Par conséquent, le service récupère des ORs au hasard, construit des circuits vers eux et leur demande d'agir comme des points d'introduction en leur fournissant sa clef publique. Notons que dans les schémas suivant, les liens verts représentent des circuits plutôt que des connexions directes. L'utilisation d'un circuit TOR complet rend difficile pour quiconque d'associer un point d'introduction avec l'adresse IP du serveur caché. Bien que les points d'introduction et les autres disposent de l'identité (la clef publique) du service caché, ils ne doivent rien savoir de l'emplacement du serveur caché (Adresse IP).

Exemple de fonctionnement des services cachés de TOR 1

Le service caché construit ensuite un descripteur de service caché contenant sa clef publique et un résumé de chaque point d'introduction qu'il signe avec sa clef privée. Il stocke ce descripteur sur un ensemble de serveurs d'annuaire, encore une fois en utilisant un circuit complet dans TOR afin de cacher le lien entre le serveur d'annuaire qui stocke le descripteur et l'adresse IP du serveur caché. Le descripteur sera trouvé par des clients qui recherchent XYZ.onion où XYZ est un nom de 16 caractères de long qui peut seulement être dérivé de la clef publique du service. Une fois cette étape achevée, le service caché est démarré.

Bien que cela semble peu pratique d'utiliser un nom de service automatiquement généré, cela permet d'atteindre l'objectif suivant: Tout le monde — y compris les points d'introduction, les serveurs d'annuaire et, bien entendu, les clients — peuvent vérifier qu'ils communiquent avec le bon service caché.

Exemple de fonctionnement des services cachés de TOR 2

Un client qui voudrait alors contacter ce service caché doit d'abord connaître son adresse onion. Après cela, le client peut lancer une tentative de connexion en téléchargeant le descripteur des serveurs d'annuaire. S'il y a un descripteur pour XYZ.onion (le service caché peut aussi bien être arrêté ou avoir disparu depuis longtemps ou bien il peut y avoir une erreur de frappe dans l'adresse onion), le client créé un circuit vers un autre noeud au hasard et lui demande d'agir comme un point de rendez-vous en lui communiquant un secret partagé.

Exemple de fonctionnement des services cachés de TOR 3

Une fois que le descripteur est présent et que le point de rendez-vous est créé, le client génère un message de bienvenue (chiffré avec la clef publique du service caché), incluant l'adresse du point de rendez-vous et le secret partagé. Le client envoie ce message à l'un des points d'introduction en lui demandant de le délivrer au service caché. Encore une fois, la communication a lieu dans un circuit de manière à ce que personne ne puisse faire le lien entre le message de bienvenue et l'adresse IP du client, assurant l'anonymat du client.

Exemple de fonctionnement des services cachés de TOR 4

Le service caché déchiffre le message de bienvenue du client et y trouve l'adresse du point de rendez-vous ainsi que le secret partagé. Le service créé alors un circuit vers le point de rendez-vous et lui envoie le secret partagé dans un message rendez-vous.

A ce moment, il est primordial que le service caché conserve le même ensemble de noeuds gardiens pour créer de nouveaux circuits. Autrement, un attaquant pourrait utiliser son propre relais et forcer le service caché à créer un nombre arbitraire de circuits dans l'espoir que le relais corrompu puisse être désigné comme un noeud d'entrée et récupérer l'adresse IP du serveur en faisant de l'analyse temporelle.

Exemple de fonctionnement des services cachés de TOR 5

Dans la dernière étape, le point de rendez-vous indique au client que la connexion a bien été mise en place. Après cela, le client comme le service caché peuvent utiliser leurs circuits jusqu'au point de rendez-vous pour communiquer l'un avec l'autre. Le point de rendez-vous relaye simplement (chiffré d'un bout à l'autre) les messages du client vers le service et vice-versa.

Une des raisons de ne pas réutiliser la connexion créée auparavant via le point d'introduction pour une communication réelle est qu'aucun relais unique ne doit apparaître comme responsable d'un service caché donné. C'est pourquoi le point de rendez-vous ne connait jamais rien sur l'identité du service caché.

En général, la connexion complète entre le client et le service caché est constituée de 6 relais: 3 d'entre eux sont choisis par le client avec le troisième comme point de rendez-vous, les 3 autres étant affectés par le service caché.

Exemple de fonctionnement des services cachés de TOR 6