Added some more details to the hidden service protocol description based on comments by `Orum and keb. (fa2c5337d)

@@ -9,10 +9,6 @@
 <h2>Tor: Hidden Service Protocol</h2>
 <hr />
 
-# TO TRANSLATORS: this page might still need some review and corrections!
-# better wait at least one week from today (2008-03-29) before starting
-# translation
-
 <p>
 A hidden service needs to advertise its existence in the Tor network before
 clients will be able to contact it. Therefore, the service randomly picks
@@ -35,8 +31,13 @@ containing the introduction points' addresses and its public key and signs
 it with its private key. It stores that descriptor on a set of directory
 servers, again using a circuit that hides the link between storing the
 descriptor with the hidden service's IP address. The descriptor will be
-found by clients requesting XYZ.onion where XYZ is uniquely derived from
-the service's public key. After this step, the hidden service is set up.
+found by clients requesting XYZ.onion where XYZ is a 16 characters long
+name that can be uniquely derived from the service's public key. Although
+it might seem impractical to use an automatically-generated service name,
+it serves an important goal: Everyone -- including the introduction points,
+the directory servers, and of course the clients -- can verify that they
+are talking to the hidden service. After this step, the hidden service is
+set up.
 </p>
 
 <img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png" />
@@ -77,6 +78,16 @@ creates a circuit to the rendezvous point and sends the one-time secret to
 it in a rendezvous message.
 </p>
 
+<p>
+At this point it is of special importance that the hidden service sticks to
+the same set of guard nodes for creating new circuits. Otherwise an attacker
+could run an own relay and force a hidden service to create an arbitrary
+number of circuits in the hope of the corrupt relay to be picked as entry
+node and learn the hidden service's IP address via timing analysis. This
+attack was described by &Oslash;verlier and Syverson in their paper titled
+Locating Hidden Services.
+</p>
+
 <img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png" />
 # it should say "Bob connects to Alice's ..."
 
@@ -88,8 +99,31 @@ other. The rendezvous point simply relays (end-to-end encrypted) messages
 from client to service and vice versa.
 </p>
 
+<p>
+One of the reasons for not using the earlier created connection via the
+introduction point for actual communication is that no single relay should
+appear to be responsible for a given hidden service. This is why the
+rendezvous point never learns about the hidden service's identity.
+</p>
+
+<p>
+In general, the complete connection between client and hidden service
+consists of 6 relays: 3 of them were picked by the client with the third
+being the rendezvous point and the other 3 were picked by the hidden
+service.
+</p>
+
 <img alt="Tor hidden service step six" src="$(IMGROOT)/THS-6.png" />
 
+<p>
+There are more detailed descriptions about the hidden service protocol than
+this one. See the
+<a href="<svnsandbox>doc/design-paper/tor-design.pdf">Tor design paper</a>
+for an in-depth design description and the
+<a href="<svnsandbox>doc/spec/rend-spec.txt">rendezvous specification</a>
+for the message formats.
+</p>
+
   </div><!-- #main -->
 
 #include <foot.wmi>


...	...	@@ -9,10 +9,6 @@
9	9	<h2>Tor: Hidden Service Protocol</h2>
10	10	<hr />
11	11
12		-# TO TRANSLATORS: this page might still need some review and corrections!
13		-# better wait at least one week from today (2008-03-29) before starting
14		-# translation
15		-
16	12	<p>
17	13	A hidden service needs to advertise its existence in the Tor network before
18	14	clients will be able to contact it. Therefore, the service randomly picks
...	...	@@ -35,8 +31,13 @@ containing the introduction points' addresses and its public key and signs
35	31	it with its private key. It stores that descriptor on a set of directory
36	32	servers, again using a circuit that hides the link between storing the
37	33	descriptor with the hidden service's IP address. The descriptor will be
38		-found by clients requesting XYZ.onion where XYZ is uniquely derived from
39		-the service's public key. After this step, the hidden service is set up.
	34	+found by clients requesting XYZ.onion where XYZ is a 16 characters long
	35	+name that can be uniquely derived from the service's public key. Although
	36	+it might seem impractical to use an automatically-generated service name,
	37	+it serves an important goal: Everyone -- including the introduction points,
	38	+the directory servers, and of course the clients -- can verify that they
	39	+are talking to the hidden service. After this step, the hidden service is
	40	+set up.
40	41	</p>
41	42
42	43	<img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png" />
...	...	@@ -77,6 +78,16 @@ creates a circuit to the rendezvous point and sends the one-time secret to
77	78	it in a rendezvous message.
78	79	</p>
79	80
	81	+<p>
	82	+At this point it is of special importance that the hidden service sticks to
	83	+the same set of guard nodes for creating new circuits. Otherwise an attacker
	84	+could run an own relay and force a hidden service to create an arbitrary
	85	+number of circuits in the hope of the corrupt relay to be picked as entry
	86	+node and learn the hidden service's IP address via timing analysis. This
	87	+attack was described by Øverlier and Syverson in their paper titled
	88	+Locating Hidden Services.
	89	+</p>
	90	+
80	91	<img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png" />
81	92	# it should say "Bob connects to Alice's ..."
82	93
...	...	@@ -88,8 +99,31 @@ other. The rendezvous point simply relays (end-to-end encrypted) messages
88	99	from client to service and vice versa.
89	100	</p>
90	101
	102	+<p>
	103	+One of the reasons for not using the earlier created connection via the
	104	+introduction point for actual communication is that no single relay should
	105	+appear to be responsible for a given hidden service. This is why the
	106	+rendezvous point never learns about the hidden service's identity.
	107	+</p>
	108	+
	109	+<p>
	110	+In general, the complete connection between client and hidden service
	111	+consists of 6 relays: 3 of them were picked by the client with the third
	112	+being the rendezvous point and the other 3 were picked by the hidden
	113	+service.
	114	+</p>
	115	+
91	116	<img alt="Tor hidden service step six" src="$(IMGROOT)/THS-6.png" />
92	117
	118	+<p>
	119	+There are more detailed descriptions about the hidden service protocol than
	120	+this one. See the
	121	+<a href="<svnsandbox>doc/design-paper/tor-design.pdf">Tor design paper</a>
	122	+for an in-depth design description and the
	123	+<a href="<svnsandbox>doc/spec/rend-spec.txt">rendezvous specification</a>
	124	+for the message formats.
	125	+</p>
	126	+
93	127	</div><!-- #main -->
94	128
95	129	#include <foot.wmi>
96	130

tor-webwml.git