tor-webwml.git

1) ## translation metadata

2) # Revision: $Revision$

3) # Translation-Priority: 3-low
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>

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 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 – 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 Ø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 -->