diff options
Diffstat (limited to 'spec/rend-spec/rendezvous-protocol.md')
| -rw-r--r-- | spec/rend-spec/rendezvous-protocol.md | 32 |
1 files changed, 16 insertions, 16 deletions
diff --git a/spec/rend-spec/rendezvous-protocol.md b/spec/rend-spec/rendezvous-protocol.md index fbd79a1..2b14934 100644 --- a/spec/rend-spec/rendezvous-protocol.md +++ b/spec/rend-spec/rendezvous-protocol.md @@ -4,10 +4,10 @@ Before connecting to a hidden service, the client first builds a circuit to an arbitrarily chosen Tor node (known as the rendezvous -point), and sends an ESTABLISH_RENDEZVOUS cell. The hidden service -later connects to the same node and sends a RENDEZVOUS cell. Once +point), and sends an ESTABLISH_RENDEZVOUS message. The hidden service +later connects to the same node and sends a RENDEZVOUS message. Once this has occurred, the relay forwards the contents of the RENDEZVOUS -cell to the client, and joins the two circuits together. +message to the client, and joins the two circuits together. Single Onion Services attempt to build a non-anonymous single-hop circuit, but use an anonymous 3-hop circuit if: @@ -24,12 +24,12 @@ but use an anonymous 3-hop circuit if: ## Establishing a rendezvous point {#EST_REND_POINT} The client sends the rendezvous point a RELAY_COMMAND_ESTABLISH_RENDEZVOUS -cell containing a 20-byte value. +message containing a 20-byte value. RENDEZVOUS_COOKIE \[20 bytes\] Rendezvous points MUST ignore any extra bytes in an -ESTABLISH_RENDEZVOUS cell. (Older versions of Tor did not.) +ESTABLISH_RENDEZVOUS message. (Older versions of Tor did not.) The rendezvous cookie is an arbitrary 20-byte value, chosen randomly by the client. The client SHOULD choose a new rendezvous cookie for @@ -37,12 +37,12 @@ each new connection attempt. If the rendezvous cookie is already in use on an existing circuit, the rendezvous point should reject it and destroy the circuit. -Upon receiving an ESTABLISH_RENDEZVOUS cell, the rendezvous point associates +Upon receiving an ESTABLISH_RENDEZVOUS message, the rendezvous point associates the cookie with the circuit on which it was sent. It replies to the client -with an empty RENDEZVOUS_ESTABLISHED cell to indicate success. Clients MUST -ignore any extra bytes in a RENDEZVOUS_ESTABLISHED cell. +with an empty RENDEZVOUS_ESTABLISHED message to indicate success. Clients MUST +ignore any extra bytes in a RENDEZVOUS_ESTABLISHED message. -The client MUST NOT use the circuit which sent the cell for any +The client MUST NOT use the circuit which sent the message for any purpose other than rendezvous with the given location-hidden service. The client should establish a rendezvous point BEFORE trying to @@ -53,7 +53,7 @@ connect to a hidden service. ## Joining to a rendezvous point {#JOIN_REND} To complete a rendezvous, the hidden service host builds a circuit to -the rendezvous point and sends a RENDEZVOUS1 cell containing: +the rendezvous point and sends a RENDEZVOUS1 message containing: ```text RENDEZVOUS_COOKIE [20 bytes] @@ -67,10 +67,10 @@ introduction (see \[PROCESS_INTRO2\]) and HANDSHAKE_INFO is defined in If the cookie matches the rendezvous cookie set on any not-yet-connected circuit on the rendezvous point, the rendezvous -point connects the two circuits, and sends a RENDEZVOUS2 cell to the -client containing the HANDSHAKE_INFO field of the RENDEZVOUS1 cell. +point connects the two circuits, and sends a RENDEZVOUS2 message to the +client containing the HANDSHAKE_INFO field of the RENDEZVOUS1 message. -Upon receiving the RENDEZVOUS2 cell, the client verifies that HANDSHAKE_INFO +Upon receiving the RENDEZVOUS2 message, the client verifies that HANDSHAKE_INFO correctly completes a handshake. To do so, the client parses SERVER_PK from HANDSHAKE_INFO and reverses the final operations of section \[NTOR-WITH-EXTRA-DATA\] as shown here: @@ -103,7 +103,7 @@ The first HASH_LEN bytes of K form the forward digest Df; the next HASH_LEN bytes form the backward digest Db; the next S_KEY_LEN bytes form Kf, and the final S_KEY_LEN bytes form Kb. Excess bytes from K are discarded. -Subsequently, the rendezvous point passes relay cells, unchanged, from each +Subsequently, the rendezvous point passes RELAY cells, unchanged, from each of the two circuits to the other. When Alice's OP sends RELAY cells along the circuit, it authenticates with Df, and encrypts them with the Kf, then with all of the keys for the ORs in Alice's side of the circuit; and when @@ -127,12 +127,12 @@ The behavior of ESTABLISH_RENDEZVOUS is unchanged from older versions of this protocol, except that relays should now ignore unexpected bytes at the end. -Old versions of Tor required that RENDEZVOUS cell payloads be exactly +Old versions of Tor required that RENDEZVOUS message payloads be exactly 168 bytes long. All shorter rendezvous payloads should be padded to this length with random bytes, to make them difficult to distinguish from older protocols at the rendezvous point. Relays older than 0.2.9.1 should not be used for rendezvous points by next generation onion services because they enforce too-strict length checks to -rendezvous cells. Hence the "HSRend" protocol from proposal#264 should be +RENDEZVOUS messages. Hence the "HSRend" protocol from proposal#264 should be used to select relays for rendezvous points. |