Browse code

Change hidden -> onion. (See #24285)

Renamed files, made new files with old names for redirects, updated
links to use new URLs.

kat authored on 19/11/2017 22:01:11
Showing 1 changed files
... ...
@@ -1,162 +1,7 @@
1 1
 ## translation metadata
2 2
 # Revision: $Revision$
3
-# Translation-Priority: 3-low
3
+# Status: obsolete
4 4
 
5
-#include "head.wmi" TITLE="Tor: Onion Service Protocol" CHARSET="UTF-8"
6
-<div id="content" class="clearfix">
7
-  <div id="breadcrumbs">
8
-    <a href="<page index>">Home &raquo; </a>
9
-    <a href="<page docs/documentation>">Documentation &raquo; </a>
10
-    <a href="<page docs/hidden-services>">Onion Services</a>
11
-  </div>
12
-  <div id="maincol">
13
-    <h2>Tor: Onion Service Protocol</h2>
14
-    <hr>
5
+#include "head.wmi" TITLE="Redirecting" REDIRECT="docs/onion-services"
15 6
 
16
-    <p>
17
-    Tor makes it possible for users to hide their locations while offering
18
-    various kinds of services, such as web publishing or an instant
19
-    messaging server.  Using Tor "rendezvous points," other Tor users can
20
-	connect to these onion services, formerly known as hidden services, each
21
-	without knowing the other's network identity. This page describes the
22
-	technical details of how this rendezvous protocol works. For a more direct
23
-	how-to, see our <a href="<page docs/tor-hidden-service>">configuring onion
24
-	services</a> page.  </p>
25
-
26
-    <p>
27
-    An onion service needs to advertise its existence in the Tor network before
28
-    clients will be able to contact it. Therefore, the service randomly picks
29
-    some relays, builds circuits to them, and asks them to act as
30
-    <em>introduction points</em> by telling them its public key. Note
31
-    that in the following figures the green links are circuits rather
32
-    than direct connections. By using a full Tor circuit, it's hard for
33
-    anyone to associate an introduction point with the onion server's IP
34
-    address. While the introduction points and others are told the onion
35
-    service's identity (public key), we don't want them to learn about the
36
-    onion server's location (IP address).
37
-    </p>
38
-
39
-    <img alt="Tor onion service step one" src="$(IMGROOT)/tor-onion-services-1.png">
40
-    # maybe add a speech bubble containing "PK" to Bob, because that's what
41
-    # Bob tells to his introduction points
42
-
43
-    <p>
44
-	Step two: the onion service assembles an <em>onion service descriptor</em>,
45
-	containing its public key and a summary of each introduction point, and
46
-	signs this descriptor with its private key.  It uploads that descriptor to
47
-	a distributed hash table.  The descriptor will be found by clients
48
-	requesting XYZ.onion where XYZ is a 16 character name derived from the
49
-	service's public key. After this step, the onion service is set up.  </p>
50
-
51
-    <p>
52
-    Although it might seem impractical to use an automatically-generated
53
-    service name, it serves an important goal: Everyone &ndash; including
54
-	the introduction points, the distributed hash table directory, and of
55
-	course the clients &ndash; can verify that they are talking to the right
56
-	onion service. See also <a
57
-	href="https://en.wikipedia.org/wiki/Zooko%27s_triangle">Zooko's
58
-	conjecture</a> that out of Decentralized, Secure, and Human-Meaningful, you
59
-	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 onion service names?  </p>
62
-
63
-    <img alt="Tor onion service step two" src="$(IMGROOT)/tor-onion-services-2.png">
64
-    # maybe replace "database" with "DHT"; further: how incorrect
65
-    # is it to *not* add DB to the Tor cloud, now that begin dir cells are in
66
-    # use?
67
-
68
-    <p>
69
-    Step three: A client that wants to contact an onion service needs
70
-    to learn about its onion address first. After that, the client can
71
-    initiate connection establishment by downloading the descriptor from
72
-    the distributed hash table. If there is a descriptor for XYZ.onion
73
-    (the onion service could also be offline or have left long ago,
74
-    or there could be a typo in the onion address), the client now
75
-    knows the set of introduction points and the right public key to
76
-    use. Around this time, the client also creates a circuit to another
77
-    randomly picked relay and asks it to act as <em>rendezvous point</em>
78
-    by telling it a one-time secret.
79
-    </p>
80
-
81
-    <img alt="Tor onion service step three" src="$(IMGROOT)/tor-onion-services-3.png">
82
-    # maybe add "cookie" to speech bubble, separated from the surrounded
83
-    # "IP1-3" and "PK"
84
-
85
-    <p>
86
-    Step four: When the descriptor is present and the rendezvous
87
-    point is ready, the client assembles an <em>introduce</em> message
88
-    (encrypted to the onion service's public key) including the address
89
-    of the rendezvous point and the one-time secret. The client sends
90
-    this message to one of the introduction points, requesting it be
91
-    delivered to the onion service. Again, communication takes place
92
-    via a Tor circuit: nobody can relate sending the introduce message
93
-    to the client's IP address, so the client remains anonymous.
94
-    </p>
95
-
96
-    <img alt="Tor onion service step four" src="$(IMGROOT)/tor-onion-services-4.png">
97
-
98
-    <p>
99
-    Step five: The onion service decrypts the client's introduce message
100
-    and finds the address of the rendezvous point and the one-time secret
101
-    in it. The service creates a circuit to the rendezvous point and
102
-    sends the one-time secret to it in a rendezvous message.
103
-    </p>
104
-
105
-    <p>
106
-    At this point it is of special importance that the onion service sticks to
107
-    the same set of <a
108
-    href="<wikifaq>#Whatsthisaboutentryguardformerlyknownashelpernodes">entry
109
-    guards</a> when creating new circuits. Otherwise an attacker
110
-    could run his own relay and force an onion service to create an arbitrary
111
-    number of circuits in the hope that the corrupt relay is picked as entry
112
-    node and he learns the onion server's IP address via timing analysis. This
113
-    attack was described by &Oslash;verlier and Syverson in their paper titled
114
-    <a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
115
-    Servers</a>.
116
-    </p>
117
-
118
-    <img alt="Tor onion service step five" src="$(IMGROOT)/tor-onion-services-5.png">
119
-    # it should say "Bob connects to Alice's ..."
120
-
121
-    <p>
122
-    In the last step, the rendezvous point notifies the client about successful
123
-    connection establishment. After that, both client and onion service can
124
-    use their circuits to the rendezvous point for communicating with each
125
-    other. The rendezvous point simply relays (end-to-end encrypted) messages
126
-    from client to service and vice versa.
127
-    </p>
128
-
129
-    <p>
130
-    One of the reasons for not using the introduction circuit
131
-    for actual communication is that no single relay should
132
-    appear to be responsible for a given onion service. This is why the
133
-    rendezvous point never learns about the onion service's identity.
134
-    </p>
135
-
136
-    <p>
137
-    In general, the complete connection between client and onion service
138
-    consists of 6 relays: 3 of them were picked by the client with the third
139
-    being the rendezvous point and the other 3 were picked by the onion
140
-    service.
141
-    </p>
142
-
143
-    <img alt="Tor onion service step six" src="$(IMGROOT)/tor-onion-services-6.png">
144
-
145
-    <p>
146
-    There are more detailed descriptions about the onion service protocol than
147
-    this one. See the
148
-    <a href="<svnprojects>design-paper/tor-design.pdf">Tor design paper</a>
149
-    for an in-depth design description and the
150
-    <a href="<specblob>rend-spec.txt">rendezvous specification</a>
151
-    for the message formats.
152
-    </p>
153
-  </div>
154
-  <!-- END MAINCOL -->
155
-  <div id = "sidecol">
156
-#include "side.wmi"
157
-#include "info.wmi"
158
-  </div>
159
-  <!-- END SIDECOL -->
160
-</div>
161
-<!-- END CONTENT -->
162 7
 #include <foot.wmi>
Browse code

Update images to reflect onion (rather than hidden) terminology. (See #24286)

kat authored on 19/11/2017 20:42:58
Showing 1 changed files
... ...
@@ -36,7 +36,7 @@
36 36
     onion server's location (IP address).
37 37
     </p>
38 38
 
39
-    <img alt="Tor onion service step one" src="$(IMGROOT)/THS-1.png">
39
+    <img alt="Tor onion service step one" src="$(IMGROOT)/tor-onion-services-1.png">
40 40
     # maybe add a speech bubble containing "PK" to Bob, because that's what
41 41
     # Bob tells to his introduction points
42 42
 
... ...
@@ -60,7 +60,7 @@
60 60
 	href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>
61 61
 	design for onion service names?  </p>
62 62
 
63
-    <img alt="Tor onion service step two" src="$(IMGROOT)/THS-2.png">
63
+    <img alt="Tor onion service step two" src="$(IMGROOT)/tor-onion-services-2.png">
64 64
     # maybe replace "database" with "DHT"; further: how incorrect
65 65
     # is it to *not* add DB to the Tor cloud, now that begin dir cells are in
66 66
     # use?
... ...
@@ -78,7 +78,7 @@
78 78
     by telling it a one-time secret.
79 79
     </p>
80 80
 
81
-    <img alt="Tor onion service step three" src="$(IMGROOT)/THS-3.png">
81
+    <img alt="Tor onion service step three" src="$(IMGROOT)/tor-onion-services-3.png">
82 82
     # maybe add "cookie" to speech bubble, separated from the surrounded
83 83
     # "IP1-3" and "PK"
84 84
 
... ...
@@ -93,7 +93,7 @@
93 93
     to the client's IP address, so the client remains anonymous.
94 94
     </p>
95 95
 
96
-    <img alt="Tor onion service step four" src="$(IMGROOT)/THS-4.png">
96
+    <img alt="Tor onion service step four" src="$(IMGROOT)/tor-onion-services-4.png">
97 97
 
98 98
     <p>
99 99
     Step five: The onion service decrypts the client's introduce message
... ...
@@ -115,7 +115,7 @@
115 115
     Servers</a>.
116 116
     </p>
117 117
 
118
-    <img alt="Tor onion service step five" src="$(IMGROOT)/THS-5.png">
118
+    <img alt="Tor onion service step five" src="$(IMGROOT)/tor-onion-services-5.png">
119 119
     # it should say "Bob connects to Alice's ..."
120 120
 
121 121
     <p>
... ...
@@ -140,7 +140,7 @@
140 140
     service.
141 141
     </p>
142 142
 
143
-    <img alt="Tor onion service step six" src="$(IMGROOT)/THS-6.png">
143
+    <img alt="Tor onion service step six" src="$(IMGROOT)/tor-onion-services-6.png">
144 144
 
145 145
     <p>
146 146
     There are more detailed descriptions about the onion service protocol than
Browse code

Change hidden service to onion service. (See #24285)

kat authored on 16/11/2017 19:08:34
Showing 1 changed files
... ...
@@ -2,78 +2,75 @@
2 2
 # Revision: $Revision$
3 3
 # Translation-Priority: 3-low
4 4
 
5
-#include "head.wmi" TITLE="Tor: Hidden Service Protocol" CHARSET="UTF-8"
5
+#include "head.wmi" TITLE="Tor: Onion Service Protocol" CHARSET="UTF-8"
6 6
 <div id="content" class="clearfix">
7 7
   <div id="breadcrumbs">
8 8
     <a href="<page index>">Home &raquo; </a>
9 9
     <a href="<page docs/documentation>">Documentation &raquo; </a>
10
-    <a href="<page docs/hidden-services>">Hidden Services</a>
10
+    <a href="<page docs/hidden-services>">Onion Services</a>
11 11
   </div>
12 12
   <div id="maincol">
13
-    <h2>Tor: Hidden Service Protocol</h2>
13
+    <h2>Tor: Onion Service Protocol</h2>
14 14
     <hr>
15 15
 
16 16
     <p>
17 17
     Tor makes it possible for users to hide their locations while offering
18 18
     various kinds of services, such as web publishing or an instant
19 19
     messaging server.  Using Tor "rendezvous points," other Tor users can
20
-    connect to these hidden services, each without knowing the other's
21
-    network identity. This page describes the technical details of how
22
-    this rendezvous protocol works. For a more direct how-to, see our <a
23
-    href="<page docs/tor-hidden-service>">configuring hidden services</a>
24
-    page.
25
-    </p>
20
+	connect to these onion services, formerly known as hidden services, each
21
+	without knowing the other's network identity. This page describes the
22
+	technical details of how this rendezvous protocol works. For a more direct
23
+	how-to, see our <a href="<page docs/tor-hidden-service>">configuring onion
24
+	services</a> page.  </p>
26 25
 
27 26
     <p>
28
-    A hidden service needs to advertise its existence in the Tor network before
27
+    An onion service needs to advertise its existence in the Tor network before
29 28
     clients will be able to contact it. Therefore, the service randomly picks
30 29
     some relays, builds circuits to them, and asks them to act as
31 30
     <em>introduction points</em> by telling them its public key. Note
32 31
     that in the following figures the green links are circuits rather
33 32
     than direct connections. By using a full Tor circuit, it's hard for
34
-    anyone to associate an introduction point with the hidden server's IP
35
-    address. While the introduction points and others are told the hidden
33
+    anyone to associate an introduction point with the onion server's IP
34
+    address. While the introduction points and others are told the onion
36 35
     service's identity (public key), we don't want them to learn about the
37
-    hidden server's location (IP address).
36
+    onion server's location (IP address).
38 37
     </p>
39 38
 
40
-    <img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png">
39
+    <img alt="Tor onion service step one" src="$(IMGROOT)/THS-1.png">
41 40
     # maybe add a speech bubble containing "PK" to Bob, because that's what
42 41
     # Bob tells to his introduction points
43 42
 
44 43
     <p>
45
-    Step two: the hidden service assembles a <em>hidden service
46
-    descriptor</em>, containing its public key and a summary of each
47
-    introduction point, and signs this descriptor with its private key.
48
-    It uploads that descriptor to a distributed hash table. The descriptor will be
49
-    found by clients requesting XYZ.onion where XYZ is a 16 character
50
-    name derived from the service's public key. After
51
-    this step, the hidden service is set up.
52
-    </p>
44
+	Step two: the onion service assembles an <em>onion service descriptor</em>,
45
+	containing its public key and a summary of each introduction point, and
46
+	signs this descriptor with its private key.  It uploads that descriptor to
47
+	a distributed hash table.  The descriptor will be found by clients
48
+	requesting XYZ.onion where XYZ is a 16 character name derived from the
49
+	service's public key. After this step, the onion service is set up.  </p>
53 50
 
54 51
     <p>
55 52
     Although it might seem impractical to use an automatically-generated
56 53
     service name, it serves an important goal: Everyone &ndash; including
57
-    the introduction points, the distributed hash table directory, and of course the
58
-    clients &ndash; can verify that they are talking to the right hidden
59
-    service. See also <a href="https://en.wikipedia.org/wiki/Zooko%27s_triangle">Zooko's
60
-    conjecture</a> that out of Decentralized, Secure, and Human-Meaningful,
61
-    you can achieve at most two. Perhaps one day somebody will implement a <a
62
-    href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>
63
-    design for hidden service names?
64
-    </p>
65
-
66
-    <img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png">
54
+	the introduction points, the distributed hash table directory, and of
55
+	course the clients &ndash; can verify that they are talking to the right
56
+	onion service. See also <a
57
+	href="https://en.wikipedia.org/wiki/Zooko%27s_triangle">Zooko's
58
+	conjecture</a> that out of Decentralized, Secure, and Human-Meaningful, you
59
+	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 onion service names?  </p>
62
+
63
+    <img alt="Tor onion service step two" src="$(IMGROOT)/THS-2.png">
67 64
     # maybe replace "database" with "DHT"; further: how incorrect
68 65
     # is it to *not* add DB to the Tor cloud, now that begin dir cells are in
69 66
     # use?
70 67
 
71 68
     <p>
72
-    Step three: A client that wants to contact a hidden service needs
69
+    Step three: A client that wants to contact an onion service needs
73 70
     to learn about its onion address first. After that, the client can
74 71
     initiate connection establishment by downloading the descriptor from
75 72
     the distributed hash table. If there is a descriptor for XYZ.onion
76
-    (the hidden service could also be offline or have left long ago,
73
+    (the onion service could also be offline or have left long ago,
77 74
     or there could be a typo in the onion address), the client now
78 75
     knows the set of introduction points and the right public key to
79 76
     use. Around this time, the client also creates a circuit to another
... ...
@@ -81,49 +78,49 @@
81 78
     by telling it a one-time secret.
82 79
     </p>
83 80
 
84
-    <img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png">
81
+    <img alt="Tor onion service step three" src="$(IMGROOT)/THS-3.png">
85 82
     # maybe add "cookie" to speech bubble, separated from the surrounded
86 83
     # "IP1-3" and "PK"
87 84
 
88 85
     <p>
89 86
     Step four: When the descriptor is present and the rendezvous
90 87
     point is ready, the client assembles an <em>introduce</em> message
91
-    (encrypted to the hidden service's public key) including the address
88
+    (encrypted to the onion service's public key) including the address
92 89
     of the rendezvous point and the one-time secret. The client sends
93 90
     this message to one of the introduction points, requesting it be
94
-    delivered to the hidden service. Again, communication takes place
91
+    delivered to the onion service. Again, communication takes place
95 92
     via a Tor circuit: nobody can relate sending the introduce message
96 93
     to the client's IP address, so the client remains anonymous.
97 94
     </p>
98 95
 
99
-    <img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png">
96
+    <img alt="Tor onion service step four" src="$(IMGROOT)/THS-4.png">
100 97
 
101 98
     <p>
102
-    Step five: The hidden service decrypts the client's introduce message
99
+    Step five: The onion service decrypts the client's introduce message
103 100
     and finds the address of the rendezvous point and the one-time secret
104 101
     in it. The service creates a circuit to the rendezvous point and
105 102
     sends the one-time secret to it in a rendezvous message.
106 103
     </p>
107 104
 
108 105
     <p>
109
-    At this point it is of special importance that the hidden service sticks to
106
+    At this point it is of special importance that the onion service sticks to
110 107
     the same set of <a
111 108
     href="<wikifaq>#Whatsthisaboutentryguardformerlyknownashelpernodes">entry
112 109
     guards</a> when creating new circuits. Otherwise an attacker
113
-    could run his own relay and force a hidden service to create an arbitrary
110
+    could run his own relay and force an onion service to create an arbitrary
114 111
     number of circuits in the hope that the corrupt relay is picked as entry
115
-    node and he learns the hidden server's IP address via timing analysis. This
112
+    node and he learns the onion server's IP address via timing analysis. This
116 113
     attack was described by &Oslash;verlier and Syverson in their paper titled
117 114
     <a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
118 115
     Servers</a>.
119 116
     </p>
120 117
 
121
-    <img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png">
118
+    <img alt="Tor onion service step five" src="$(IMGROOT)/THS-5.png">
122 119
     # it should say "Bob connects to Alice's ..."
123 120
 
124 121
     <p>
125 122
     In the last step, the rendezvous point notifies the client about successful
126
-    connection establishment. After that, both client and hidden service can
123
+    connection establishment. After that, both client and onion service can
127 124
     use their circuits to the rendezvous point for communicating with each
128 125
     other. The rendezvous point simply relays (end-to-end encrypted) messages
129 126
     from client to service and vice versa.
... ...
@@ -132,21 +129,21 @@
132 129
     <p>
133 130
     One of the reasons for not using the introduction circuit
134 131
     for actual communication is that no single relay should
135
-    appear to be responsible for a given hidden service. This is why the
136
-    rendezvous point never learns about the hidden service's identity.
132
+    appear to be responsible for a given onion service. This is why the
133
+    rendezvous point never learns about the onion service's identity.
137 134
     </p>
138 135
 
139 136
     <p>
140
-    In general, the complete connection between client and hidden service
137
+    In general, the complete connection between client and onion service
141 138
     consists of 6 relays: 3 of them were picked by the client with the third
142
-    being the rendezvous point and the other 3 were picked by the hidden
139
+    being the rendezvous point and the other 3 were picked by the onion
143 140
     service.
144 141
     </p>
145 142
 
146
-    <img alt="Tor hidden service step six" src="$(IMGROOT)/THS-6.png">
143
+    <img alt="Tor onion service step six" src="$(IMGROOT)/THS-6.png">
147 144
 
148 145
     <p>
149
-    There are more detailed descriptions about the hidden service protocol than
146
+    There are more detailed descriptions about the onion service protocol than
150 147
     this one. See the
151 148
     <a href="<svnprojects>design-paper/tor-design.pdf">Tor design paper</a>
152 149
     for an in-depth design description and the
Browse code

zooko.com is broken, link to https://en.wikipedia.org/wiki/Zooko%27s_triangle instead

Peter Palfrader authored on 31/07/2016 11:53:52
Showing 1 changed files
... ...
@@ -56,7 +56,7 @@
56 56
     service name, it serves an important goal: Everyone &ndash; including
57 57
     the introduction points, the distributed hash table directory, and of course the
58 58
     clients &ndash; can verify that they are talking to the right hidden
59
-    service. See also <a href="http://zooko.com/distnames.html">Zooko's
59
+    service. See also <a href="https://en.wikipedia.org/wiki/Zooko%27s_triangle">Zooko's
60 60
     conjecture</a> that out of Decentralized, Secure, and Human-Meaningful,
61 61
     you can achieve at most two. Perhaps one day somebody will implement a <a
62 62
     href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>
Browse code

yuck trailing spaces

Sebastian Hahn authored on 11/02/2015 06:06:15
Showing 1 changed files
... ...
@@ -9,10 +9,10 @@
9 9
     <a href="<page docs/documentation>">Documentation &raquo; </a>
10 10
     <a href="<page docs/hidden-services>">Hidden Services</a>
11 11
   </div>
12
-  <div id="maincol"> 
12
+  <div id="maincol">
13 13
     <h2>Tor: Hidden Service Protocol</h2>
14 14
     <hr>
15
-    
15
+
16 16
     <p>
17 17
     Tor makes it possible for users to hide their locations while offering
18 18
     various kinds of services, such as web publishing or an instant
... ...
@@ -23,7 +23,7 @@
23 23
     href="<page docs/tor-hidden-service>">configuring hidden services</a>
24 24
     page.
25 25
     </p>
26
-    
26
+
27 27
     <p>
28 28
     A hidden service needs to advertise its existence in the Tor network before
29 29
     clients will be able to contact it. Therefore, the service randomly picks
... ...
@@ -36,11 +36,11 @@
36 36
     service's identity (public key), we don't want them to learn about the
37 37
     hidden server's location (IP address).
38 38
     </p>
39
-    
39
+
40 40
     <img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png">
41 41
     # maybe add a speech bubble containing "PK" to Bob, because that's what
42 42
     # Bob tells to his introduction points
43
-    
43
+
44 44
     <p>
45 45
     Step two: the hidden service assembles a <em>hidden service
46 46
     descriptor</em>, containing its public key and a summary of each
... ...
@@ -50,7 +50,7 @@
50 50
     name derived from the service's public key. After
51 51
     this step, the hidden service is set up.
52 52
     </p>
53
-    
53
+
54 54
     <p>
55 55
     Although it might seem impractical to use an automatically-generated
56 56
     service name, it serves an important goal: Everyone &ndash; including
... ...
@@ -62,12 +62,12 @@
62 62
     href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>
63 63
     design for hidden service names?
64 64
     </p>
65
-    
65
+
66 66
     <img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png">
67 67
     # maybe replace "database" with "DHT"; further: how incorrect
68 68
     # is it to *not* add DB to the Tor cloud, now that begin dir cells are in
69 69
     # use?
70
-    
70
+
71 71
     <p>
72 72
     Step three: A client that wants to contact a hidden service needs
73 73
     to learn about its onion address first. After that, the client can
... ...
@@ -80,11 +80,11 @@
80 80
     randomly picked relay and asks it to act as <em>rendezvous point</em>
81 81
     by telling it a one-time secret.
82 82
     </p>
83
-    
83
+
84 84
     <img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png">
85 85
     # maybe add "cookie" to speech bubble, separated from the surrounded
86 86
     # "IP1-3" and "PK"
87
-    
87
+
88 88
     <p>
89 89
     Step four: When the descriptor is present and the rendezvous
90 90
     point is ready, the client assembles an <em>introduce</em> message
... ...
@@ -95,16 +95,16 @@
95 95
     via a Tor circuit: nobody can relate sending the introduce message
96 96
     to the client's IP address, so the client remains anonymous.
97 97
     </p>
98
-    
98
+
99 99
     <img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png">
100
-    
100
+
101 101
     <p>
102 102
     Step five: The hidden service decrypts the client's introduce message
103 103
     and finds the address of the rendezvous point and the one-time secret
104 104
     in it. The service creates a circuit to the rendezvous point and
105 105
     sends the one-time secret to it in a rendezvous message.
106 106
     </p>
107
-    
107
+
108 108
     <p>
109 109
     At this point it is of special importance that the hidden service sticks to
110 110
     the same set of <a
... ...
@@ -117,10 +117,10 @@
117 117
     <a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
118 118
     Servers</a>.
119 119
     </p>
120
-    
120
+
121 121
     <img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png">
122 122
     # it should say "Bob connects to Alice's ..."
123
-    
123
+
124 124
     <p>
125 125
     In the last step, the rendezvous point notifies the client about successful
126 126
     connection establishment. After that, both client and hidden service can
... ...
@@ -128,23 +128,23 @@
128 128
     other. The rendezvous point simply relays (end-to-end encrypted) messages
129 129
     from client to service and vice versa.
130 130
     </p>
131
-    
131
+
132 132
     <p>
133 133
     One of the reasons for not using the introduction circuit
134 134
     for actual communication is that no single relay should
135 135
     appear to be responsible for a given hidden service. This is why the
136 136
     rendezvous point never learns about the hidden service's identity.
137 137
     </p>
138
-    
138
+
139 139
     <p>
140 140
     In general, the complete connection between client and hidden service
141 141
     consists of 6 relays: 3 of them were picked by the client with the third
142 142
     being the rendezvous point and the other 3 were picked by the hidden
143 143
     service.
144 144
     </p>
145
-    
145
+
146 146
     <img alt="Tor hidden service step six" src="$(IMGROOT)/THS-6.png">
147
-    
147
+
148 148
     <p>
149 149
     There are more detailed descriptions about the hidden service protocol than
150 150
     this one. See the
... ...
@@ -162,4 +162,4 @@
162 162
   <!-- END SIDECOL -->
163 163
 </div>
164 164
 <!-- END CONTENT -->
165
-#include <foot.wmi>  
165
+#include <foot.wmi>
Browse code

the .onion addresses are actually not uniquely derived from the service's key -- many different keys could in theory produce the same .onion address (though we hope they don't in practice).

Roger Dingledine authored on 24/08/2012 19:04:46
Showing 1 changed files
... ...
@@ -47,7 +47,7 @@
47 47
     introduction point, and signs this descriptor with its private key.
48 48
     It uploads that descriptor to a distributed hash table. The descriptor will be
49 49
     found by clients requesting XYZ.onion where XYZ is a 16 character
50
-    name that can be uniquely derived from the service's public key. After
50
+    name derived from the service's public key. After
51 51
     this step, the hidden service is set up.
52 52
     </p>
53 53
     
Browse code

update hidden service examples.

Andrew Lewman authored on 12/04/2012 14:34:34
Showing 1 changed files
... ...
@@ -69,17 +69,16 @@
69 69
     # use?
70 70
     
71 71
     <p>
72
-    Step three: A client that wants to contact a hidden service needs to
73
-    learn about its
74
-    onion address first. After that, the client can initiate connection
75
-    establishment by downloading the descriptor from the distributed hash
76
-    table. If
77
-    there is a descriptor for XYZ.onion (the hidden service could also be
78
-    offline or have left long ago, or there could be a typo in the onion
79
-    address), the client now knows the set of introduction points and the
80
-    right public key to use. Around this time, the client also creates
81
-    a circuit to another randomly picked relay and asks it to act as
82
-    <em>rendezvous point</em> by telling it a one-time secret.
72
+    Step three: A client that wants to contact a hidden service needs
73
+    to learn about its onion address first. After that, the client can
74
+    initiate connection establishment by downloading the descriptor from
75
+    the distributed hash table. If there is a descriptor for XYZ.onion
76
+    (the hidden service could also be offline or have left long ago,
77
+    or there could be a typo in the onion address), the client now
78
+    knows the set of introduction points and the right public key to
79
+    use. Around this time, the client also creates a circuit to another
80
+    randomly picked relay and asks it to act as <em>rendezvous point</em>
81
+    by telling it a one-time secret.
83 82
     </p>
84 83
     
85 84
     <img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png">
... ...
@@ -87,24 +86,23 @@
87 86
     # "IP1-3" and "PK"
88 87
     
89 88
     <p>
90
-    Step four: When the descriptor is present and the rendezvous point is
91
-    ready, the client assembles an <em>introduce</em>
92
-    message (encrypted to the hidden service's public key) including the
93
-    address of the rendezvous point and the one-time secret. The client sends
94
-    this message to one of the introduction points, requesting it be delivered
95
-    to the hidden service. Again, communication takes place via a Tor circuit:
96
-    nobody can relate sending the introduce message to the client's IP
97
-    address, so the client remains anonymous.
89
+    Step four: When the descriptor is present and the rendezvous
90
+    point is ready, the client assembles an <em>introduce</em> message
91
+    (encrypted to the hidden service's public key) including the address
92
+    of the rendezvous point and the one-time secret. The client sends
93
+    this message to one of the introduction points, requesting it be
94
+    delivered to the hidden service. Again, communication takes place
95
+    via a Tor circuit: nobody can relate sending the introduce message
96
+    to the client's IP address, so the client remains anonymous.
98 97
     </p>
99 98
     
100 99
     <img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png">
101 100
     
102 101
     <p>
103 102
     Step five: The hidden service decrypts the client's introduce message
104
-    and finds the
105
-    address of the rendezvous point and the one-time secret in it. The service
106
-    creates a circuit to the rendezvous point and sends the one-time secret to
107
-    it in a rendezvous message.
103
+    and finds the address of the rendezvous point and the one-time secret
104
+    in it. The service creates a circuit to the rendezvous point and
105
+    sends the one-time secret to it in a rendezvous message.
108 106
     </p>
109 107
     
110 108
     <p>
Browse code

Fix a link to the rend spec. Thanks keb

Sebastian Hahn authored on 17/03/2011 13:42:33
Showing 1 changed files
... ...
@@ -152,7 +152,7 @@
152 152
     this one. See the
153 153
     <a href="<svnprojects>design-paper/tor-design.pdf">Tor design paper</a>
154 154
     for an in-depth design description and the
155
-    <a href="<gitblob>doc/spec/rend-spec.txt">rendezvous specification</a>
155
+    <a href="<specblob>rend-spec.txt">rendezvous specification</a>
156 156
     for the message formats.
157 157
     </p>
158 158
   </div>
Browse code

alas, zooko.com appears to have its https version down

Roger Dingledine authored on 12/03/2011 22:24:27
Showing 1 changed files
... ...
@@ -56,7 +56,7 @@
56 56
     service name, it serves an important goal: Everyone &ndash; including
57 57
     the introduction points, the distributed hash table directory, and of course the
58 58
     clients &ndash; can verify that they are talking to the right hidden
59
-    service. See also <a href="https://zooko.com/distnames.html">Zooko's
59
+    service. See also <a href="http://zooko.com/distnames.html">Zooko's
60 60
     conjecture</a> that out of Decentralized, Secure, and Human-Meaningful,
61 61
     you can achieve at most two. Perhaps one day somebody will implement a <a
62 62
     href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>
Browse code

looks like we never set the keywords either

Roger Dingledine authored on 27/10/2010 12:31:57
Showing 1 changed files
... ...
@@ -1,5 +1,5 @@
1 1
 ## translation metadata
2
-# Revision: $Revision: 22359 $
2
+# Revision: $Revision$
3 3
 # Translation-Priority: 3-low
4 4
 
5 5
 #include "head.wmi" TITLE="Tor: Hidden Service Protocol" CHARSET="UTF-8"
Browse code

We decided to go with HTML in favor of XHTML.

Sebastian Hahn authored on 10/10/2010 03:34:47
Showing 1 changed files
... ...
@@ -11,7 +11,7 @@
11 11
   </div>
12 12
   <div id="maincol"> 
13 13
     <h2>Tor: Hidden Service Protocol</h2>
14
-    <hr />
14
+    <hr>
15 15
     
16 16
     <p>
17 17
     Tor makes it possible for users to hide their locations while offering
... ...
@@ -37,7 +37,7 @@
37 37
     hidden server's location (IP address).
38 38
     </p>
39 39
     
40
-    <img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png" />
40
+    <img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png">
41 41
     # maybe add a speech bubble containing "PK" to Bob, because that's what
42 42
     # Bob tells to his introduction points
43 43
     
... ...
@@ -63,7 +63,7 @@
63 63
     design for hidden service names?
64 64
     </p>
65 65
     
66
-    <img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png" />
66
+    <img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png">
67 67
     # maybe replace "database" with "DHT"; further: how incorrect
68 68
     # is it to *not* add DB to the Tor cloud, now that begin dir cells are in
69 69
     # use?
... ...
@@ -82,7 +82,7 @@
82 82
     <em>rendezvous point</em> by telling it a one-time secret.
83 83
     </p>
84 84
     
85
-    <img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png" />
85
+    <img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png">
86 86
     # maybe add "cookie" to speech bubble, separated from the surrounded
87 87
     # "IP1-3" and "PK"
88 88
     
... ...
@@ -97,7 +97,7 @@
97 97
     address, so the client remains anonymous.
98 98
     </p>
99 99
     
100
-    <img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png" />
100
+    <img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png">
101 101
     
102 102
     <p>
103 103
     Step five: The hidden service decrypts the client's introduce message
... ...
@@ -120,7 +120,7 @@
120 120
     Servers</a>.
121 121
     </p>
122 122
     
123
-    <img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png" />
123
+    <img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png">
124 124
     # it should say "Bob connects to Alice's ..."
125 125
     
126 126
     <p>
... ...
@@ -145,7 +145,7 @@
145 145
     service.
146 146
     </p>
147 147
     
148
-    <img alt="Tor hidden service step six" src="$(IMGROOT)/THS-6.png" />
148
+    <img alt="Tor hidden service step six" src="$(IMGROOT)/THS-6.png">
149 149
     
150 150
     <p>
151 151
     There are more detailed descriptions about the hidden service protocol than
Browse code

fix a bunch of broken links to the wiki and faq. use our tags more uniformly.

Roger Dingledine authored on 10/10/2010 01:35:02
Showing 1 changed files
... ...
@@ -110,7 +110,7 @@
110 110
     <p>
111 111
     At this point it is of special importance that the hidden service sticks to
112 112
     the same set of <a
113
-    href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Whatsthisaboutentryguardformerlyknownashelpernodes">entry
113
+    href="<wikifaq>#Whatsthisaboutentryguardformerlyknownashelpernodes">entry
114 114
     guards</a> when creating new circuits. Otherwise an attacker
115 115
     could run his own relay and force a hidden service to create an arbitrary
116 116
     number of circuits in the hope that the corrupt relay is picked as entry
Browse code

change all of the breadcrumbs from page home to page index.

Andrew Lewman authored on 12/08/2010 17:17:47
Showing 1 changed files
... ...
@@ -5,7 +5,7 @@
5 5
 #include "head.wmi" TITLE="Tor: Hidden Service Protocol" CHARSET="UTF-8"
6 6
 <div id="content" class="clearfix">
7 7
   <div id="breadcrumbs">
8
-    <a href="<page home>">Home &raquo; </a>
8
+    <a href="<page index>">Home &raquo; </a>
9 9
     <a href="<page docs/documentation>">Documentation &raquo; </a>
10 10
     <a href="<page docs/hidden-services>">Hidden Services</a>
11 11
   </div>
Browse code

first cut of the new, shiny tor website as wml.

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