From 220ea886ec38f7c0ff4b56a1d97421ed182b87a3 Mon Sep 17 00:00:00 2001 From: teor Date: Thu, 26 Jul 2018 09:53:39 +1000 Subject: tor-spec: Generalise the first-hop ban to rend points and exit streams Part of 26885. --- tor-spec.txt | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) (limited to 'tor-spec.txt') diff --git a/tor-spec.txt b/tor-spec.txt index ef0e12e..441ccee 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1154,15 +1154,12 @@ see tor-design.pdf. Once both parties have X and Y, they derive their shared circuit keys and 'derivative key data' value via the KDF-TOR function in 5.2.1. - If an OR sees a circuit created with CREATE_FAST, the OR is sure to be the - first hop of a circuit. ORs SHOULD reject attempts to create streams with - RELAY_BEGIN exiting the circuit at the first hop: letting Tor be used as a - single hop proxy makes exit nodes a more attractive target for compromise. - The CREATE_FAST handshake is currently deprecated whenever it is not necessary; the migration is controlled by the "usecreatefast" networkstatus parameter as described in dir-spec.txt. + [Tor 0.3.1.1-alpha and later disable CREATE_FAST by default.] + 5.2. Setting circuit keys 5.2.1. KDF-TOR @@ -1305,8 +1302,24 @@ see tor-design.pdf. Circuits are torn down when an unrecoverable error occurs along the circuit, or when all streams on a circuit are closed and the - circuit's intended lifetime is over. Circuits may be torn down - either completely or hop-by-hop. + circuit's intended lifetime is over. + + ORs SHOULD also tear down circuits which attempt to create: + * streams with RELAY_BEGIN, or + * rendezvous points with ESTABLISH_RENDEZVOUS, + ending at the first hop. Letting Tor be used as a single hop proxy makes + exit and rendezvous nodes a more attractive target for compromise. + + ORs MAY use multiple methods to check if they are the first hop: + * If an OR sees a circuit created with CREATE_FAST, the OR is sure to be + the first hop of a circuit. + * If an OR is the responder, and the initiator: + * did not authenticate the link, or + * authenticated with a key that is not in the consensus, + then the OR is probably the first hop of a circuit (or the second hop of + a circuit via a bridge relay). + + Circuits may be torn down either completely or hop-by-hop. To tear down a circuit completely, an OR or OP sends a DESTROY cell to the adjacent nodes on that circuit, using the appropriate -- cgit v1.2.3-54-g00ecf From 42eb1fdc55d7f9ccee872de78cb6a4a4fa603904 Mon Sep 17 00:00:00 2001 From: teor Date: Thu, 26 Jul 2018 09:52:17 +1000 Subject: tor-spec: Generalise "exit" to "end" where appropriate Closes #26885. --- tor-spec.txt | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) (limited to 'tor-spec.txt') diff --git a/tor-spec.txt b/tor-spec.txt index 441ccee..4722da5 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1219,13 +1219,15 @@ see tor-design.pdf. When creating a circuit through the network, the circuit creator (OP) performs the following steps: - 1. Choose an onion router as an exit node (R_N), such that the onion - router's exit policy includes at least one pending stream that - needs a circuit (if there are any). + 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). - 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. @@ -1463,11 +1465,16 @@ see tor-design.pdf. 6.1. Relay cells - Within a circuit, the OP and the exit node use the contents of + Within a circuit, the OP and the end node use the contents of RELAY packets to tunnel end-to-end commands and TCP connections ("Streams") across circuits. End-to-end commands can be initiated by either edge; streams are initiated by the OP. + End nodes that accept streams may be: + * exit relays (RELAY_BEGIN, anonymous), + * directory servers (RELAY_BEGIN_DIR, anonymous or non-anonymous), + * onion services (RELAY_BEGIN, anonymous via a rendezvous point). + The payload of each unencrypted RELAY cell consists of: Relay command [1 byte] 'Recognized' [2 bytes] @@ -1493,7 +1500,7 @@ see tor-design.pdf. 14 -- RELAY_EXTEND2 [forward] [control] 15 -- RELAY_EXTENDED2 [backward] [control] - 32..40 -- Used for hidden services; see rend-spec.txt. + 32..40 -- Used for hidden services; see rend-spec-{v2,v3}.txt. Commands labelled as "forward" must only be sent by the originator of the circuit. Commands labelled as "backward" must only be sent by @@ -1626,6 +1633,12 @@ see tor-design.pdf. connection to its directory port. RELAY_BEGIN_DIR cells ignore exit policy, since the stream is local to the Tor process. + Directory servers may be: + * authoritative directories (RELAY_BEGIN_DIR, usually non-anonymous), + * bridge authoritative directories (RELAY_BEGIN_DIR, anonymous), + * directory mirrors (RELAY_BEGIN_DIR, usually non-anonymous), + * onion service directories (RELAY_BEGIN_DIR, anonymous). + If the Tor relay is not running a directory service, it should respond with a REASON_NOTDIRECTORY RELAY_END cell. @@ -1690,9 +1703,9 @@ see tor-design.pdf. Because TCP connections can be half-open, we follow an equivalent to TCP's FIN/FIN-ACK/ACK protocol to close streams. - An exit connection can have a TCP stream in one of three states: - 'OPEN', 'DONE_PACKAGING', and 'DONE_DELIVERING'. For the purposes - of modeling transitions, we treat 'CLOSED' as a fourth state, + An exit (or onion service) connection can have a TCP stream in one of + three states: 'OPEN', 'DONE_PACKAGING', and 'DONE_DELIVERING'. For the + purposes of modeling transitions, we treat 'CLOSED' as a fourth state, although connections in this state are not, in fact, tracked by the onion router. -- cgit v1.2.3-54-g00ecf