July 2018 - tor-commits - lists.torproject.org

[tor/release-0.3.4] Merge branch 'maint-0.3.4' into release-0.3.4
by nickm＠torproject.org 20 Jul '18

20 Jul '18

commit a1402bac344905ba3cd9fddac58ac2af0940f930 Merge: 5ca3de212 977821e59 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Jul 20 10:42:29 2018 -0400 Merge branch 'maint-0.3.4' into release-0.3.4 changes/ticket26647 | 4 ++++ src/or/control.c | 4 ++++ 2 files changed, 8 insertions(+)

1 0

[tor/maint-0.3.2] Add controller support for listing ExtORPort and HTTPTunnelPorts
by nickm＠torproject.org 20 Jul '18

20 Jul '18

commit e3e6335a08036fc64924b55e68f236a12e3c9118 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jul 10 10:50:43 2018 -0400 Add controller support for listing ExtORPort and HTTPTunnelPorts Closes ticket 26647. --- changes/ticket26647 | 4 ++++ src/or/control.c | 5 ++++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/changes/ticket26647 b/changes/ticket26647 new file mode 100644 index 000000000..1c2e917c6 --- /dev/null +++ b/changes/ticket26647 @@ -0,0 +1,4 @@ + o Minor features (controller): + - The control port now exposes the list of HTTPTunnelPorts and + ExtOrPorts via GETINFO net/listeners/httptunnel and net/listeners/extor + respectively. Closes ticket 26647. diff --git a/src/or/control.c b/src/or/control.c index 202366aae..3609210b9 100644 --- a/src/or/control.c +++ b/src/or/control.c @@ -1848,6 +1848,8 @@ getinfo_helper_listeners(control_connection_t *control_conn, if (!strcmp(question, "net/listeners/or")) type = CONN_TYPE_OR_LISTENER; + else if (!strcmp(question, "net/listeners/extor")) + type = CONN_TYPE_EXT_OR_LISTENER; else if (!strcmp(question, "net/listeners/dir")) type = CONN_TYPE_DIR_LISTENER; else if (!strcmp(question, "net/listeners/socks")) @@ -1856,6 +1858,8 @@ getinfo_helper_listeners(control_connection_t *control_conn, type = CONN_TYPE_AP_TRANS_LISTENER; else if (!strcmp(question, "net/listeners/natd")) type = CONN_TYPE_AP_NATD_LISTENER; + else if (!strcmp(question, "net/listeners/httptunnel")) + type = CONN_TYPE_AP_HTTP_CONNECT_LISTENER; else if (!strcmp(question, "net/listeners/dns")) type = CONN_TYPE_AP_DNS_LISTENER; else if (!strcmp(question, "net/listeners/control")) @@ -7318,4 +7322,3 @@ control_testing_set_global_event_mask(uint64_t mask) global_event_mask = mask; } #endif /* defined(TOR_UNIT_TESTS) */ -

1 0

[tor/maint-0.3.2] Merge branch 'ticket26647_032' into maint-0.3.2
by nickm＠torproject.org 20 Jul '18

20 Jul '18

commit be3a962ca7c6fc5fd72dfd9bb1def24efa4cdf2a Merge: 209332e71 e3e6335a0 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Jul 20 10:42:23 2018 -0400 Merge branch 'ticket26647_032' into maint-0.3.2 changes/ticket26647 | 4 ++++ src/or/control.c | 5 ++++- 2 files changed, 8 insertions(+), 1 deletion(-)

1 0

[tor/maint-0.3.3] Add controller support for listing ExtORPort and HTTPTunnelPorts
by nickm＠torproject.org 20 Jul '18

20 Jul '18

commit e3e6335a08036fc64924b55e68f236a12e3c9118 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jul 10 10:50:43 2018 -0400 Add controller support for listing ExtORPort and HTTPTunnelPorts Closes ticket 26647. --- changes/ticket26647 | 4 ++++ src/or/control.c | 5 ++++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/changes/ticket26647 b/changes/ticket26647 new file mode 100644 index 000000000..1c2e917c6 --- /dev/null +++ b/changes/ticket26647 @@ -0,0 +1,4 @@ + o Minor features (controller): + - The control port now exposes the list of HTTPTunnelPorts and + ExtOrPorts via GETINFO net/listeners/httptunnel and net/listeners/extor + respectively. Closes ticket 26647. diff --git a/src/or/control.c b/src/or/control.c index 202366aae..3609210b9 100644 --- a/src/or/control.c +++ b/src/or/control.c @@ -1848,6 +1848,8 @@ getinfo_helper_listeners(control_connection_t *control_conn, if (!strcmp(question, "net/listeners/or")) type = CONN_TYPE_OR_LISTENER; + else if (!strcmp(question, "net/listeners/extor")) + type = CONN_TYPE_EXT_OR_LISTENER; else if (!strcmp(question, "net/listeners/dir")) type = CONN_TYPE_DIR_LISTENER; else if (!strcmp(question, "net/listeners/socks")) @@ -1856,6 +1858,8 @@ getinfo_helper_listeners(control_connection_t *control_conn, type = CONN_TYPE_AP_TRANS_LISTENER; else if (!strcmp(question, "net/listeners/natd")) type = CONN_TYPE_AP_NATD_LISTENER; + else if (!strcmp(question, "net/listeners/httptunnel")) + type = CONN_TYPE_AP_HTTP_CONNECT_LISTENER; else if (!strcmp(question, "net/listeners/dns")) type = CONN_TYPE_AP_DNS_LISTENER; else if (!strcmp(question, "net/listeners/control")) @@ -7318,4 +7322,3 @@ control_testing_set_global_event_mask(uint64_t mask) global_event_mask = mask; } #endif /* defined(TOR_UNIT_TESTS) */ -

1 0

[torspec/master] tor-spec: circIDs are no longer chosen based on nicknames
by nickm＠torproject.org 20 Jul '18

20 Jul '18

commit 03b884b63d21893718f07b1ca7f76a783226c77a Author: teor <teor(a)torproject.org> Date: Thu Jul 19 13:34:12 2018 +1000 tor-spec: circIDs are no longer chosen based on nicknames And perhaps they never were? --- tor-spec.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tor-spec.txt b/tor-spec.txt index 09d17a3..089b733 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1267,7 +1267,7 @@ see tor-design.pdf. cell, the circuit will fail and be torn down. 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 based on lexicographic order of nicknames.) + circIDs.) When an onion router receives a CREATE/CREATE2 cell, if it already has a circuit on the given connection with the given circID, it drops the

1 0

[torspec/master] tor-spec: Specify how EXTEND2 cells are turned into CREATE2 cells
by nickm＠torproject.org 20 Jul '18

20 Jul '18

commit 3347808b4fe15e290a9b2c4941ee52738c849992 Author: teor <teor(a)torproject.org> Date: Thu Jul 19 13:32:01 2018 +1000 tor-spec: Specify how EXTEND2 cells are turned into CREATE2 cells Also generalised the EXTENDED to CREATED section so it covers EXTENDED2 to CREATED2. Closes 26859. --- tor-spec.txt | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/tor-spec.txt b/tor-spec.txt index 364505f..d706025 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -992,13 +992,17 @@ see tor-design.pdf. different RSA identity, it SHOULD NOT attempt to make another connection: it should just fail and DESTROY the circuit. + After checking relay identities, extending ORs generate a + CREATE/CREATE2 cell from the contents of the EXTEND/EXTEND2 cell. + See section 5.3 for details. + The payload of an EXTENDED cell is the same as the payload of a CREATED cell. The payload of an EXTENDED2 cell is the same as the payload of a CREATED2 cell. - [Support for EXTEND2 was added in Tor 0.2.4.8-alpha.] + [Support for EXTEND2/EXTENDED2 was added in Tor 0.2.4.8-alpha.] Clients SHOULD use the EXTEND format whenever sending a TAP handshake, and MUST use it whenever the EXTEND cell will be handled @@ -1252,20 +1256,28 @@ see tor-design.pdf. 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 - payload. As special cases, if the extend cell includes a digest of + payload. + + 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. + + As special cases, if the extend cell includes a digest of all zeroes, or asks to extend back to the relay that sent the extend cell, the circuit will fail and be torn down. 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 based on lexicographic order of nicknames.) - When an onion router receives a CREATE cell, if it already has a + When an onion router receives a CREATE/CREATE2 cell, if it already has a circuit on the given connection with the given circID, it drops the - cell. Otherwise, after receiving the CREATE cell, it completes the - DH handshake, and replies with a CREATED cell. Upon receiving a - CREATED cell, an onion router packs it payload into an EXTENDED relay - cell (see section 5), and sends that cell up the circuit. Upon - receiving the EXTENDED relay cell, the OP can retrieve g^y. + cell. Otherwise, after receiving the CREATE/CREATE2 cell, it completes + the specified handshake, and replies with a CREATED/CREATED2 cell. + + Upon receiving a CREATED/CREATED2 cell, an onion router packs it payload + into an EXTENDED/EXTENDED2 relay cell (see section 5.1.2), and sends + that cell up the circuit. Upon receiving the EXTENDED/EXTENDED2 relay + cell, the OP can retrieve the handshake material. (As an optimization, OR implementations may delay processing onions until a break in traffic allows time to do so without harming

1 0

[torspec/master] tor-spec: Rewrite the Routing Relay Cells section
by nickm＠torproject.org 20 Jul '18

20 Jul '18

commit 81a066672d25c2413f0aca1ec735b63c1c98cb11 Author: teor <teor(a)torproject.org> Date: Thu Jul 19 13:29:30 2018 +1000 tor-spec: Rewrite the Routing Relay Cells section The section now consists of: * forward encryption at the client * forward decryption at ORs * backward encryption at the end (exit) * backward decryption at the client Part of 26860. --- tor-spec.txt | 64 +++++++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 48 insertions(+), 16 deletions(-) diff --git a/tor-spec.txt b/tor-spec.txt index db32093..364505f 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1353,18 +1353,35 @@ see tor-design.pdf. 5.5. Routing relay cells - When an OR receives a RELAY or RELAY_EARLY cell, it checks the cell's - circID and determines whether it has a corresponding circuit along that - connection. If not, the OR drops the cell. +5.5.1. Circuit ID Checks - Otherwise, if the OR is not at the OP edge of the circuit (that is, - either an 'exit node' or a non-edge node), it de/encrypts the payload + When a node wants to send a RELAY or RELAY_EARLY cell, it checks the cell's + circID and determines whether the corresponding circuit along that + connection is still open. If not, the node drops the cell. + + When a node receives a RELAY or RELAY_EARLY cell, it checks the cell's + circID and determines whether it has a corresponding circuit along + that connection. If not, the node drops the cell. + +5.5.2. Forward Direction + + The forward direction is the direction that CREATE cells are sent. + +5.5.2.1. Routing from the Origin + + When a relay cell is sent from an OP, the OP encrypts the payload + with the stream cipher as follows: + OP sends relay cell: + For I=N...1, where N is the destination node: + Encrypt with Kf_I. + Transmit the encrypted cell to node 1. + +5.5.2.2. Relaying Forward at Onion Routers + + When a forward relay cell is received by an OR, it decrypts the payload with the stream cipher, as follows: - 'Forward' relay cell (same direction as CREATE): - Use Kf as key; decrypt. - 'Back' relay cell (opposite direction from CREATE): - Use Kb as key; encrypt. - Note that in counter mode, decrypt and encrypt are the same operation. + 'Forward' relay cell: + Use Kf as key; decrypt. The OR then decides whether it recognizes the relay cell, by inspecting the payload as described in section 6.1 below. If the OR @@ -1374,14 +1391,29 @@ see tor-design.pdf. encounters an unrecognized relay cell, an error has occurred: the OR sends a DESTROY cell to tear down the circuit. + For more information, see section 6 below. + +5.5.3. Backward Direction + + The backward direction is the opposite direction from CREATE cells. + +5.5.3.1. Relaying Backward at Onion Routers + + When a backward relay cell is received by an OR, it encrypts the payload + with the stream cipher, as follows: + 'Backward' relay cell: + Use Kb as key; encrypt. + +5.5.3. Routing to the Origin + When a relay cell arrives at an OP, the OP decrypts the payload with the stream cipher as follows: - OP receives data cell: - For I=1...N, - Decrypt with Kb_I. If the payload is recognized (see - section 6..1), then stop and process the payload. - - For more information, see section 6 below. + OP receives relay cell from node 1: + For I=1...N, where N is the final node on the circuit: + Decrypt with Kb_I. + If the payload is recognized (see section 6.1), then: + The sending node is I. + Stop and process the payload. 5.6. Handling relay_early cells

1 0

[torspec/master] tor-spec: fix some section numbers
by nickm＠torproject.org 20 Jul '18

20 Jul '18

commit b19196bfb069985b82fbccf1557cbcba94f4f7e9 Author: teor <teor(a)torproject.org> Date: Thu Jul 19 13:33:49 2018 +1000 tor-spec: fix some section numbers --- tor-spec.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tor-spec.txt b/tor-spec.txt index d706025..09d17a3 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -889,7 +889,7 @@ see tor-design.pdf. The first format is equivalent to a CREATE2 cell with HTYPE of 'tap' and length of TAP_C_HANDSHAKE_LEN. The second format is a way to encapsulate new handshake types into the old CREATE cell format for - migration. See 5.1.2.1 below. Recognized HTAG values are: + migration. See 5.1.2 below. Recognized HTAG values are: ntor -- 'ntorNTORntorNTOR' @@ -1249,7 +1249,7 @@ see tor-design.pdf. 1. Create an onion skin, encrypted to R_M's public onion key. 2. Send the onion skin in a relay EXTEND cell along - the circuit (see section 5). + the circuit (see sections 5.1.2 and 5.5). 3. When a relay EXTENDED cell is received, verify KH, and calculate the shared keys. The circuit is now extended.

1 0

[torspec/master] Update spec to match correct decryption order
by nickm＠torproject.org 20 Jul '18

20 Jul '18

commit c551c2dc07785cc96468a079b1b9a77ddb1e17b0 Author: Dave Rolek <dmr-x(a)riseup.net> Date: Fri Jul 6 15:32:20 2018 +0000 Update spec to match correct decryption order Fixes #26860. --- tor-spec.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tor-spec.txt b/tor-spec.txt index ea195ad..db32093 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1377,7 +1377,7 @@ see tor-design.pdf. When a relay cell arrives at an OP, the OP decrypts the payload with the stream cipher as follows: OP receives data cell: - For I=N...1, + For I=1...N, Decrypt with Kb_I. If the payload is recognized (see section 6..1), then stop and process the payload.

1 0

[torspec/master] Merge branch '26860-decryption-order-squashed'
by nickm＠torproject.org 20 Jul '18

20 Jul '18

commit 7ced6190ea1df2ae8f26ef5842a5ef4fb7e7e627 Merge: ce1d4a8 03b884b Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Jul 20 10:39:39 2018 -0400 Merge branch '26860-decryption-order-squashed' tor-spec.txt | 98 +++++++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 71 insertions(+), 27 deletions(-)

1 0