tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 17024

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

21) <p>Ein versteckter Service muss seine Existenz im Tor-Netzwerk bekannt

22)   machen, bevor er kontaktiert werden kann. Daher wählt der Service
23)   zufällig einige Tor-Server aus, baut Verbindungsstrecken auf und

24)   bittet diese, als <em>Einführungspunkte (introduction point)</em> zu

25)   agieren. Beachte bitte, dass in den folgenden Abildungen die grünen

26)   Verweise eher Verbindungsstrecken von mehreren beteilten Rechnern

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

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

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

32)   (IP-Adresse) erfahren.
33) </p>
34) 
35) <img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png" />
36) # maybe add a speech bubble containing "PK" to Bob, because that's what
37) # Bob tells to his introduction points
38) 
39) <p>Im zweiten Schritt generiert der versteckte Service einen

40)   <em>Deskriptor</em>. Dieser enthält die Adresse des Einführungspunktes und

41)   seinen öffentlichen Schlüssel. Der versteckte Service signiert die
42)   Informationen mit seinem privaten Schlüssel. Es speichert den

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

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

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

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

52)   reden. Nach diesem Schritt ist der versteckte Dienst bereit.
53) </p>
54) 

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

66) <img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png" />
67) # maybe replace "database" with "directory servers"; further: how incorrect
68) # is it to *not* add DB to the Tor cloud, now that begin dir cells are in
69) # use?
70) 
71) <p>Ein Programm, welches sich mit dem versteckten Dienst verbinden

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

76) der Client eine Strecke zu einem Tor-Server auf und bittet es, als

77) <em>Rendezvouspunkt zu</em> agieren. Dazu teilt er ihm ein einmaliges Geheimnis

78) mit.
79) </p>
80) 
81) <img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png" />
82) # maybe add "cookie" to speech bubble, separated from the surrounded
83) # "IP1-3" and "PK"
84) 
85) <p>Neben dem Aufbau der Verbindung zum Rendezvouspunkt muss das

86) Clientprogramm eine Nachricht an den <em>Einführungspunkt</em> erstellen

87) (verschlüsselt mit dem öffentlichen Schlüssel des versteckten
88) Dienstes.). Diese Nachricht schließt die Adresse des Rendezvouspunktes

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

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

93) gesichert.
94) </p>
95) 
96) <img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png" />
97) 

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

99) findet dort die Adresse des Rendezvouspunktes sowie das Geheimnis. Der
100) Dienst baut eine Strecke zum Rendezvouspunkt auf und sendet das
101) Geheimnis in einer Rendezvousnachricht.
102) </p>
103) 
104) <p>An diesem Punkt ist es besonders wichtig, dass der versteckte

105) Dienst <a href="<page faq>#EntryGuards">dieselben Knoten</a> zum Anlegen
106) neuer Strecken verwendet. Sonst

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

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

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

112) "<a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
113) Servers</a>" beschrieben.

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

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

121) auch der versteckte Service ihre Verbindungsstrecken zum
122) Rendezvouspunkt nutzen, um miteinander zu kommunizieren. Der
123) Rendezvouspunkt leitet die Nachrichten vom Client zum Service und

124) zurück weiter.

125) </p>
126) 

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

129) bestimmten versteckten Dienst sein soll. Darum lernt der

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

131) </p>
132) 
133) <p>Im Allgemeinen besteht die komplette Verbindung zwischen dem Client
134) und dem versteckten Dienst aus sechs Tor-Servern. Drei wurden vom

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

136) </p>
137) 
138) <img alt="Tor hidden service step six" src="$(IMGROOT)/THS-6.png" />
139) 
140) <p>Es gibt detailliertere Beschreibungen zu dem Protokoll als diese
141) Seite. Schaue dir hierzu die
142) <a

143) href="<svnprojects>design-paper/tor-design.pdf">Designbeschreibung

144) von Tor</a> und die
145) <a

146) href="<gitblob>doc/spec/rend-spec.txt">Rendezvous-Spezifikation</a>