touch up karsten's hidden service protocol summary (a3d53b7b5)

@@ -9,16 +9,28 @@
 <h2>Tor: Hidden Service Protocol</h2>
 <hr />
 
+<p>
+Tor makes it possible for users to hide their locations while offering
+various kinds of services, such as web publishing or an instant
+messaging server.  Using Tor "rendezvous points," other Tor users can
+connect to these hidden services, each without knowing the other's
+network identity. This page describes the technical details of how
+this rendezvous protocol works. For a more direct how-to, see our <a
+href="<page docs/tor-hidden-service>">configuring hidden services</a>
+page.
+</p>
+
 <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
-some relays, builds circuits to them, and asks them to act as introduction
-points telling them its public key. Note that in the following figures the
-green links are circuits rather than direct connections. This makes it
-impossible for anyone to associate the introduction points with the hidden
-server's IP address. This is important, because although the introduction
-points and others are told the hidden service's identity (public key), they
-must not learn about the hidden server's location (IP address).
+some relays, builds circuits to them, and asks them to act as
+<em>introduction points</em> by telling them its public key. Note
+that in the following figures the green links are circuits rather
+than direct connections. By using a full Tor circuit, it's hard for
+anyone to associate an introduction point with the hidden server's IP
+address. While the introduction points and others are told the hidden
+service's identity (public key), we don't want them to learn about the
+hidden server's location (IP address).
 </p>
 
 <img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png" />
@@ -26,19 +38,27 @@ must not learn about the hidden server's location (IP address).
 # Bob tells to his introduction points
 
 <p>
-In a second step, the hidden service assembles a hidden service descriptor
-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 the directory
-server storing the
-descriptor with the hidden server's IP address. The descriptor will be
-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 &ndash; including the introduction points,
-the directory servers, and of course the clients &ndash; can verify that they
-are talking to the hidden service. After this step, the hidden service is
-set up.
+Step two: the hidden service assembles a <em>hidden service
+descriptor</em>, containing its public key and a summary of each
+introduction point, and signs this descriptor with its private key.
+It uploads that descriptor to a set of directory servers, again using a
+full Tor circuit to hide the link between the directory server storing
+the descriptor and the hidden server's IP address. The descriptor will be
+found by clients requesting XYZ.onion where XYZ is a 16 character
+name that can be uniquely derived from the service's public key. After
+this step, the hidden service is set up.
+</p>
+
+<p>
+Although it might seem impractical to use an automatically-generated
+service name, it serves an important goal: Everyone &ndash; including
+the introduction points, the directory servers, and of course the
+clients &ndash; can verify that they are talking to the right hidden
+service. See also <a href="https://zooko.com/distnames.html">Zooko's
+conjecture</a> that out of Decentralized, Secure, and Human-Meaningful,
+you can achieve at most two. Perhaps one day somebody will implement a <a
+href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>
+design for hidden service names?
 </p>
 
 <img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png" />
@@ -47,13 +67,16 @@ set up.
 # use?
 
 <p>
-A client that wants to contact a hidden service needs to learn about its
+Step three: A client that wants to contact a hidden service needs to
+learn about its
 onion address first. After that, the client can initiate connection
 establishment by downloading the descriptor from the directory servers. If
 there is a descriptor for XYZ.onion (the hidden service could also be
 offline or have left long ago, or there could be a typo in the onion
-address), the client creates a circuit to another randomly picked relay and
-asks it to act as rendezvous point, telling it a one-time secret.
+address), the client now knows the set of introduction points and the
+right public key to use. Around this time, the client also creates
+a circuit to another randomly picked relay and asks it to act as
+<em>rendezvous point</em> by telling it a one-time secret.
 </p>
 
 <img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png" />
@@ -61,19 +84,21 @@ asks it to act as rendezvous point, telling it a one-time secret.
 # "IP1-3" and "PK"
 
 <p>
-Upon setting up the rendezvous point, the client assembles an introduce
+Step four: When the descriptor is present and the rendezvous point is
+ready, the client assembles an <em>introduce</em>
 message (encrypted to the hidden service's public key) including the
 address of the rendezvous point and the one-time secret. The client sends
-this message to one of the introduction points, requesting it to deliver it
-to the hidden service. Again, communication takes place via a circuit, so
-that nobody can relate sending the introduce message to the client's IP
-address, ensuring the client's anonymity.
+this message to one of the introduction points, requesting it be delivered
+to the hidden service. Again, communication takes place via a Tor circuit:
+nobody can relate sending the introduce message to the client's IP
+address, so the client remains anonymous.
 </p>
 
 <img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png" />
 
 <p>
-The hidden service decrypts the client's introduce message and finds the
+Step five: The hidden service decrypts the client's introduce message
+and finds the
 address of the rendezvous point and the one-time secret in it. The service
 creates a circuit to the rendezvous point and sends the one-time secret to
 it in a rendezvous message.
@@ -81,12 +106,15 @@ it in a rendezvous message.
 
 <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 server's IP address via timing analysis. This
+the same set of <a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#EntryGuards">entry
+guards</a> when creating new circuits. Otherwise an attacker
+could run his own relay and force a hidden service to create an arbitrary
+number of circuits in the hope that the corrupt relay is picked as entry
+node and he learns the hidden server's IP address via timing analysis. This
 attack was described by &Oslash;verlier and Syverson in their paper titled
-Locating Hidden Servers.
+<a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
+Servers</a>.
 </p>
 
 <img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png" />
@@ -94,15 +122,15 @@ Locating Hidden Servers.
 
 <p>
 In the last step, the rendezvous point notifies the client about successful
-connection establishment. After that, both, client and hidden service can
+connection establishment. After that, both client and hidden service can
 use their circuits to the rendezvous point for communicating with each
 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
+One of the reasons for not using the introduction circuit
+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>

...	...	@@ -9,16 +9,28 @@
9	9	<h2>Tor: Hidden Service Protocol</h2>
10	10	<hr />
11	11
	12	+<p>
	13	+Tor makes it possible for users to hide their locations while offering
	14	+various kinds of services, such as web publishing or an instant
	15	+messaging server. Using Tor "rendezvous points," other Tor users can
	16	+connect to these hidden services, each without knowing the other's
	17	+network identity. This page describes the technical details of how
	18	+this rendezvous protocol works. For a more direct how-to, see our <a
	19	+href="<page docs/tor-hidden-service>">configuring hidden services</a>
	20	+page.
	21	+</p>
	22	+
12	23	<p>
13	24	A hidden service needs to advertise its existence in the Tor network before
14	25	clients will be able to contact it. Therefore, the service randomly picks
15		-some relays, builds circuits to them, and asks them to act as introduction
16		-points telling them its public key. Note that in the following figures the
17		-green links are circuits rather than direct connections. This makes it
18		-impossible for anyone to associate the introduction points with the hidden
19		-server's IP address. This is important, because although the introduction
20		-points and others are told the hidden service's identity (public key), they
21		-must not learn about the hidden server's location (IP address).
	26	+some relays, builds circuits to them, and asks them to act as
	27	+<em>introduction points</em> by telling them its public key. Note
	28	+that in the following figures the green links are circuits rather
	29	+than direct connections. By using a full Tor circuit, it's hard for
	30	+anyone to associate an introduction point with the hidden server's IP
	31	+address. While the introduction points and others are told the hidden
	32	+service's identity (public key), we don't want them to learn about the
	33	+hidden server's location (IP address).
22	34	</p>
23	35
24	36	<img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png" />
...	...	@@ -26,19 +38,27 @@ must not learn about the hidden server's location (IP address).
26	38	# Bob tells to his introduction points
27	39
28	40	<p>
29		-In a second step, the hidden service assembles a hidden service descriptor
30		-containing the introduction points' addresses and its public key and signs
31		-it with its private key. It stores that descriptor on a set of directory
32		-servers, again using a circuit that hides the link between the directory
33		-server storing the
34		-descriptor with the hidden server's IP address. The descriptor will be
35		-found by clients requesting XYZ.onion where XYZ is a 16 characters long
36		-name that can be uniquely derived from the service's public key. Although
37		-it might seem impractical to use an automatically-generated service name,
38		-it serves an important goal: Everyone – including the introduction points,
39		-the directory servers, and of course the clients – can verify that they
40		-are talking to the hidden service. After this step, the hidden service is
41		-set up.
	41	+Step two: the hidden service assembles a <em>hidden service
	42	+descriptor</em>, containing its public key and a summary of each
	43	+introduction point, and signs this descriptor with its private key.
	44	+It uploads that descriptor to a set of directory servers, again using a
	45	+full Tor circuit to hide the link between the directory server storing
	46	+the descriptor and the hidden server's IP address. The descriptor will be
	47	+found by clients requesting XYZ.onion where XYZ is a 16 character
	48	+name that can be uniquely derived from the service's public key. After
	49	+this step, the hidden service is set up.
	50	+</p>
	51	+
	52	+<p>
	53	+Although it might seem impractical to use an automatically-generated
	54	+service name, it serves an important goal: Everyone – including
	55	+the introduction points, the directory servers, and of course the
	56	+clients – can verify that they are talking to the right hidden
	57	+service. See also <a href="https://zooko.com/distnames.html">Zooko's
	58	+conjecture</a> that out of Decentralized, Secure, and Human-Meaningful,
	59	+you can achieve at most two. Perhaps one day somebody will implement a <a
	60	+href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>
	61	+design for hidden service names?
42	62	</p>
43	63
44	64	<img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png" />
...	...	@@ -47,13 +67,16 @@ set up.
47	67	# use?
48	68
49	69	<p>
50		-A client that wants to contact a hidden service needs to learn about its
	70	+Step three: A client that wants to contact a hidden service needs to
	71	+learn about its
51	72	onion address first. After that, the client can initiate connection
52	73	establishment by downloading the descriptor from the directory servers. If
53	74	there is a descriptor for XYZ.onion (the hidden service could also be
54	75	offline or have left long ago, or there could be a typo in the onion
55		-address), the client creates a circuit to another randomly picked relay and
56		-asks it to act as rendezvous point, telling it a one-time secret.
	76	+address), the client now knows the set of introduction points and the
	77	+right public key to use. Around this time, the client also creates
	78	+a circuit to another randomly picked relay and asks it to act as
	79	+<em>rendezvous point</em> by telling it a one-time secret.
57	80	</p>
58	81
59	82	<img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png" />
...	...	@@ -61,19 +84,21 @@ asks it to act as rendezvous point, telling it a one-time secret.
61	84	# "IP1-3" and "PK"
62	85
63	86	<p>
64		-Upon setting up the rendezvous point, the client assembles an introduce
	87	+Step four: When the descriptor is present and the rendezvous point is
	88	+ready, the client assembles an <em>introduce</em>
65	89	message (encrypted to the hidden service's public key) including the
66	90	address of the rendezvous point and the one-time secret. The client sends
67		-this message to one of the introduction points, requesting it to deliver it
68		-to the hidden service. Again, communication takes place via a circuit, so
69		-that nobody can relate sending the introduce message to the client's IP
70		-address, ensuring the client's anonymity.
	91	+this message to one of the introduction points, requesting it be delivered
	92	+to the hidden service. Again, communication takes place via a Tor circuit:
	93	+nobody can relate sending the introduce message to the client's IP
	94	+address, so the client remains anonymous.
71	95	</p>
72	96
73	97	<img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png" />
74	98
75	99	<p>
76		-The hidden service decrypts the client's introduce message and finds the
	100	+Step five: The hidden service decrypts the client's introduce message
	101	+and finds the
77	102	address of the rendezvous point and the one-time secret in it. The service
78	103	creates a circuit to the rendezvous point and sends the one-time secret to
79	104	it in a rendezvous message.
...	...	@@ -81,12 +106,15 @@ it in a rendezvous message.
81	106
82	107	<p>
83	108	At this point it is of special importance that the hidden service sticks to
84		-the same set of guard nodes for creating new circuits. Otherwise an attacker
85		-could run an own relay and force a hidden service to create an arbitrary
86		-number of circuits in the hope of the corrupt relay to be picked as entry
87		-node and learn the hidden server's IP address via timing analysis. This
	109	+the same set of <a
	110	+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#EntryGuards">entry
	111	+guards</a> when creating new circuits. Otherwise an attacker
	112	+could run his own relay and force a hidden service to create an arbitrary
	113	+number of circuits in the hope that the corrupt relay is picked as entry
	114	+node and he learns the hidden server's IP address via timing analysis. This
88	115	attack was described by Øverlier and Syverson in their paper titled
89		-Locating Hidden Servers.
	116	+<a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
	117	+Servers</a>.
90	118	</p>
91	119
92	120	<img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png" />
...	...	@@ -94,15 +122,15 @@ Locating Hidden Servers.
94	122
95	123	<p>
96	124	In the last step, the rendezvous point notifies the client about successful
97		-connection establishment. After that, both, client and hidden service can
	125	+connection establishment. After that, both client and hidden service can
98	126	use their circuits to the rendezvous point for communicating with each
99	127	other. The rendezvous point simply relays (end-to-end encrypted) messages
100	128	from client to service and vice versa.
101	129	</p>
102	130
103	131	<p>
104		-One of the reasons for not using the earlier created connection via the
105		-introduction point for actual communication is that no single relay should
	132	+One of the reasons for not using the introduction circuit
	133	+for actual communication is that no single relay should
106	134	appear to be responsible for a given hidden service. This is why the
107	135	rendezvous point never learns about the hidden service's identity.
108	136	</p>

...	...	@@ -157,7 +157,7 @@ Germany. Coordinates the German Tor community with respect to legal
157	157	questions and concerns.</dd>
158	158	<dt>Shava Nerad</dt><dd>Our former Development Director. She still works
159	159	on PR and community relations.</dd>
160		-<dt>Lasse Øverlier</dt><dd>Writes research papers on Tor: attacks,
	160	+<dt>Lasse Øverlier</dt><dd>Writes research papers on Tor: attacks,
161	161	defenses, and resource management, especially for hidden services.</dd>
162	162	<dt>Kyle Williams</dt><dd>The other developer for
163	163	JanusVM, a VMWare-based
164	164

tor-webwml.git