Tor: Protocole des Services Cachés

Tor permet à ses utilisateurs de cacher leur emplacement tout en leur offrant différents types de services tels que la publication de site web ou un serveur de messagerie instanée. 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. Cette page décrit les détails techniques du fonctionnement du protocole de "rendez-vous". Si vous désirez des instructions plus opérationnelles, consultez notre page sur la configuration des services cachés.

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 noeuds au hasard, construit des circuits vers eux et leur demande d'agir comme des points d'introduction en leur fournissant sa clef publique. Notez 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).

Etape deux: le service caché construit 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'annuaires, 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é. Vous pouvez également consulter la conjecture de Zooko qui précise qu'on peut atteindre deux des trois fonctionnalités suivantes: décentralisation, sécurité, noms compréhensibles pour un être humain. Peut-être qu'un jour, quelqu'un implémentera une fonctionnalité Petname sur les noms de services cachés ?

Étape 3: Un client qui voudrait contacter un 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é.

Etape quatre: 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.

Etape cinq: 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. Cette attaque a été décrite par Øverlier et Syverson dans leur document intitulé Localiser des Serveurs Cachés.

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é.

Il existe d'autres documentations plus complètes sur le protocole de service caché que celle-ci. Consultez le document de spécification de Tor pour une description plus approfondie ainsi que la spécification rendez-vous pour le format de messages.