| blob | f03009267963678de6dac4ccdb512895c747dac6 |
2 Tor Rendezvous Specification
4 0. Overview and preliminaries
6 Read
7 https://www.torproject.org/doc/design-paper/tor-design.html#sec:rendezvous
8 before you read this specification. It will make more sense.
10 Rendezvous points provide location-hidden services (server
11 anonymity) for the onion routing network. With rendezvous points,
12 Bob can offer a TCP service (say, a webserver) via the onion
13 routing network, without revealing the IP of that service.
15 Bob does this by anonymously advertising a public key for his
16 service, along with a list of onion routers to act as "Introduction
17 Points" for his service. He creates forward circuits to those
18 introduction points, and tells them about his public key. To
19 connect to Bob, Alice first builds a circuit to an OR to act as
20 her "Rendezvous Point." She then connects to one of Bob's chosen
21 introduction points, optionally provides authentication or
22 authorization information, and asks it to tell him about her Rendezvous
23 Point (RP). If Bob chooses to answer, he builds a circuit to her
24 RP, and tells it to connect him to Alice. The RP joins their
25 circuits together, and begins relaying cells. Alice's 'BEGIN'
26 cells are received directly by Bob's OP, which passes data to
27 and from the local server implementing Bob's service.
29 Below we describe a network-level specification of this service,
30 along with interfaces to make this process transparent to Alice
31 (so long as she is using an OP).
33 0.1. Notation, conventions and prerequisites
35 In the specifications below, we use the same notation and terminology
36 as in "tor-spec.txt". The service specified here also requires the
37 existence of an onion routing network as specified in that file.
39 H(x) is a SHA1 digest of x.
40 PKSign(SK,x) is a PKCS.1-padded RSA signature of x with SK.
41 PKEncrypt(SK,x) is a PKCS.1-padded RSA encryption of x with SK.
42 Public keys are all RSA, and encoded in ASN.1.
43 All integers are stored in network (big-endian) order.
44 All symmetric encryption uses AES in counter mode, except where
45 otherwise noted.
47 In all discussions, "Alice" will refer to a user connecting to a
48 location-hidden service, and "Bob" will refer to a user running a
49 location-hidden service.
51 An OP is (as defined elsewhere) an "Onion Proxy" or Tor client.
53 An OR is (as defined elsewhere) an "Onion Router" or Tor server.
55 An "Introduction point" is a Tor server chosen to be Bob's medium-term
56 'meeting place'. A "Rendezvous point" is a Tor server chosen by Alice to
57 be a short-term communication relay between her and Bob. All Tor servers
58 potentially act as introduction and rendezvous points.
60 0.2. Protocol outline
62 1. Bob->Bob's OP: "Offer IP:Port as
63 public-key-name:Port". [configuration]
64 (We do not specify this step; it is left to the implementor of
65 Bob's OP.)
67 2. Bob's OP generates keypair and rendezvous service descriptor:
68 "Meet public-key X at introduction point A, B, or C." (signed)
70 3. Bob's OP->Introduction point via Tor: [introduction setup]
71 "This pk is me."
73 4. Bob's OP->directory service via Tor: publishes Bob's service
74 descriptor [advertisement]
76 5. Out of band, Alice receives a [x.y.]z.onion:port address.
77 She opens a SOCKS connection to her OP, and requests
78 x.y.z.onion:port.
80 6. Alice's OP retrieves Bob's descriptor via Tor. [descriptor lookup.]
82 7. Alice's OP chooses a rendezvous point, opens a circuit to that
83 rendezvous point, and establishes a rendezvous circuit. [rendezvous
84 setup.]
86 8. Alice connects to the Introduction point via Tor, and tells it about
87 her rendezvous point and optional authentication/authorization
88 information. (Encrypted to Bob.) [Introduction 1]
90 9. The Introduction point passes this on to Bob's OP via Tor, along the
91 introduction circuit. [Introduction 2]
93 10. Bob's OP decides whether to connect to Alice, and if so, creates a
94 circuit to Alice's RP via Tor. Establishes a shared circuit.
95 [Rendezvous.]
97 11. Alice's OP sends begin cells to Bob's OP. [Connection]
99 0.3. Constants and new cell types
101 Relay cell types
102 32 -- RELAY_ESTABLISH_INTRO
103 33 -- RELAY_ESTABLISH_RENDEZVOUS
104 34 -- RELAY_INTRODUCE1
105 35 -- RELAY_INTRODUCE2
106 36 -- RELAY_RENDEZVOUS1
107 37 -- RELAY_RENDEZVOUS2
108 38 -- RELAY_INTRO_ESTABLISHED
109 39 -- RELAY_RENDEZVOUS_ESTABLISHED
110 40 -- RELAY_COMMAND_INTRODUCE_ACK
112 0.4. Version overview
114 There are several parts in the hidden service protocol that have
115 changed over time, each of them having its own version number, whereas
116 other parts remained the same. The following list of potentially
117 versioned protocol parts should help reduce some confusion:
119 - Hidden service descriptor: the binary-based v0 was the default for
120 a long time, and an ascii-based v2 has been added by proposal
121 114. See 1.2.
123 - Hidden service descriptor propagation mechanism: currently related to
124 the hidden service descriptor version -- v0 publishes to the original
125 hs directory authorities, whereas v2 publishes to a rotating subset
126 of relays with the "hsdir" flag; see 1.4 and 1.6.
128 - Introduction protocol for how to generate an introduction cell:
129 v0 specified a nickname for the rendezvous point and assumed the
130 relay would know about it, whereas v2 now specifies IP address,
131 port, and onion key so the relay doesn't need to already recognize
132 it. See 1.8.
134 1. The Protocol
136 1.1. Bob configures his local OP.
138 We do not specify a format for the OP configuration file. However,
139 OPs SHOULD allow Bob to provide more than one advertised service
140 per OP, and MUST allow Bob to specify one or more virtual ports per
141 service. Bob provides a mapping from each of these virtual ports
142 to a local IP:Port pair.
144 1.2. Bob's OP generates service descriptors.
146 The first time the OP provides an advertised service, it generates
147 a public/private keypair (stored locally).
149 Beginning with 0.2.0.10-alpha, Bob's OP encodes "V2" descriptors. The
150 format of a "V2" descriptor is as follows:
152 "rendezvous-service-descriptor" descriptor-id NL
154 [At start, exactly once]
156 Indicates the beginning of the descriptor. "descriptor-id" is a
157 periodically changing identifier of 160 bits formatted as 32 base32
158 chars that is calculated by the hidden service and its clients. If
159 the optional "descriptor-cookie" is used, this "descriptor-id"
160 cannot be computed by anyone else. (Everyone can verify that this
161 "descriptor-id" belongs to the rest of the descriptor, even without
162 knowing the optional "descriptor-cookie", as described below.) The
163 "descriptor-id" is calculated by performing the following operation:
165 descriptor-id =
166 H(permanent-id | H(time-period | descriptor-cookie | replica))
168 "permanent-id" is the permanent identifier of the hidden service,
169 consisting of 80 bits. It can be calculated by computing the hash value
170 of the public hidden service key and truncating after the first 80 bits:
172 permanent-id = H(public-key)[:10]
174 "H(time-period | descriptor-cookie | replica)" is the (possibly
175 secret) id part that is
176 necessary to verify that the hidden service is the true originator
177 of this descriptor. It can only be created by the hidden service
178 and its clients, but the "signature" below can only be created by
179 the service.
181 "descriptor-cookie" is an optional secret password of 128 bits that
182 is shared between the hidden service provider and its clients.
184 "replica" denotes the number of the non-consecutive replica.
186 (Each descriptor is replicated on a number of _consecutive_ nodes
187 in the identifier ring by making every storing node responsible
188 for the identifier intervals starting from its 3rd predecessor's
189 ID to its own ID. In addition to that, every service publishes
190 multiple descriptors with different descriptor IDs in order to
191 distribute them to different places on the ring. Therefore,
192 "replica" chooses one of the _non-consecutive_ replicas. -KL)
194 The "time-period" changes periodically depending on the global time and
195 as a function of "permanent-id". The current value for "time-period" can
196 be calculated using the following formula:
198 time-period = (current-time + permanent-id-byte * 86400 / 256)
199 / 86400
201 "current-time" contains the current system time in seconds since
202 1970-01-01 00:00, e.g. 1188241957. "permanent-id-byte" is the first
203 (unsigned) byte of the permanent identifier (which is in network
204 order), e.g. 143. Adding the product of "permanent-id-byte" and
205 86400 (seconds per day), divided by 256, prevents "time-period" from
206 changing for all descriptors at the same time of the day. The result
207 of the overall operation is a (network-ordered) 32-bit integer, e.g.
208 13753 or 0x000035B9 with the example values given above.
210 "version" version-number NL
212 [Exactly once]
214 The version number of this descriptor's format. In this case: 2.
216 "permanent-key" NL a public key in PEM format
218 [Exactly once]
220 The public key of the hidden service which is required to verify the
221 "descriptor-id" and the "signature".
223 "secret-id-part" secret-id-part NL
225 [Exactly once]
227 The result of the following operation as explained above, formatted as
228 32 base32 chars. Using this secret id part, everyone can verify that
229 the signed descriptor belongs to "descriptor-id".
231 secret-id-part = H(time-period | descriptor-cookie | replica)
233 "publication-time" YYYY-MM-DD HH:MM:SS NL
235 [Exactly once]
237 A timestamp when this descriptor has been created.
239 "protocol-versions" version-string NL
241 [Exactly once]
243 A comma-separated list of recognized and permitted version numbers
244 for use in INTRODUCE cells; these versions are described in section
245 1.8 below.
247 "introduction-points" NL encrypted-string
249 [At most once]
251 A list of introduction points. If the optional "descriptor-cookie" is
252 used, this list is encrypted with AES in CTR mode with a random
253 initialization vector of 128 bits that is written to
254 the beginning of the encrypted string, and the "descriptor-cookie" as
255 secret key of 128 bits length.
257 The string containing the introduction point data (either encrypted
258 or not) is encoded in base64, and surrounded with
259 "-----BEGIN MESSAGE-----" and "-----END MESSAGE-----".
261 The unencrypted string may begin with:
263 ["service-authentication" auth-type NL auth-data ... reserved]
265 [At start, any number]
267 The service-specific authentication data can be used to perform
268 client authentication. This data is independent of the selected
269 introduction point as opposed to "intro-authentication" below.
271 Subsequently, an arbitrary number of introduction point entries may
272 follow, each containing the following data:
274 "introduction-point" identifier NL
276 [At start, exactly once]
278 The identifier of this introduction point: the base-32 encoded
279 hash of this introduction point's identity key.
281 "ip-address" ip-address NL
283 [Exactly once]
285 The IP address of this introduction point.
287 "onion-port" port NL
289 [Exactly once]
291 The TCP port on which the introduction point is listening for
292 incoming onion requests.
294 "onion-key" NL a public key in PEM format
296 [Exactly once]
298 The public key that can be used to encrypt messages to this
299 introduction point.
301 "service-key" NL a public key in PEM format
303 [Exactly once]
305 The public key that can be used to encrypt messages to the hidden
306 service.
308 ["intro-authentication" auth-type NL auth-data ... reserved]
310 [Any number]
312 The introduction-point-specific authentication data can be used
313 to perform client authentication. This data depends on the
314 selected introduction point as opposed to "service-authentication"
315 above.
317 (This ends the fields in the encrypted portion of the descriptor.)
319 [It's ok for Bob to advertise 0 introduction points. He might want
320 to do that if he previously advertised some introduction points,
321 and now he doesn't have any. -RD]
323 "signature" NL signature-string
325 [At end, exactly once]
327 A signature of all fields above with the private key of the hidden
328 service.
330 1.2.1. Other descriptor formats we don't use.
332 Support for the V0 descriptor format was dropped in 0.2.2.0-alpha-dev:
334 KL Key length [2 octets]
335 PK Bob's public key [KL octets]
336 TS A timestamp [4 octets]
337 NI Number of introduction points [2 octets]
338 Ipt A list of NUL-terminated ORs [variable]
339 SIG Signature of above fields [variable]
341 KL is the length of PK, in octets.
342 TS is the number of seconds elapsed since Jan 1, 1970.
344 The members of Ipt may be either (a) nicknames, or (b) identity key
345 digests, encoded in hex, and prefixed with a '$'.
347 The V1 descriptor format was understood and accepted from
348 0.1.1.5-alpha-cvs to 0.2.0.6-alpha-dev, but no Tors generated it and
349 it was removed:
351 V Format byte: set to 255 [1 octet]
352 V Version byte: set to 1 [1 octet]
353 KL Key length [2 octets]
354 PK Bob's public key [KL octets]
355 TS A timestamp [4 octets]
356 PROTO Protocol versions: bitmask [2 octets]
357 NI Number of introduction points [2 octets]
358 For each introduction point: (as in INTRODUCE2 cells)
359 IP Introduction point's address [4 octets]
360 PORT Introduction point's OR port [2 octets]
361 ID Introduction point identity ID [20 octets]
362 KLEN Length of onion key [2 octets]
363 KEY Introduction point onion key [KLEN octets]
364 SIG Signature of above fields [variable]
366 A hypothetical "V1" descriptor, that has never been used but might
367 be useful for historical reasons, contains:
369 V Format byte: set to 255 [1 octet]
370 V Version byte: set to 1 [1 octet]
371 KL Key length [2 octets]
372 PK Bob's public key [KL octets]
373 TS A timestamp [4 octets]
374 PROTO Rendezvous protocol versions: bitmask [2 octets]
375 NA Number of auth mechanisms accepted [1 octet]
376 For each auth mechanism:
377 AUTHT The auth type that is supported [2 octets]
378 AUTHL Length of auth data [1 octet]
379 AUTHD Auth data [variable]
380 NI Number of introduction points [2 octets]
381 For each introduction point: (as in INTRODUCE2 cells)
382 ATYPE An address type (typically 4) [1 octet]
383 ADDR Introduction point's IP address [4 or 16 octets]
384 PORT Introduction point's OR port [2 octets]
385 AUTHT The auth type that is supported [2 octets]
386 AUTHL Length of auth data [1 octet]
387 AUTHD Auth data [variable]
388 ID Introduction point identity ID [20 octets]
389 KLEN Length of onion key [2 octets]
390 KEY Introduction point onion key [KLEN octets]
391 SIG Signature of above fields [variable]
393 AUTHT specifies which authentication/authorization mechanism is
394 required by the hidden service or the introduction point. AUTHD
395 is arbitrary data that can be associated with an auth approach.
396 Currently only AUTHT of [00 00] is supported, with an AUTHL of 0.
397 See section 2 of this document for details on auth mechanisms.
399 1.3. Bob's OP establishes his introduction points.
401 The OP establishes a new introduction circuit to each introduction
402 point. These circuits MUST NOT be used for anything but hidden service
403 introduction. To establish the introduction, Bob sends a
404 RELAY_ESTABLISH_INTRO cell, containing:
406 KL Key length [2 octets]
407 PK Introduction public key [KL octets]
408 HS Hash of session info [20 octets]
409 SIG Signature of above information [variable]
411 [XXX011, need to add auth information here. -RD]
413 To prevent replay attacks, the HS field contains a SHA-1 hash based on the
414 shared secret KH between Bob's OP and the introduction point, as
415 follows:
416 HS = H(KH | "INTRODUCE")
417 That is:
418 HS = H(KH | [49 4E 54 52 4F 44 55 43 45])
419 (KH, as specified in tor-spec.txt, is H(g^xy | [00]) .)
421 Upon receiving such a cell, the OR first checks that the signature is
422 correct with the included public key. If so, it checks whether HS is
423 correct given the shared state between Bob's OP and the OR. If either
424 check fails, the OP discards the cell; otherwise, it associates the
425 circuit with Bob's public key, and dissociates any other circuits
426 currently associated with PK. On success, the OR sends Bob a
427 RELAY_INTRO_ESTABLISHED cell with an empty payload.
429 Bob's OP does not include its own public key in the RELAY_ESTABLISH_INTRO
430 cell, but the public key of a freshly generated introduction key pair.
431 The OP also includes these fresh public keys in the v2 hidden service
432 descriptor together with the other introduction point information. The
433 reason is that the introduction point does not need to and therefore
434 should not know for which hidden service it works, so as to prevent it
435 from tracking the hidden service's activity.
437 1.4. Bob's OP advertises his service descriptor(s).
439 Bob's OP opens a stream to each directory server's directory port via Tor.
440 (He may re-use old circuits for this.) Over this stream, Bob's OP makes
441 an HTTP 'POST' request, to a URL "/tor/rendezvous/publish" relative to the
442 directory server's root, containing as its body Bob's service descriptor.
444 Bob should upload a service descriptor for each version format that
445 is supported in the current Tor network.
447 Upon receiving a descriptor, the directory server checks the signature,
448 and discards the descriptor if the signature does not match the enclosed
449 public key. Next, the directory server checks the timestamp. If the
450 timestamp is more than 24 hours in the past or more than 1 hour in the
451 future, or the directory server already has a newer descriptor with the
452 same public key, the server discards the descriptor. Otherwise, the
453 server discards any older descriptors with the same public key and
454 version format, and associates the new descriptor with the public key.
455 The directory server remembers this descriptor for at least 24 hours
456 after its timestamp. At least every 18 hours, Bob's OP uploads a
457 fresh descriptor.
459 Bob's OP publishes v2 descriptors to a changing subset of all v2 hidden
460 service directories. Therefore, Bob's OP opens a stream via Tor to each
461 responsible hidden service directory. (He may re-use old circuits
462 for this.) Over this stream, Bob's OP makes an HTTP 'POST' request to a
463 URL "/tor/rendezvous2/publish" relative to the hidden service
464 directory's root, containing as its body Bob's service descriptor.
466 At any time, there are 6 hidden service directories responsible for
467 keeping replicas of a descriptor; they consist of 2 sets of 3 hidden
468 service directories with consecutive onion IDs. Bob's OP learns about
469 the complete list of hidden service directories by filtering the
470 consensus status document received from the directory authorities. A
471 hidden service directory is deemed responsible for all descriptor IDs in
472 the interval from its direct predecessor, exclusive, to its own ID,
473 inclusive; it further holds replicas for its 2 predecessors. A
474 participant only trusts its own routing list and never learns about
475 routing information from other parties.
477 Bob's OP publishes a new v2 descriptor once an hour or whenever its
478 content changes. V2 descriptors can be found by clients within a given
479 time period of 24 hours, after which they change their ID as described
480 under 1.2. If a published descriptor would be valid for less than 60
481 minutes (= 2 x 30 minutes to allow the server to be 30 minutes behind
482 and the client 30 minutes ahead), Bob's OP publishes the descriptor
483 under the ID of both, the current and the next publication period.
485 1.5. Alice receives a x.y.z.onion address.
487 When Alice receives a pointer to a location-hidden service, it is as a
488 hostname of the form "z.onion" or "y.z.onion" or "x.y.z.onion", where
489 z is a base-32 encoding of a 10-octet hash of Bob's service's public
490 key, computed as follows:
492 1. Let H = H(PK).
493 2. Let H' = the first 80 bits of H, considering each octet from
494 most significant bit to least significant bit.
495 2. Generate a 16-character encoding of H', using base32 as defined
496 in RFC 3548.
498 (We only use 80 bits instead of the 160 bits from SHA1 because we
499 don't need to worry about arbitrary collisions, and because it will
500 make handling the url's more convenient.)
502 The string "x", if present, is the base-32 encoding of the
503 authentication/authorization required by the introduction point.
504 The string "y", if present, is the base-32 encoding of the
505 authentication/authorization required by the hidden service.
506 Omitting a string is taken to mean auth type [00 00].
507 See section 2 of this document for details on auth mechanisms.
509 [Yes, numbers are allowed at the beginning. See RFC 1123. -NM]
511 1.6. Alice's OP retrieves a service descriptor.
513 Similarly to the description in section 1.4, Alice's OP fetches a v2
514 descriptor from a randomly chosen hidden service directory out of the
515 changing subset of 6 nodes. If the request is unsuccessful, Alice retries
516 the other remaining responsible hidden service directories in a random
517 order. Alice relies on Bob to care about a potential clock skew between
518 the two by possibly storing two sets of descriptors (see end of section
519 1.4).
521 Alice's OP opens a stream via Tor to the chosen v2 hidden service
522 directory. (She may re-use old circuits for this.) Over this stream,
523 Alice's OP makes an HTTP 'GET' request for the document
524 "/tor/rendezvous2/<z>", where z is replaced with the encoding of the
525 descriptor ID. The directory replies with a 404 HTTP response if it does
526 not recognize <z>, and otherwise returns Bob's most recently uploaded
527 service descriptor.
529 If Alice's OP receives a 404 response, it tries the other directory
530 servers, and only fails the lookup if none recognize the public key hash.
532 Upon receiving a service descriptor, Alice verifies with the same process
533 as the directory server uses, described above in section 1.4.
535 The directory server gives a 400 response if it cannot understand Alice's
536 request.
538 Alice should cache the descriptor locally, but should not use
539 descriptors that are more than 24 hours older than their timestamp.
540 [Caching may make her partitionable, but she fetched it anonymously,
541 and we can't very well *not* cache it. -RD]
543 1.7. Alice's OP establishes a rendezvous point.
545 When Alice requests a connection to a given location-hidden service,
546 and Alice's OP does not have an established circuit to that service,
547 the OP builds a rendezvous circuit. It does this by establishing
548 a circuit to a randomly chosen OR, and sending a
549 RELAY_ESTABLISH_RENDEZVOUS cell to that OR. The body of that cell
550 contains:
552 RC Rendezvous cookie [20 octets]
554 [XXX011 this looks like an auth mechanism. should we generalize here? -RD]
556 The rendezvous cookie is an arbitrary 20-byte value, chosen randomly by
557 Alice's OP.
559 Upon receiving a RELAY_ESTABLISH_RENDEZVOUS cell, the OR associates the
560 RC with the circuit that sent it. It replies to Alice with an empty
561 RELAY_RENDEZVOUS_ESTABLISHED cell to indicate success.
563 Alice's OP MUST NOT use the circuit which sent the cell for any purpose
564 other than rendezvous with the given location-hidden service.
566 1.8. Introduction: from Alice's OP to Introduction Point
568 Alice builds a separate circuit to one of Bob's chosen introduction
569 points, and sends it a RELAY_INTRODUCE1 cell containing:
571 Cleartext
572 PK_ID Identifier for Bob's PK [20 octets]
573 Encrypted to Bob's PK: (in the v0 intro protocol)
574 RP Rendezvous point's nickname [20 octets]
575 RC Rendezvous cookie [20 octets]
576 g^x Diffie-Hellman data, part 1 [128 octets]
577 OR (in the v1 intro protocol)
578 VER Version byte: set to 1. [1 octet]
579 RP Rendezvous point nick or ID [42 octets]
580 RC Rendezvous cookie [20 octets]
581 g^x Diffie-Hellman data, part 1 [128 octets]
582 OR (in the v2 intro protocol)
583 VER Version byte: set to 2. [1 octet]
584 IP Rendezvous point's address [4 octets]
585 PORT Rendezvous point's OR port [2 octets]
586 ID Rendezvous point identity ID [20 octets]
587 KLEN Length of onion key [2 octets]
588 KEY Rendezvous point onion key [KLEN octets]
589 RC Rendezvous cookie [20 octets]
590 g^x Diffie-Hellman data, part 1 [128 octets]
592 PK_ID is the hash of Bob's public key. RP is NUL-padded and
593 terminated. In version 0, it must contain a nickname. In version 1,
594 it must contain EITHER a nickname or an identity key digest that is
595 encoded in hex and prefixed with a '$'.
597 The hybrid encryption to Bob's PK works just like the hybrid
598 encryption in CREATE cells (see tor-spec). Thus the payload of the
599 version 0 RELAY_INTRODUCE1 cell on the wire will contain
600 20+42+16+20+20+128=246 bytes, and the version 1 and version 2
601 introduction formats have other sizes.
603 Through Tor 0.2.0.6-alpha, clients only generated the v0 introduction
604 format, whereas hidden services have understood and accepted v0,
605 v1, and v2 since 0.1.1.x. As of Tor 0.2.0.7-alpha and 0.1.2.18,
606 clients switched to using the v2 intro format.
608 If Alice has downloaded a v2 descriptor, she uses the contained public
609 key ("service-key") instead of Bob's public key to create the
610 RELAY_INTRODUCE1 cell as described above.
612 1.8.1. Other introduction formats we don't use.
614 We briefly speculated about using the following format for the
615 "encrypted to Bob's PK" part of the introduction, but no Tors have
616 ever generated these.
618 VER Version byte: set to 3. [1 octet]
619 ATYPE An address type (typically 4) [1 octet]
620 ADDR Rendezvous point's IP address [4 or 16 octets]
621 PORT Rendezvous point's OR port [2 octets]
622 AUTHT The auth type that is supported [2 octets]
623 AUTHL Length of auth data [1 octet]
624 AUTHD Auth data [variable]
625 ID Rendezvous point identity ID [20 octets]
626 KLEN Length of onion key [2 octets]
627 KEY Rendezvous point onion key [KLEN octets]
628 RC Rendezvous cookie [20 octets]
629 g^x Diffie-Hellman data, part 1 [128 octets]
631 1.9. Introduction: From the Introduction Point to Bob's OP
633 If the Introduction Point recognizes PK_ID as a public key which has
634 established a circuit for introductions as in 1.3 above, it sends the body
635 of the cell in a new RELAY_INTRODUCE2 cell down the corresponding circuit.
636 (If the PK_ID is unrecognized, the RELAY_INTRODUCE1 cell is discarded.)
638 After sending the RELAY_INTRODUCE2 cell, the OR replies to Alice with an
639 empty RELAY_COMMAND_INTRODUCE_ACK cell. If no RELAY_INTRODUCE2 cell can
640 be sent, the OR replies to Alice with a non-empty cell to indicate an
641 error. (The semantics of the cell body may be determined later; the
642 current implementation sends a single '1' byte on failure.)
644 When Bob's OP receives the RELAY_INTRODUCE2 cell, it decrypts it with
645 the private key for the corresponding hidden service, and extracts the
646 rendezvous point's nickname, the rendezvous cookie, and the value of g^x
647 chosen by Alice.
649 1.10. Rendezvous
651 Bob's OP builds a new Tor circuit ending at Alice's chosen rendezvous
652 point, and sends a RELAY_RENDEZVOUS1 cell along this circuit, containing:
653 RC Rendezvous cookie [20 octets]
654 g^y Diffie-Hellman [128 octets]
655 KH Handshake digest [20 octets]
657 (Bob's OP MUST NOT use this circuit for any other purpose.)
659 If the RP recognizes RC, it relays the rest of the cell down the
660 corresponding circuit in a RELAY_RENDEZVOUS2 cell, containing:
662 g^y Diffie-Hellman [128 octets]
663 KH Handshake digest [20 octets]
665 (If the RP does not recognize the RC, it discards the cell and
666 tears down the circuit.)
668 When Alice's OP receives a RELAY_RENDEZVOUS2 cell on a circuit which
669 has sent a RELAY_ESTABLISH_RENDEZVOUS cell but which has not yet received
670 a reply, it uses g^y and H(g^xy) to complete the handshake as in the Tor
671 circuit extend process: they establish a 60-octet string as
672 K = SHA1(g^xy | [00]) | SHA1(g^xy | [01]) | SHA1(g^xy | [02])
673 and generate
674 KH = K[0..15]
675 Kf = K[16..31]
676 Kb = K[32..47]
678 Subsequently, the rendezvous point passes relay cells, unchanged, from
679 each of the two circuits to the other. When Alice's OP sends
680 RELAY cells along the circuit, it first encrypts them with the
681 Kf, then with all of the keys for the ORs in Alice's side of the circuit;
682 and when Alice's OP receives RELAY cells from the circuit, it decrypts
683 them with the keys for the ORs in Alice's side of the circuit, then
684 decrypts them with Kb. Bob's OP does the same, with Kf and Kb
685 interchanged.
687 1.11. Creating streams
689 To open TCP connections to Bob's location-hidden service, Alice's OP sends
690 a RELAY_BEGIN cell along the established circuit, using the special
691 address "", and a chosen port. Bob's OP chooses a destination IP and
692 port, based on the configuration of the service connected to the circuit,
693 and opens a TCP stream. From then on, Bob's OP treats the stream as an
694 ordinary exit connection.
695 [ Except he doesn't include addr in the connected cell or the end
696 cell. -RD]
698 Alice MAY send multiple RELAY_BEGIN cells along the circuit, to open
699 multiple streams to Bob. Alice SHOULD NOT send RELAY_BEGIN cells for any
700 other address along her circuit to Bob; if she does, Bob MUST reject them.
702 2. Authentication and authorization.
704 Foo.
706 3. Hidden service directory operation
708 This section has been introduced with the v2 hidden service descriptor
709 format. It describes all operations of the v2 hidden service descriptor
710 fetching and propagation mechanism that are required for the protocol
711 described in section 1 to succeed with v2 hidden service descriptors.
713 3.1. Configuring as hidden service directory
715 Every onion router that has its directory port open can decide whether it
716 wants to store and serve hidden service descriptors. An onion router which
717 is configured as such includes the "hidden-service-dir" flag in its router
718 descriptors that it sends to directory authorities.
720 The directory authorities include a new flag "HSDir" for routers that
721 decided to provide storage for hidden service descriptors and that
722 have been running for at least 24 hours.
724 3.2. Accepting publish requests
726 Hidden service directory nodes accept publish requests for v2 hidden service
727 descriptors and store them to their local memory. (It is not necessary to
728 make descriptors persistent, because after restarting, the onion router
729 would not be accepted as a storing node anyway, because it has not been
730 running for at least 24 hours.) All requests and replies are formatted as
731 HTTP messages. Requests are initiated via BEGIN_DIR cells directed to
732 the router's directory port, and formatted as HTTP POST requests to the URL
733 "/tor/rendezvous2/publish" relative to the hidden service directory's root,
734 containing as its body a v2 service descriptor.
736 A hidden service directory node parses every received descriptor and only
737 stores it when it thinks that it is responsible for storing that descriptor
738 based on its own routing table. See section 1.4 for more information on how
739 to determine responsibility for a certain descriptor ID.
741 3.3. Processing fetch requests
743 Hidden service directory nodes process fetch requests for hidden service
744 descriptors by looking them up in their local memory. (They do not need to
745 determine if they are responsible for the passed ID, because it does no harm
746 if they deliver a descriptor for which they are not (any more) responsible.)
747 All requests and replies are formatted as HTTP messages. Requests are
748 initiated via BEGIN_DIR cells directed to the router's directory port,
749 and formatted as HTTP GET requests for the document "/tor/rendezvous2/<z>",
750 where z is replaced with the encoding of the descriptor ID.