tor-webwml.git

1) ## translation metadata

2) # Revision: $Revision$

3) # Translation-Priority: 3-low
4) 
5) #include "head.wmi" TITLE="Tor: Hidden Service Protocol"
6) 
7) <div class="main-column">
8) 
9) <h2>Tor: Hidden Service Protocol</h2>
10) <hr />
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) 

23) <p>
24) A hidden service needs to advertise its existence in the Tor network before
25) clients will be able to contact it. Therefore, the service randomly picks

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).

34) </p>
35) 
36) <img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png" />
37) # maybe add a speech bubble containing "PK" to Bob, because that's what
38) # Bob tells to his introduction points
39) 
40) <p>

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 &ndash; including
55) the introduction points, the directory servers, and of course the
56) clients &ndash; 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?

62) </p>
63) 
64) <img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png" />
65) # maybe replace "database" with "directory servers"; further: how incorrect
66) # is it to *not* add DB to the Tor cloud, now that begin dir cells are in
67) # use?
68) 
69) <p>

70) Step three: A client that wants to contact a hidden service needs to
71) learn about its

72) onion address first. After that, the client can initiate connection
73) establishment by downloading the descriptor from the directory servers. If
74) there is a descriptor for XYZ.onion (the hidden service could also be
75) offline or have left long ago, or there could be a typo in the onion

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.

80) </p>
81) 
82) <img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png" />
83) # maybe add "cookie" to speech bubble, separated from the surrounded
84) # "IP1-3" and "PK"
85) 
86) <p>

87) Step four: When the descriptor is present and the rendezvous point is
88) ready, the client assembles an <em>introduce</em>

89) message (encrypted to the hidden service's public key) including the
90) address of the rendezvous point and the one-time secret. The client sends

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.

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

100) Step five: The hidden service decrypts the client's introduce message
101) and finds the

102) address of the rendezvous point and the one-time secret in it. The service
103) creates a circuit to the rendezvous point and sends the one-time secret to
104) it in a rendezvous message.
105) </p>
106) 

107) <p>
108) At this point it is of special importance that the hidden service sticks to

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

115) attack was described by Øverlier and Syverson in their paper titled

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

118) </p>
119) 

120) <img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png" />
121) # it should say "Bob connects to Alice's ..."
122) 
123) <p>
124) In the last step, the rendezvous point notifies the client about successful

125) connection establishment. After that, both client and hidden service can

126) use their circuits to the rendezvous point for communicating with each
127) other. The rendezvous point simply relays (end-to-end encrypted) messages
128) from client to service and vice versa.
129) </p>
130) 

131) <p>

132) One of the reasons for not using the introduction circuit
133) for actual communication is that no single relay should

134) appear to be responsible for a given hidden service. This is why the
135) rendezvous point never learns about the hidden service's identity.
136) </p>
137) 
138) <p>
139) In general, the complete connection between client and hidden service
140) consists of 6 relays: 3 of them were picked by the client with the third
141) being the rendezvous point and the other 3 were picked by the hidden
142) service.
143) </p>
144) 

145) <img alt="Tor hidden service step six" src="$(IMGROOT)/THS-6.png" />
146) 

147) <p>
148) There are more detailed descriptions about the hidden service protocol than
149) this one. See the
150) <a href="<svnsandbox>doc/design-paper/tor-design.pdf">Tor design paper</a>
151) for an in-depth design description and the
152) <a href="<svnsandbox>doc/spec/rend-spec.txt">rendezvous specification</a>
153) for the message formats.
154) </p>
155)