docs/en/hidden-services.wml
2a9aaa80
 ## translation metadata
40e07e2e
 # Revision: $Revision$
2a9aaa80
 # Translation-Priority: 3-low
 
 #include "head.wmi" TITLE="Tor: Hidden Service Protocol" CHARSET="UTF-8"
 <div id="content" class="clearfix">
   <div id="breadcrumbs">
b289ef06
     <a href="<page index>">Home &raquo; </a>
2a9aaa80
     <a href="<page docs/documentation>">Documentation &raquo; </a>
     <a href="<page docs/hidden-services>">Hidden Services</a>
   </div>
1e42e693
   <div id="maincol">
2a9aaa80
     <h2>Tor: Hidden Service Protocol</h2>
ed5ac546
     <hr>
1e42e693
 
2a9aaa80
     <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>
1e42e693
 
2a9aaa80
     <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
     <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>
1e42e693
 
ed5ac546
     <img alt="Tor hidden service step one" src="$(IMGROOT)/THS-1.png">
2a9aaa80
     # maybe add a speech bubble containing "PK" to Bob, because that's what
     # Bob tells to his introduction points
1e42e693
 
2a9aaa80
     <p>
     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 distributed hash table. The descriptor will be
     found by clients requesting XYZ.onion where XYZ is a 16 character
2673ea96
     name derived from the service's public key. After
2a9aaa80
     this step, the hidden service is set up.
     </p>
1e42e693
 
2a9aaa80
     <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 distributed hash table directory, and of course the
     clients &ndash; can verify that they are talking to the right hidden
59126df8
     service. See also <a href="https://en.wikipedia.org/wiki/Zooko%27s_triangle">Zooko's
2a9aaa80
     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>
1e42e693
 
ed5ac546
     <img alt="Tor hidden service step two" src="$(IMGROOT)/THS-2.png">
2a9aaa80
     # maybe replace "database" with "DHT"; further: how incorrect
     # is it to *not* add DB to the Tor cloud, now that begin dir cells are in
     # use?
1e42e693
 
2a9aaa80
     <p>
1e2b76f5
     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 distributed hash table. 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 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.
2a9aaa80
     </p>
1e42e693
 
ed5ac546
     <img alt="Tor hidden service step three" src="$(IMGROOT)/THS-3.png">
2a9aaa80
     # maybe add "cookie" to speech bubble, separated from the surrounded
     # "IP1-3" and "PK"
1e42e693
 
2a9aaa80
     <p>
1e2b76f5
     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 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.
2a9aaa80
     </p>
1e42e693
 
ed5ac546
     <img alt="Tor hidden service step four" src="$(IMGROOT)/THS-4.png">
1e42e693
 
2a9aaa80
     <p>
     Step five: The hidden service decrypts the client's introduce message
1e2b76f5
     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.
2a9aaa80
     </p>
1e42e693
 
2a9aaa80
     <p>
     At this point it is of special importance that the hidden service sticks to
     the same set of <a
da280ad7
     href="<wikifaq>#Whatsthisaboutentryguardformerlyknownashelpernodes">entry
2a9aaa80
     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
     <a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
     Servers</a>.
     </p>
1e42e693
 
ed5ac546
     <img alt="Tor hidden service step five" src="$(IMGROOT)/THS-5.png">
2a9aaa80
     # it should say "Bob connects to Alice's ..."
1e42e693
 
2a9aaa80
     <p>
     In the last step, the rendezvous point notifies the client about successful
     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>
1e42e693
 
2a9aaa80
     <p>
     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>
1e42e693
 
2a9aaa80
     <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>
1e42e693
 
ed5ac546
     <img alt="Tor hidden service step six" src="$(IMGROOT)/THS-6.png">
1e42e693
 
2a9aaa80
     <p>
     There are more detailed descriptions about the hidden service protocol than
     this one. See the
     <a href="<svnprojects>design-paper/tor-design.pdf">Tor design paper</a>
     for an in-depth design description and the
c51bf859
     <a href="<specblob>rend-spec.txt">rendezvous specification</a>
2a9aaa80
     for the message formats.
     </p>
   </div>
   <!-- END MAINCOL -->
   <div id = "sidecol">
 #include "side.wmi"
 #include "info.wmi"
   </div>
   <!-- END SIDECOL -->
 </div>
 <!-- END CONTENT -->
1e42e693
 #include <foot.wmi>