fr/hidden-services.wml (50923011b) - tor-webwml.git

hidden-services.wml

## translation metadata
# Revision: $Revision$
# Translation-Priority: 3-low
#include "head.wmi" TITLE="Tor: Hidden Service Protocol" CHARSET="UTF-8"
<div class="main-column">

<h2>Tor: Protocole des Services Cachés</h2>
<hr />

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
<a href="<page docs/tor-hidden-service>">configuration des services
cachés</a>.

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

# maybe add a speech bubble containing "PK" to Bob, because that's what
# Bob tells to his introduction points
<img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png" />

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 &mdash; y compris les points d'introduction, les serveurs d'annuaire
et ,bien entendu, les clients &mdash; peuvent vérifier qu'ils communiquent
avec le bon service caché. Vous pouvez également consulter <a
href="https://zooko.com/distnames.html">la conjecture de Zooko</a> 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é <a
href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>
sur les noms de services cachés ?

# maybe replace "database" with "DHT"; further: how incorrect
# is it to *not* add DB to the Tor cloud, now that begin dir cells are in
# use?
<img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png" />

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

# maybe add "cookie" to speech bubble, separated from the surrounded
# "IP1-3" and "PK"
<img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png" />

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.

At this point it is of special importance that the hidden service sticks to
the same set of <a
href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Whatsthisaboutentryguardformerlyknownashelpernodes">entry
guards</a> when creating new circuits. Otherwise an attacker could run his
own relay and force a hidden service to create an arbitrary number of
circuits in the hope that the corrupt relay is picked as entry node and he
learns the hidden server's IP address via timing analysis. This attack was
described by &Oslash;verlier and Syverson in their paper titled <a
href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
Servers</a>.

# it should say "Bob connects to Alice's ..."
<img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png" />

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 <a
href="<svnprojects>design-paper/tor-design.pdf">document de spécification de
Tor</a> pour une description plus approfondie ainsi que la <a
href="<gitblob>doc/spec/rend-spec.txt">spécification rendez-vous</a> pour le
format de messages.

</div>

#include <foot.wmi>

tor-webwml.git

new and updated translations for the website