de/hidden-services.wml (86929a088) - tor-webwml.git

hidden-services.wml

## translation metadata
# Based-On-Revision: 17024
# Last-Translator: jens@kubieziel.de

#include "head.wmi" TITLE="Tor: Protokoll für versteckte Dienste" CHARSET="UTF-8"

<h2>Tor: Protokoll für versteckte Dienste</h2>
<hr />

Tor macht es Benutzern möglich, den Ort der Dienste zu verstecken. Dies kann
die Publikation von Webseiten oder ein Server für Instant-Nachrichten wie auch
anderes sein. Andere Nutzer können sich über so genannte Rendezvouspunkte mit
den versteckten Diensten verbinden ohne deren Identität zu kennen. Die Seite
beschreibt die technischen Details zu dem Protokoll. Eine eher praktische
Anleitung kannst du auf der Seite <a href="<page
docs/tor-hidden-service>">Versteckte Dienste konfigurieren</a> finden.

Ein versteckter Service muss seine Existenz im Tor-Netzwerk bekannt
 machen, bevor er kontaktiert werden kann. Daher wählt der Service
 zufällig einige Tor-Server aus, baut Verbindungsstrecken auf und
 bittet diese, als Einführungspunkte (introduction point) zu
 agieren. Beachte bitte, dass in den folgenden Abildungen die grünen
 Verweise eher Verbindungsstrecken von mehreren beteilten Rechnern
 meint, als direkte Verbindungen. Das macht es für jeden unmöglich,
 den Einführungspunkt mit der IP-Adresse des versteckten Servers in
 Verbindung zu bringen. Dies ist wichtig, denn obwohl die
 Einführungspunkte und andere die Identität des versteckten Services
 (öffentlicher Schlüssel) kennen, dürfen sie nicht dessen Ort
 (IP-Adresse) erfahren.

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

Im zweiten Schritt generiert der versteckte Service einen
 Deskriptor. Dieser enthält die Adresse des Einführungspunktes und
 seinen öffentlichen Schlüssel. Der versteckte Service signiert die
 Informationen mit seinem privaten Schlüssel. Es speichert den
 Deskriptor bei Verzeichnisservern, indem er wieder eine
 Verbindungsstrecke nutzt. Wenn nun ein Client die Adresse XYZ.onion
 bei einem Verzeichnisserver nachfragt, wird der Deskriptor dort
 gefunden. Die Adresse XYZ ist dabei ein 16&nbsp;Zeichen langer Name,
 der in eindeutiger Weise vom öffentlichen Schlüssel des versteckten
 Service abgeleitet wurde. Obwohl dieses Verfahren zunächst
 unpraktisch aussieht, dient es einem wichtigen Ziel: Jedermann &ndash;
 auch Einführungspunkte, Verzeichnisserver und natürlich Tor-Proxys
 &ndash; kann prüfen, ob sie wirklich mit dem versteckten Dienst
 reden. Nach diesem Schritt ist der versteckte Dienst bereit.

Auf den ersten Blick ist die Benutzung einen generierten Servicenamens
unpraktisch. Es dient jedoch einem wichtigen Ziel: Jeder &ndash; auch die
Einführungspunkte, Verzeichnisserver und natürlich auch die Clientprogramme
&ndash; können feststellen, ob sie mit dem richtigen Dienst kommunizieren.
Schaue dir dazu <a href="https://zooko.com/distnames.html">Zookos Vermutung</a>
an. Sie besagt, dass du bei der Wahl der Eigenschaften dezentralisiert, sicher
und menschenlesbar maxmimal zwei Eigenschaften ereichen kannst. Vielleicht wird
irgendwann jemand das Design der <a
href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petnamen</a>
implementieren?

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

Ein Programm, welches sich mit dem versteckten Dienst verbinden
möchte, muss zuerst von der Onionadresse wissen. Danach kann sich das
Programm verbinden. Es lädt den Deskriptor von den Verzeichnisservern
herunter. Wenn ein Deskriptor existiert (Der Dienst könnte auch
offline sein oder ein Fehler in der Onionadresse ist möglich.), baut
der Client eine Strecke zu einem Tor-Server auf und bittet es, als
Rendezvouspunkt zu agieren. Dazu teilt er ihm ein einmaliges Geheimnis
mit.

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

Neben dem Aufbau der Verbindung zum Rendezvouspunkt muss das
Clientprogramm eine Nachricht an den Einführungspunkt erstellen
(verschlüsselt mit dem öffentlichen Schlüssel des versteckten
Dienstes.). Diese Nachricht schließt die Adresse des Rendezvouspunktes
und das Geheimnis ein. Das Programm sendet die Nachricht an einen der
Einführungspunkte und bittet, diese an den versteckten Dienst zu
leiten. Wieder wird alle Kommunikation über Verbindungsstrecken im
Tor-Netzwerk abgewickelt. Damit wird die Anonymität des Clients
gesichert.

Der versteckte Dienst entschlüsselt die Nachricht des Clienten und
findet dort die Adresse des Rendezvouspunktes sowie das Geheimnis. Der
Dienst baut eine Strecke zum Rendezvouspunkt auf und sendet das
Geheimnis in einer Rendezvousnachricht.

An diesem Punkt ist es besonders wichtig, dass der versteckte
Dienst <a href="<page faq>#EntryGuards">dieselben Knoten</a> zum Anlegen
neuer Strecken verwendet. Sonst
könnte ein Angreifer einen eigenen Server betreiben und den
versteckten Dienst zwingen, eine Anzahl an Verbindungsstrecken über
ihn auszurichten. Über eine Analyse der Laufzeiten der Internetpakete
kann man so die IP-Adresse des Dienstes herausfinden. Der Angriff
wurde von &Oslash;verlier und Syverson in der Veröffentlichung
"<a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
Servers</a>" beschrieben.

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

Im letzten Schritt informiert der Rendezvouspunkt den Clienten über
den erfolgreichen Verbindungsaufbau. Danach können sowohl Client wie
auch der versteckte Service ihre Verbindungsstrecken zum
Rendezvouspunkt nutzen, um miteinander zu kommunizieren. Der
Rendezvouspunkt leitet die Nachrichten vom Client zum Service und
zurück weiter.

Eine der Gründe, nicht eher aufgebaute Strecken zu nutzen, ist die
Tatsache, dass kein einzelner Server verantwortlich für einen
bestimmten versteckten Dienst sein soll. Darum lernt der
Rendezvouspunkt nie die Identität des versteckten Dienstes kennen.

Im Allgemeinen besteht die komplette Verbindung zwischen dem Client
und dem versteckten Dienst aus sechs Tor-Servern. Drei wurden vom
Client und drei vom versteckten Dienst gewählt.

Es gibt detailliertere Beschreibungen zu dem Protokoll als diese
Seite. Schaue dir hierzu die
<a
href="<svnprojects>design-paper/tor-design.pdf">Designbeschreibung
von Tor</a> und die
<a
href="<gitblob>doc/spec/rend-spec.txt">Rendezvous-Spezifikation</a>
an. Dort findest du genauere Informationen.

</div>

#include <foot.wmi>

tor-webwml.git

Now that the design paper was moved back to Subversion, fix links (see tor.git changeset f164a76 and svn revision r21665). Found by katoda