rendezvous.txt 9.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200
  1. How to make rendezvous points work
  2. 0. Overview
  3. Rendezvous points are an implementation of location-hidden services
  4. (server anonymity) in the onion routing network. Location-hidden
  5. services means Bob can offer a tcp service (say, a webserver) via the
  6. onion routing network, without revealing the IP of that service.
  7. The basic idea is to provide censorship resistance for Bob by allowing
  8. him to advertise a variety of onion routers as his public location
  9. (nodes known as his Introduction Points, see Section 1). Alice,
  10. the client, chooses a node known as a Meeting Point (see Section
  11. 2). This extra level of indirection is needed so Bob doesn't serve
  12. files directly from his public locations (so these nodes don't open
  13. themselves up to abuse, eg from serving Nazi propaganda in France). The
  14. extra level of indirection also allows Bob to choose which requests
  15. to respond to, and which to ignore.
  16. We also provide the necessary glue code so that Alice can view webpages
  17. on a location-hidden webserver, and Bob can run a location-hidden
  18. server, with minimal invasive changes (see Section 3). Both Alice
  19. and Bob must run local onion proxies (OPs) -- software that knows
  20. how to talk to the onion routing network.
  21. The big picture follows. We direct the reader to the rest of the
  22. document for more details and explanation.
  23. 1) Bob chooses some Introduction Points, and advertises them on a
  24. Distributed Hash Table (DHT).
  25. 2) Bob establishes onion routing connections to each of his
  26. Introduction Points, and waits.
  27. 3) Alice learns about Bob's service out of band (perhaps Bob gave her
  28. a pointer, or she found it on a website). She looks up the details
  29. of Bob's service from the DHT.
  30. 4) Alice chooses and establishes a Meeting Point for this transaction.
  31. 5) Alice goes to one of Bob's Introduction Points, and gives it a blob
  32. (encrypted for Bob) which tells him about herself and the Meeting
  33. Point she chose. The Introduction Point sends the blob to Bob.
  34. 6) Bob chooses whether to ignore the blob, or to onion route to MP.
  35. Let's assume the latter.
  36. 7) MP plugs together Alice and Bob. Note that MP doesn't know (or care)
  37. who Alice is, or who Bob is; and it can't read anything they
  38. transmit either, because they share a session key.
  39. 8) Alice sends a 'begin' cell along the circuit. It makes its way
  40. to Bob's onion proxy. Bob's onion proxy connects to Bob's webserver.
  41. 9) Data goes back and forth as usual.
  42. 1. Introduction service
  43. Bob wants to learn about client requests for communication, but
  44. wants to avoid responding unnecessarily to unauthorized clients.
  45. Bob's proxy opens a circuit, and tells some onion router on that
  46. circuit to expect incoming connections, and notify Bob of them.
  47. When establishing such an introduction point, Bob provides the onion
  48. router with a public "introduction" key. The hash of this public
  49. key identifies a unique Bob, and (since Bob is required to sign his
  50. messages) prevents anybody else from usurping Bob's introduction
  51. point in the future. Additionally, Bob can use the same public key
  52. to establish an introduction point on another onion router (OR),
  53. and Alice can still be confident that Bob is the same server.
  54. (The set-up-an-introduction-point command should come via a
  55. RELAY_BIND_INTRODUCTION cell. This cell creates a new stream on the
  56. circuit from Bob to the introduction point.)
  57. ORs that support introduction run an introduction service on a
  58. separate port. When Alice wants to notify Bob of a meeting point,
  59. she connects (directly or via Tor) to the introduction port, and
  60. sends the following:
  61. MEETING REQUEST
  62. RSA-OAEP encrypted with server's public key:
  63. [20 bytes] Hash of Bob's public key (identifies which Bob to notify)
  64. [ 0 bytes] Initial authentication [optional]
  65. RSA encrypted with Bob's public key:
  66. [16 bytes] Symmetric key for encrypting blob past RSA
  67. [ 6 bytes] Meeting point (IP/port)
  68. [ 8 bytes] Meeting cookie
  69. [ 0 bytes] End-to-end authentication [optional]
  70. [98 bytes] g^x part 1 (inside the RSA)
  71. [30 bytes] g^x part 2 (symmetrically encrypted)
  72. The meeting point and meeting cookie allow Bob to contact Alice and
  73. prove his identity; the end-to-end authentication enables Bob to
  74. decide whether to talk to Alice; the initial authentication enables
  75. the meeting point to pre-screen introduction requests before sending
  76. them to Bob. (See Section 2 for a discussion of meeting points;
  77. see Section 1.1 for an example authentication mechanism.)
  78. The authentication steps are the appropriate places for the
  79. introduction server or Bob to do replay prevention, if desired.
  80. When the introduction point receives a valid meeting request, it
  81. sends the portion intended for Bob along the stream
  82. created by Bob's RELAY_BIND_INTRODUCTION. Bob then, at his
  83. discretion, connects to Alice's meeting point.
  84. 1.1. An example authentication scheme for introduction services
  85. Bob makes two short-term secrets SB and SN, and tells the
  86. introduction point about SN. Bob gives Alice a cookie consisting
  87. of A,B,C such that H(A|SB)=B and H(A|SN)=C. Alice's initial
  88. authentication is <A,C>; Alice's end-to-end authentication is <A,B>.
  89. [Maybe] Bob keeps a replay cache of A values, and doesn't allow any
  90. value to be used twice. Over time, Bob rotates SB and SN.
  91. [Maybe] Each 'A' has an expiration time built in to it.
  92. In reality, we'll want to pick a scheme that (a) wasn't invented from
  93. scratch in an evening, and (b) doesn't require Alice to remember this
  94. many bits (see section 3.2).
  95. 2. Meeting points
  96. For Bob to actually reply to Alice, Alice first establishes a
  97. circuit to an onion router R, and sends a RELAY_BIND_MEETING cell
  98. to that onion router. The RELAY_BIND_MEETING cell contains a
  99. 'Meeting cookie' (MC) that Bob can use to authenticate to R. R
  100. remembers the cookie and associates it with Alice.
  101. Later, Bob also routes to R and sends R a RELAY_JOIN_MEETING cell with
  102. the meeting cookie MC. After this point, R routes all traffic from
  103. Bob's circuit or Alice's circuit as if the two circuits were joined:
  104. any RELAY cells that are not for a recognized topic are passed down
  105. Alice or Bob's circuit. Bob's first cell to Alice contains g^y.
  106. To prevent R from reading their traffic, Alice and Bob derive two
  107. end-to-end keys from g^{xy}, and they each treat R as just another
  108. hop on the circuit. (These keys are used in addition to the series
  109. of encryption keys already in use on Alice and Bob's circuits.)
  110. Bob's OP accepts RELAY_BEGIN, RELAY_DATA, RELAY_END, and
  111. RELAY_SENDME cells from Alice. Alice's OP accepts RELAY_DATA,
  112. RELAY_END, and RELAY_SENDME cells from Bob. All RELAY_BEGIN cells
  113. to Bob must have target IP and port of zero; Bob's OP will redirect
  114. them to the actual target IP and port of Bob's server.
  115. Alice and Bob's OPs disallow CREATE or RELAY_EXTEND cells as usual.
  116. 3. Application interface
  117. 3.1. Application interface: server side
  118. Bob has a service that he wants to offer to the world but keep its
  119. location hidden. He configures his local OP to know about this
  120. service, including the following data:
  121. Local IP and port of the service
  122. Strategy for choosing introduction points
  123. (for now, just randomly pick among the ORs offering it)
  124. Strategy for user authentication
  125. (for now, just accept all users)
  126. Public (RSA) key (one for each service Bob offers)
  127. Bob chooses a set of N Introduction servers on which to advertise
  128. his service.
  129. We assume the existence of a robust decentralized efficient lookup
  130. system (call it "DHT" for distributed hash table -- note that the
  131. onion routers can run nodes). Bob publishes
  132. * Bob's Public Key for that service
  133. * Expiration date ("don't use after")
  134. * Introduction server 0 ... Introduction server N
  135. (All signed by Bob's Public Key)
  136. into DHT, indexed by the hash of Bob's Public Key. Bob should
  137. periodically republish his introduction information with a new
  138. expiration date (and possibly with new/different introduction servers
  139. if he wants), so Alice can trust that DHT is giving her an up-to-date
  140. version. The Chord CFS paper describes a sample DHT that allows
  141. authenticated updating.
  142. 3.2. Application interface: client side
  143. We require that the client interface remain a SOCKS proxy, and we
  144. require that Alice shouldn't have to modify her applications. Thus
  145. we encode all of the necessary information into the hostname (more
  146. correctly, fqdn) that Alice uses, eg when clicking on a url in her
  147. browser.
  148. To establish a connection to Bob, Alice needs to know an Introduction
  149. point, Bob's PK, and some authentication cookie. Because encoding this
  150. information into the hostname will be too long for a typical hostname,
  151. we instead use a layer of indirection. We encode a hash of Bob's PK
  152. (10 bytes is sufficient since we're not worrying about collisions),
  153. and also the authentication token (empty for now). Location-hidden
  154. services use the special top level domain called '.onion': thus
  155. hostnames take the form x.y.onion where x is the hash of PK, and y
  156. is the authentication cookie. If no cookie is required, the hostname
  157. can simply be of the form x.onion. Assuming only case insensitive
  158. alphanumeric and hyphen, we get a bit more than 6 bits encoded
  159. per character, meaning the x part of the hostname will be about
  160. 13 characters.
  161. Alice's onion proxy examines hostnames and recognizes when they're
  162. destined for a hidden server. If so, it decodes the PK and performs
  163. the steps in Section 0 above.