Cela fait plusieurs mois déjà que j'étudie le sous-réseau Tor. L'idée m'a pris en novembre dernier d'explorer des réseaux dans le réseau, et le plus célèbre d'entre eux est bien sûr Tor. À peine je commence cet article que je dis halte aux préjugés sur Tor, il est à l'image de l'utilisation que chacun de nous en fait, c'est la même chose avec le réseau (Internet). Du point de vue historique, il a été inventé par le laboratoire de recherche de l'U.S. Navy avec pour objectif de protéger les communications du gouvernement. Ce sous-réseau est très intéressant car il permet de s'affranchir d'un certain nombre de contraintes appliquées par le routage classique.

Routage en onion

Son architecture a la forme d'un onion, c'est à dire qu'une couche ne connait que la couche qui lui est supérieur et la couche qui lui est inférieur, elle ignore la présence des autres couches, et il en est de même pour chaque couche. Pour la conception d'un tel système de routage, chaque routeur ne doit connaitre la présence que de deux routeurs du circuit dont il fait parti, et ne peut pas connaitre les autres routeurs de son circuit. Il connait donc le routeur expéditeur d'un traffic et le routeur destinataire sans jamais connaitre le destinataire final placé à l'extrémité du circuit. Basé sur ce concept simple, le routage en onion est né.

Un routeur sur toutes ses Fedora

Les avantages d'avoir le service Tor installé et actif sur ses machines sont multiples. Ces routeurs couvrent tout l'éventail des applications réseau, du client au serveur. Pour la partie client, ne croyez pas qu'en passant par Tor vous devenez anonyme sur le Web. Avant d'atteindre ce statut il faut bloquer les cookies et désactiver Javascript. En revanche vous devenez effectivement anonyme sur le réseau, mais ce n'est pas cette particularité qui m'attire le plus chez Tor. C'est le concept de réseau dans le réseau qui m'inspire. Si une machine change d'emplacement sur le réseau (donc a changé de zone géographique), elle ne change pas d'adresse dans le sous-réseau. De plus, toutes les limitations du réseau (par exemple NAT et pare-feu de box) ont disparu, et seule la configuration du routeur Tor gère la connectivité de la machine.

Application client

Il y a moyen d'avoir une utilisation très poussée du sous-réseau, mais tout n'est pas possible. En effet à cause des abus, les ports du protocole Bittorrent sont bloqués, les ports d'envoi de courriels le sont aussi. Du coté technique, on a un port d'écoute sur l'interface localhost de type Proxy SOCKSv5 (avec DNS distant) dans lequel on peut envoyer diverses requêtes. Pour envoyer les traffics réseau d'un logiciel quelconque qui ne dispose pas de configuration proxy SOCKS, on a le choix entre deux logiciels: torsocks qui est fourni avec le paquet Tor, et proxychains. Si les logiciels qu'on utilise tous les jours peuvent être configurés pour utiliser un proxy SOCKS comme Firefox par exemple, alors nul besoin de passer par torsocks ou proxychains. Au niveau du fichier de configuration /etc/tor/torrc, il n'y a rien à modifier. On peut utiliser la configuration par défaut sans danger.

Application serveur

Pour la partie serveur, les services réseau traditionnels peuvent être rendu accessibles depuis le sous-réseau avec le minimum de configuration du routeur, et surtout permet de contourner la redirection de ports/NAT de la box (le routeur du réseau). Encore plus fort, si jamais la machine change d'emplacement physique sur le réseau, l'emplacement dans le sous-réseau ne change pas, tant que le routeur n'est pas réinstallé. Tous les services peuvent écouter et attendre les connexions clientes depuis le sous-réseau indépendemment de la zone géographique de la machine, mais les services eux-mêmes ne peuvent pas établir de connexion cliente avec d'autres serveurs à travers le sous-réseau. Au niveau du fichier de configuration, il faudra ajouter les lignes suivantes :

HiddenServiceDir /var/lib/tor/hidden_service1/
HiddenServicePort 22 127.0.0.1:22
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 443 127.0.0.1:443

Pour chaque hidden_service numéroté 2, 3, 4, etc, l'adresse en .onion sera différente. Par exemple pour joindre ma machine sur les ports HTTP avec une adresse différente de l'adresse du port SSH :

HiddenServiceDir /var/lib/tor/hidden_service1/
HiddenServicePort 22 127.0.0.1:22
HiddenServiceDir /var/lib/tor/hidden_service2/
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 443 127.0.0.1:443

L'adresse de chaque hidden service est stockée dans le fichier /var/lib/tor/hidden_service1/hostname.

Et les relais dans tout ça ?

Les applications évoquées précédemment n'impliquent pas que vous fassiez tourner un relai sur votre machine. Il est tout à fait possible de configurer le routeur Tor en mode client ou serveur sans faire relai. Mais par contre, il peut très bien être configuré en mode relai en plus de tout le reste. Le sous-réseau Tor n'existe que s'il y a suffisemment de relais dispersés à travers le monde, et à l'heure où j'écris ces lignes, il y en a environ 8 000.

Avant de se lancer, il faut savoir qu'il y a trois types de relai: Le relai de sortie, le relai au milieu et le relai gardien. Le relai de sortie est situé à l'extrèmité du circuit, c'est là où débouche tous les traffics entre le sous-réseau et Internet. C'est clairement pas une bonne idée d'avoir ce type de relai sur une ligne domestique, et il faut lire beaucoup de documentation pour réunir les conditions optimales au fonctionnement de ce type de relai. J'ai testé et je vous le déconseille vivement.

Le relai au milieu, comme son nom l'indique est placé au milieu du circuit, et ne communique qu'avec d'autres relais, c'est l'idéal pour une ligne domestique car il n'y a que du traffic chiffré.

Enfin, les relais gardiens sont en fait des relais du milieu qui ont suffisament d'ancienneté pour être acrédité à recevoir les connexions des utilisateurs de Tor. Il sont situés à l'autre extrèmité du circuit, la plus sensible des deux, c'est à dire à l'entrée.

Relai du milieu

La configuration par défaut du service Tor en mode relai est de type sortie (cumulée avec les autres types car un routeur peut tout faire en même temps), il faut donc désactiver la sortie, et faire un peu de redirection de port/NAT avec sa box. Les ports OR (Onion Routing) et Dir (Directory Information) doivent être joignables depuis l'extérieur. On peut préciser le pseudo du relai ainsi que nos limites de bande passante. L'information de contact doit aussi être renseigné avec une clé GPG et une adresse email valide (mais obscurcie pour le spam) afin de pouvoir être averti en cas de problème. Enfin, il faut explicitement indiquer dans la config que toutes les règles de sortie de traffic sont rejetées par le relai, ce qui entraine la fermeture de la sortie :

ORPort 9001
Nickname Casper02
RelayBandwidthRate 50 KB
RelayBandwidthBurst 60 KB
DirPort 9030
ExitPolicy reject *:*

Rester dans le sous-réseau

C'est possible, et c'est la partie que je préfère de Tor. Jusqu'à maintenant nous avons vu les communications entre le sous-réseau et le réseau en passant par les relais de sortie, mais on peut tout aussi bien rester de bout en bout dans le sous-réseau pour joindre ses machines, à condition qu'elles aient toutes un routeur installé et configuré. Il y a une dualité entre les applications client et serveur vues précédemment. Si on peut utiliser l'application client pour joindre un serveur sur le réseau, on ne peut pas utiliser l'application serveur sans utiliser l'application client. Tout simplement car on ne peut pas joindre un serveur dans le sous-réseau en passant par le réseau, ce qui est plutôt logique en soit. L'application serveur nécessite l'application client, et utiliser les deux en même temps permet de réaliser ainsi une connexion de bout en bout dans le sous-réseau sans jamais transiter par le réseau. Fantastique n'est-ce pas ?

Installation et configuration générale

C'est le moment où l'on peut agir en connaissance de cause. Cette partie est la plus facile, mais elle implique de grandes responsabilités, c'est pourquoi je ne la traite qu'à la toute fin.

# yum install tor tor-arm

Le minimum de configuration quelque soit le mode de votre routeur, qui n'est pas vital mais que je recommande :

Log notice file /var/log/tor/notices.log
Log warn file /var/log/tor/warnings.log
RunAsDaemon 1
DataDirectory /var/lib/tor
ControlPort 9051
HashedControlPassword my-hashed-password-here

Le port de contrôle (9051) n'est actif que sur l'interface localhost, il n'y a pas lieu de s'inquièter. Le hashage du mot de passe se fait avec la commande :

$ tor --hash-password mon-mot-passe-il-dechire

Le programme tor-arm, ou plutôt ARM de son vrai nom, est un programme de monitoring comme top, htop ou glances, sauf qu'il est spécialisé pour les routeurs Tor. Pour qu'il puisse se connecter au port 9051, il faudra taper le mot de passe à son lancement dans le terminal. Si vous avez envie de faire tourner plus d'un relai, quel que soit son type vu précédemment, il faudra ajouter un paramètre supplémentaire dans le fichier de conf :

MyFamily $D8AE9C760B74AFE3CA0F48EEB21271E22CF25F7A, $etc, $etc...

Cette option sert à indiquer à vos routeurs à quels relais il ne doivent jamais se connecter pour garantir l'intégrité de leurs circuits de connexion. L'empreinte que l'on doit indiquer est visible dans le fichier /var/lib/tor/fingerprint présent sur chaque routeur.

Ok, et toi dans tout ça ?

Personnellement je détiens trois connexions sur le réseau, la ligne ADSL de mon domicile, une machine virtuelle dans un datacenter à Billancourt, et une autre machine virtuelle dans un datacenter à Roubaix. J'y ai donc installé trois relais de type différent, dont un à basse vitesse, car ce n'est pas la bande passante qui compte, mais bien le nombre de relais mis en ligne.