git.schokokeks.org
Repositories
Help
Report an Issue
tor-webwml.git
Code
Commits
Branches
Tags
Suche
Strukturansicht:
b2539227d
Branches
Tags
bridges
docs-debian
jobs
master
press-clips
tor-webwml.git
de
hidden-services.wml
translated hidden-services (r14229)
Jens Kubieziel
commited
b2539227d
at 2008-05-17 15:44:17
hidden-services.wml
Blame
History
Raw
## translation metadata # Based-On-Revision: 14229 # Last-Translator: jens@kubieziel.de #include "head.wmi" TITLE="Tor: Protokoll f�r versteckte Dienste" <div class="main-column"> <h2>Tor: Protokoll f�r versteckte Dienste</h2> <hr /> <p>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. </p> <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 <p>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 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 – auch Einf�hrungspunkte, Verzeichnisserver und nat�rlich Tor-Proxys – kann pr�fen, ob sie wirklich mit dem versteckten Dienst reden. Nach diesem Schritt ist der versteckte Dienst bereit. </p> <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? <p>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. </p> <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" <p>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. </p> <img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png" /> <p>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. </p> <p>An diesem Punkt ist es besonders wichtig, dass der versteckte Dienst dieselben Knoten 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 Øverlier und Syverson in der Ver�ffentlichung "Locating Hidden Servers" beschrieben. </p> <img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png" /> # it should say "Bob connects to Alice's ..." <p>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. </p> <p>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. </p> <p>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. </p> <img alt="Tor hidden service step six" src="$(IMGROOT)/THS-6.png" /> <p>Es gibt detailliertere Beschreibungen zu dem Protokoll als diese Seite. Schaue dir hierzu die <a href="<svnsandbox>doc/design-paper/tor-design.pdf">Designbeschreibung von Tor</a> und die <a href="<svnsandbox>doc/spec/rend-spec.txt">Rendezvous-Spezifikation</a> an. Dort findest du genauere Informationen. </p> </div><!-- #main --> #include <foot.wmi>