diff options
| -rw-r--r-- | spec/tor-spec/closing-streams.md | 2 | ||||
| -rw-r--r-- | spec/tor-spec/creating-circuits.md | 66 | ||||
| -rw-r--r-- | spec/tor-spec/opening-streams.md | 6 | ||||
| -rw-r--r-- | spec/tor-spec/preliminaries.md | 4 |
4 files changed, 38 insertions, 40 deletions
diff --git a/spec/tor-spec/closing-streams.md b/spec/tor-spec/closing-streams.md index 7182f48..265e9d1 100644 --- a/spec/tor-spec/closing-streams.md +++ b/spec/tor-spec/closing-streams.md @@ -1,6 +1,6 @@ <a id="tor-spec.txt-6.3"></a> -# Closing streams +# Closing streams{#closing-streams} When an anonymized TCP connection is closed, or an edge node encounters error on any stream, it sends a 'RELAY_END' cell along the diff --git a/spec/tor-spec/creating-circuits.md b/spec/tor-spec/creating-circuits.md index f2a1c7d..eb8de36 100644 --- a/spec/tor-spec/creating-circuits.md +++ b/spec/tor-spec/creating-circuits.md @@ -5,44 +5,42 @@ When creating a circuit through the network, the circuit creator (OP) performs the following steps: -```text - 1. Choose an onion router as an end node (R_N): - * N MAY be 1 for non-anonymous directory mirror, introduction point, - or service rendezvous connections. - * N SHOULD be 3 or more for anonymous connections. - Some end nodes accept streams (see 6.1), others are introduction - or rendezvous points (see rend-spec-{v2,v3}.txt). +1. Choose an onion router as an end node (R_N): + * N MAY be 1 for non-anonymous directory mirror, introduction point, + or service rendezvous connections. + * N SHOULD be 3 or more for anonymous connections. + Some end nodes accept streams (see ["Relay Cells"](./relay-cells.md#relay-cells)), + others are introduction or rendezvous points (see the [Rendezvous Spec](../rend-spec/index.md)). - 2. Choose a chain of (N-1) onion routers (R_1...R_N-1) to constitute - the path, such that no router appears in the path twice. +2. Choose a chain of (N-1) onion routers (R_1...R_N-1) to constitute + the path, such that no router appears in the path twice. - 3. If not already connected to the first router in the chain, - open a new connection to that router. +3. If not already connected to the first router in the chain, + open a new connection to that router. - 4. Choose a circID not already in use on the connection with the - first router in the chain; send a CREATE/CREATE2 cell along - the connection, to be received by the first onion router. +4. Choose a circID not already in use on the connection with the + first router in the chain; send a CREATE/CREATE2 cell along + the connection, to be received by the first onion router. - 5. Wait until a CREATED/CREATED2 cell is received; finish the - handshake and extract the forward key Kf_1 and the backward - key Kb_1. +5. Wait until a CREATED/CREATED2 cell is received; finish the + handshake and extract the forward key Kf_1 and the backward + key Kb_1. - 6. For each subsequent onion router R (R_2 through R_N), extend - the circuit to R. -``` +6. For each subsequent onion router R (R_2 through R_N), extend + the circuit to R. To extend the circuit by a single onion router R_M, the OP performs these steps: 1. Create an onion skin, encrypted to R_M's public onion key. -```text - 2. Send the onion skin in a relay EXTEND/EXTEND2 cell along - the circuit (see sections 5.1.2 and 5.5). +2. Send the onion skin in a relay EXTEND/EXTEND2 cell along + the circuit (see + ["EXTEND and EXTENDED cells"](./create-created-cells.md#EXTEND) + and ["Routing relay cells"](./routing-relay-cells.md#routing-relay-cells)). - 3. When a relay EXTENDED/EXTENDED2 cell is received, verify KH, - and calculate the shared keys. The circuit is now extended. -``` +3. When a relay EXTENDED/EXTENDED2 cell is received, verify KH, + and calculate the shared keys. The circuit is now extended. When an onion router receives an EXTEND relay cell, it sends a CREATE cell to the next onion router, with the enclosed onion skin as its @@ -52,7 +50,7 @@ When an onion router receives an EXTEND2 relay cell, it sends a CREATE2 cell to the next onion router, with the enclosed HLEN, HTYPE, and HDATA as its payload. The initiating onion router chooses some circID not yet used on the connection between the two onion routers. (But see section -5.1.1 above, concerning choosing circIDs.) +["Choosing circuit IDs in create cells"](./create-created-cells.md#choosing-circid)) As special cases, if the EXTEND/EXTEND2 cell includes a legacy identity, or identity fingerprint of all zeroes, or asks to extend back to the relay @@ -95,12 +93,10 @@ To prevent this, when an OR gets an extend request, it SHOULD use an existing OR connection if the ID matches, and ANY of the following conditions hold: -```text - - The IP matches the requested IP. - - The OR knows that the IP of the connection it's using is canonical - because it was listed in the NETINFO cell. + - The IP matches the requested IP. + - The OR knows that the IP of the connection it's using is canonical + because it was listed in the NETINFO cell. - ORs SHOULD NOT check the IPs that are listed in the server descriptor. - Trusting server IPs makes it easier to covertly impersonate a relay, after - stealing its keys. -``` +ORs SHOULD NOT check the IPs that are listed in the server descriptor. +Trusting server IPs makes it easier to covertly impersonate a relay, after +stealing its keys. diff --git a/spec/tor-spec/opening-streams.md b/spec/tor-spec/opening-streams.md index c3a0aa6..d59e26b 100644 --- a/spec/tor-spec/opening-streams.md +++ b/spec/tor-spec/opening-streams.md @@ -26,7 +26,8 @@ fingerprinting. Implementations MUST accept strings in any case. The FLAGS value has one or more of the following bits set, where "bit 1" is the LSB of the 32-bit value, and "bit 32" is the MSB. -(Remember that all values in Tor are big-endian (see 0.1.1 above), so +(Remember that all values in Tor are big-endian (see +["Preliminaries ยป Encoding integers"](./preliminaries.md#encoding)), so the MSB of a 4-byte value is the MSB of the first byte, and the LSB of a 4-byte value is the LSB of its last byte.) @@ -49,7 +50,8 @@ FLAGS, FLAGS is omitted from the message payload. Upon receiving this cell, the exit node resolves the address as necessary, and opens a new TCP connection to the target port. If the address cannot be resolved, or a connection can't be established, the -exit node replies with a RELAY_END cell. (See 6.3 below.) +exit node replies with a RELAY_END cell. (See +["Closing streams"](./closing-streams.md#closing-streams).) Otherwise, the exit node replies with a RELAY_CONNECTED cell, whose payload is in one of the following formats: diff --git a/spec/tor-spec/preliminaries.md b/spec/tor-spec/preliminaries.md index d911a5e..36468d8 100644 --- a/spec/tor-spec/preliminaries.md +++ b/spec/tor-spec/preliminaries.md @@ -11,7 +11,7 @@ <a id="tor-spec.txt-0.1"></a> -## Notation and encoding +## Notation and encoding{#notation-and-encoding} ```text KP -- a public key for an asymmetric cipher. @@ -34,7 +34,7 @@ Some specs mention "base32". This means RFC4648, without "=" padding. <a id="tor-spec.txt-0.1.1"></a> -### Encoding integers +### Encoding integers{#encoding} Unless we explicitly say otherwise below, all numeric values in the Tor protocol are encoded in network (big-endian) order. So a "32-bit |