tor-webwml.git

1) ## translation metadata
2) # Based-On-Revision: 14229
3) # Last-Translator: jens@kubieziel.de
4) 

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

6) 
7) <div class="main-column">
8) 

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

10) <hr />
11) 
12) <p>Ein versteckter Service muss seine Existenz im Tor-Netzwerk bekannt

13)   machen, bevor er kontaktiert werden kann. Daher wählt der Service
14)   zufällig einige Tor-Server aus, baut Verbindungsstrecken auf und
15)   bittet diese, als Einführungspunkte (introduction point) zu
16)   agieren. Beachte bitte, dass in den folgenden Abildungen die grünen

17)   Verweise eher Verbindungsstrecken von mehreren beteilten Rechnern

18)   meint, als direkte Verbindungen. Das macht es für jeden unmöglich,
19)   den Einführungspunkt mit der IP-Adresse des versteckten Servers in

20)   Verbindung zu bringen. Dies ist wichtig, denn obwohl die

21)   Einführungspunkte und andere die Identität des versteckten Services
22)   (öffentlicher Schlüssel) kennen, dürfen sie nicht dessen Ort

23)   (IP-Adresse) erfahren.
24) </p>
25) 
26) <img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png" />
27) # maybe add a speech bubble containing "PK" to Bob, because that's what
28) # Bob tells to his introduction points
29) 
30) <p>Im zweiten Schritt generiert der versteckte Service einen

31)   Deskriptor. Dieser enthält die Adresse des Einführungspunktes und
32)   seinen öffentlichen Schlüssel. Der versteckte Service signiert die
33)   Informationen mit seinem privaten Schlüssel. Es speichert den

34)   Deskriptor bei Verzeichnisservern, indem er wieder eine
35)   Verbindungsstrecke nutzt. Wenn nun ein Client die Adresse XYZ.onion
36)   bei einem Verzeichnisserver nachfragt, wird der Deskriptor dort
37)   gefunden. Die Adresse XYZ ist dabei ein 16 Zeichen langer Name,

38)   der in eindeutiger Weise vom öffentlichen Schlüssel des versteckten
39)   Service abgeleitet wurde. Obwohl dieses Verfahren zunächst

40)   unpraktisch aussieht, dient es einem wichtigen Ziel: Jedermann –

41)   auch Einführungspunkte, Verzeichnisserver und natürlich Tor-Proxys
42)   – kann prüfen, ob sie wirklich mit dem versteckten Dienst

43)   reden. Nach diesem Schritt ist der versteckte Dienst bereit.
44) </p>
45) 
46) <img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png" />
47) # maybe replace "database" with "directory servers"; further: how incorrect
48) # is it to *not* add DB to the Tor cloud, now that begin dir cells are in
49) # use?
50) 
51) <p>Ein Programm, welches sich mit dem versteckten Dienst verbinden

52) möchte, muss zuerst von der Onionadresse wissen. Danach kann sich das
53) Programm verbinden. Es lädt den Deskriptor von den Verzeichnisservern
54) herunter. Wenn ein Deskriptor existiert (Der Dienst könnte auch
55) offline sein oder ein Fehler in der Onionadresse ist möglich.), baut

56) der Client eine Strecke zu einem Tor-Server auf und bittet es, als
57) Rendezvouspunkt zu agieren. Dazu teilt er ihm ein einmaliges Geheimnis
58) mit.
59) </p>
60) 
61) <img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png" />
62) # maybe add "cookie" to speech bubble, separated from the surrounded
63) # "IP1-3" and "PK"
64) 
65) <p>Neben dem Aufbau der Verbindung zum Rendezvouspunkt muss das

66) Clientprogramm eine Nachricht an den Einführungspunkt erstellen
67) (verschlüsselt mit dem öffentlichen Schlüssel des versteckten
68) Dienstes.). Diese Nachricht schließt die Adresse des Rendezvouspunktes

69) und das Geheimnis ein. Das Programm sendet die Nachricht an einen der

70) Einführungspunkte und bittet, diese an den versteckten Dienst zu
71) leiten. Wieder wird alle Kommunikation über Verbindungsstrecken im
72) Tor-Netzwerk abgewickelt. Damit wird die Anonymität des Clients

73) gesichert.
74) </p>
75) 
76) <img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png" />
77) 

78) <p>Der versteckte Dienst entschlüsselt die Nachricht des Clienten und

79) findet dort die Adresse des Rendezvouspunktes sowie das Geheimnis. Der
80) Dienst baut eine Strecke zum Rendezvouspunkt auf und sendet das
81) Geheimnis in einer Rendezvousnachricht.
82) </p>
83) 
84) <p>An diesem Punkt ist es besonders wichtig, dass der versteckte
85) Dienst dieselben Knoten zum Anlegen neuer Strecken verwendet. Sonst

86) könnte ein Angreifer einen eigenen Server betreiben und den
87) versteckten Dienst zwingen, eine Anzahl an Verbindungsstrecken über
88) ihn auszurichten. Über eine Analyse der Laufzeiten der Internetpakete

89) kann man so die IP-Adresse des Dienstes herausfinden. Der Angriff

90) wurde von Øverlier und Syverson in der Veröffentlichung

91) "Locating Hidden Servers" beschrieben.
92) </p>
93) 
94) <img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png" />
95) # it should say "Bob connects to Alice's ..."
96) 

97) <p>Im letzten Schritt informiert der Rendezvouspunkt den Clienten über
98) den erfolgreichen Verbindungsaufbau. Danach können sowohl Client wie

99) auch der versteckte Service ihre Verbindungsstrecken zum
100) Rendezvouspunkt nutzen, um miteinander zu kommunizieren. Der
101) Rendezvouspunkt leitet die Nachrichten vom Client zum Service und

102) zurück weiter.

103) </p>
104) 

105) <p>Eine der Gründe, nicht eher aufgebaute Strecken zu nutzen, ist die
106) Tatsache, dass kein einzelner Server verantwortlich für einen

107) bestimmten versteckten Dienst sein soll. Darum lernt der

108) Rendezvouspunkt nie die Identität des versteckten Dienstes kennen.

109) </p>
110) 
111) <p>Im Allgemeinen besteht die komplette Verbindung zwischen dem Client
112) und dem versteckten Dienst aus sechs Tor-Servern. Drei wurden vom

113) Client und drei vom versteckten Dienst gewählt.