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

[tor/master] Check that the header is key_value
by nickm＠torproject.org 30 Jul '18

30 Jul '18

commit f0a4a5f726cf1939461cbf9a4b73060770bbc3e7 Author: juga0 <juga(a)riseup.net> Date: Thu May 31 09:03:39 2018 +0000 Check that the header is key_value to avoid interpreting as headers extra lines that are not key_values --- src/feature/dircache/dirserv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/feature/dircache/dirserv.c b/src/feature/dircache/dirserv.c index ea7b29c46..e7b5239e0 100644 --- a/src/feature/dircache/dirserv.c +++ b/src/feature/dircache/dirserv.c @@ -2674,7 +2674,10 @@ dirserv_read_measured_bandwidths(const char *from_file, if (measured_bw_line_apply(&parsed_line, routerstatuses) > 0) applied_lines++; } else { - if (strcmp(line, "====\n") != 0) { + /* If line does not contain the header separator and it is key_value, + * it is probably a KeyValue header.*/ + if (strcmp(line, "====\n") != 0 && + string_is_key_value(LOG_DEBUG, line)) { line[strlen(line)-1] = '\0'; smartlist_add_strdup(bwlist_headers, line); };

1 0

[tor/master] Rename bwlist to bw_file and banwidth to
by nickm＠torproject.org 30 Jul '18

30 Jul '18

commit d79c65772bd88b7b2810750237057fafbe8ea076 Author: juga0 <juga(a)riseup.net> Date: Fri Jun 29 20:43:51 2018 +0000 Rename bwlist to bw_file and banwidth to bandwidth-file --- src/feature/dirauth/dirvote.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/src/feature/dirauth/dirvote.c b/src/feature/dirauth/dirvote.c index a1bafb4fd..b123f73a4 100644 --- a/src/feature/dirauth/dirvote.c +++ b/src/feature/dirauth/dirvote.c @@ -254,7 +254,7 @@ format_networkstatus_vote(crypto_pk_t *private_signing_key, /* XXXX Abstraction violation: should be pulling a field out of v3_ns.*/ char *flag_thresholds = dirserv_get_flag_thresholds_line(); char *params; - char *bwlist_headers; + char *bw_file_headers; authority_cert_t *cert = v3_ns->cert; char *methods = make_consensus_method_list(MIN_SUPPORTED_CONSENSUS_METHOD, @@ -269,11 +269,11 @@ format_networkstatus_vote(crypto_pk_t *private_signing_key, else params = tor_strdup(""); tor_assert(cert); - if (v3_ns->bwlist_headers) - bwlist_headers = smartlist_join_strings(v3_ns->bwlist_headers, " ", 0, + if (v3_ns->bw_file_headers) + bw_file_headers = smartlist_join_strings(v3_ns->bw_file_headers, " ", 0, NULL); else - bwlist_headers = tor_strdup(""); + bw_file_headers = tor_strdup(""); smartlist_add_asprintf(chunks, "network-status-version 3\n" "vote-status %s\n" @@ -292,7 +292,7 @@ format_networkstatus_vote(crypto_pk_t *private_signing_key, "dir-source %s %s %s %s %d %d\n" "contact %s\n" "%s" /* shared randomness information */ - "bandwidth-file %s\n", /* bandwidth file headers */ + "bandwidth-file-headers %s\n", /* bandwidth file headers */ v3_ns->type == NS_TYPE_VOTE ? "vote" : "opinion", methods, published, va, fu, vu, @@ -309,14 +309,14 @@ format_networkstatus_vote(crypto_pk_t *private_signing_key, voter->contact, shared_random_vote_str ? shared_random_vote_str : "", - bwlist_headers); + bw_file_headers); tor_free(params); tor_free(flags); tor_free(flag_thresholds); tor_free(methods); tor_free(shared_random_vote_str); - tor_free(bwlist_headers); + tor_free(bw_file_headers); if (!tor_digest_is_zero(voter->legacy_id_digest)) { char fpbuf[HEX_DIGEST_LEN+1]; @@ -4299,7 +4299,7 @@ dirserv_generate_networkstatus_vote_obj(crypto_pk_t *private_key, uint32_t addr; char *hostname = NULL, *client_versions = NULL, *server_versions = NULL; const char *contact; - smartlist_t *routers, *routerstatuses, *bwlist_headers; + smartlist_t *routers, *routerstatuses, *bw_file_headers; char identity_digest[DIGEST_LEN]; char signing_key_digest[DIGEST_LEN]; int listbadexits = options->AuthDirListBadExits; @@ -4383,7 +4383,7 @@ dirserv_generate_networkstatus_vote_obj(crypto_pk_t *private_key, routerstatuses = smartlist_new(); microdescriptors = smartlist_new(); - bwlist_headers = smartlist_new(); + bw_file_headers = smartlist_new(); SMARTLIST_FOREACH_BEGIN(routers, routerinfo_t *, ri) { /* If it has a protover list and contains a protocol name greater than @@ -4450,7 +4450,7 @@ dirserv_generate_networkstatus_vote_obj(crypto_pk_t *private_key, /* This pass through applies the measured bw lines to the routerstatuses */ if (options->V3BandwidthsFile) { dirserv_read_measured_bandwidths(options->V3BandwidthsFile, - routerstatuses, bwlist_headers); + routerstatuses, bw_file_headers); } else { /* * No bandwidths file; clear the measured bandwidth cache in case we had @@ -4546,7 +4546,7 @@ dirserv_generate_networkstatus_vote_obj(crypto_pk_t *private_key, options->ConsensusParams, NULL, 0, 0); smartlist_sort_strings(v3_out->net_params); } - v3_out->bwlist_headers = bwlist_headers; + v3_out->bw_file_headers = bw_file_headers; voter = tor_malloc_zero(sizeof(networkstatus_voter_info_t)); voter->nickname = tor_strdup(options->Nickname);

1 0

[tor/master] Free bw_list_headers in networstatus_t
by nickm＠torproject.org 30 Jul '18

30 Jul '18

commit 6d8bc12583939f7f4849b4a86599f896db85e2f8 Author: juga0 <juga(a)riseup.net> Date: Fri Jun 29 13:45:06 2018 +0000 Free bw_list_headers in networstatus_t --- src/feature/nodelist/networkstatus.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/feature/nodelist/networkstatus.c b/src/feature/nodelist/networkstatus.c index e9d36cbdc..252e01eb4 100644 --- a/src/feature/nodelist/networkstatus.c +++ b/src/feature/nodelist/networkstatus.c @@ -385,6 +385,11 @@ networkstatus_vote_free_(networkstatus_t *ns) smartlist_free(ns->routerstatus_list); } + if (ns->bw_file_headers) { + SMARTLIST_FOREACH(ns->bw_file_headers, char *, c, tor_free(c)); + smartlist_free(ns->bw_file_headers); + } + digestmap_free(ns->desc_digest_map, NULL); if (ns->sr_info.commits) {

1 0

[torspec/master] Add a missing "
by nickm＠torproject.org 30 Jul '18

30 Jul '18

commit 5491f3fc076aeb4c12e7e1dbeaf631d3d243815e Author: teor <teor(a)torproject.org> Date: Wed Jul 25 15:39:00 2018 +1000 Add a missing " --- rend-spec-v3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index eb1ba42..705dc0d 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -1402,7 +1402,7 @@ Table of contents: legacy protocol (v2) that is <= 0.2.9 or the protocol version value "HSIntro 3". - "legacy-key-cert NL certificate NL + "legacy-key-cert" NL certificate NL [None or at most once per introduction point]

1 0

[torspec/master] Merge remote-tracking branch 'teor/bug26925'
by nickm＠torproject.org 30 Jul '18

30 Jul '18

commit 54ef5f2158a00cdf545833ad670d19a1a1536dd7 Merge: 1f0d38a 5491f3f Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Jul 30 08:35:48 2018 -0400 Merge remote-tracking branch 'teor/bug26925' rend-spec-v3.txt | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-)

1 0

[torspec/master] rend-spec-v3: harmonise client and service link specifiers in EXTENDs
by nickm＠torproject.org 30 Jul '18

30 Jul '18

commit cd6058ed8ebf2ffef4944cab076f605c52e9049b Author: teor <teor(a)torproject.org> Date: Wed Jul 25 15:37:57 2018 +1000 rend-spec-v3: harmonise client and service link specifiers in EXTENDs Closes bug 26925. --- rend-spec-v3.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 0b56fce..eb1ba42 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -1343,6 +1343,15 @@ Table of contents: The link-specifiers is a base64 encoding of a link specifier block in the format described in BUILDING-BLOCKS. + The client SHOULD NOT reject any LSTYPE fields which it doesn't + recognize; instead, it should use them verbatim in its EXTEND + request to the introduction point. + + The client MAY perform basic validity checks on the link + specifiers in the descriptor. These checks SHOULD NOT leak + detailed information about the client's version, configuration, + or consensus. (See 3.3 for service link specifier handling.) + "onion-key" SP "ntor" SP key NL [Exactly once per introduction point] @@ -1702,9 +1711,10 @@ Table of contents: in [BUILDING-BLOCKS], the "TLS-over-TCP, IPv4" and "Legacy node identity" specifiers must be present. - The hidden service SHOULD NOT reject any LSTYPE fields which it - doesn't recognize; instead, it should use them verbatim in its EXTEND - request to the rendezvous point. + The hidden service should handle invalid or unrecognised link specifiers + the same way as clients do in section 2.5.2.2. In particular, services + MAY perform basic validity checks on link specifiers, and SHOULD NOT + reject unrecognised link specifiers, to avoid information leaks. The ONION_KEY_TYPE field is:

1 0

[tor/master] Merge remote-tracking branch 'rl1987/bug26892_take2'
by nickm＠torproject.org 30 Jul '18

30 Jul '18

commit 811ed8cf9f58d8480244483f4ad012ea9dca42ef Merge: 5823e62fa ffdfd39d4 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Jul 30 08:24:14 2018 -0400 Merge remote-tracking branch 'rl1987/bug26892_take2' changes/bug26892 | 6 ++++++ src/feature/relay/router.c | 3 +++ 2 files changed, 9 insertions(+)

1 0

[tor/master] Early bailout from log_addr_has_changed() if running as client
by nickm＠torproject.org 30 Jul '18

30 Jul '18

commit ffdfd39d4fc693795f1e3fd222b676fe053681be Author: rl1987 <rl1987(a)sdf.lonestar.org> Date: Thu Jul 26 17:49:27 2018 +0300 Early bailout from log_addr_has_changed() if running as client --- changes/bug26892 | 6 ++++++ src/feature/relay/router.c | 3 +++ 2 files changed, 9 insertions(+) diff --git a/changes/bug26892 b/changes/bug26892 new file mode 100644 index 000000000..6fc8a0320 --- /dev/null +++ b/changes/bug26892 @@ -0,0 +1,6 @@ + o Minor bugfixes (logging): + - As a precaution, do an early return from + log_addr_has_changed() if Tor is running as client. Also, + log a stack trace for debugging as this function should only + be called when Tor runs as server. Fixes bug 26892; + bugfix on 0.1.1.9-alpha. diff --git a/src/feature/relay/router.c b/src/feature/relay/router.c index 973d3e110..0cc488723 100644 --- a/src/feature/relay/router.c +++ b/src/feature/relay/router.c @@ -2686,6 +2686,9 @@ log_addr_has_changed(int severity, char addrbuf_prev[TOR_ADDR_BUF_LEN]; char addrbuf_cur[TOR_ADDR_BUF_LEN]; + if (BUG(!server_mode(get_options()))) + return; + if (tor_addr_to_str(addrbuf_prev, prev, sizeof(addrbuf_prev), 1) == NULL) strlcpy(addrbuf_prev, "???", TOR_ADDR_BUF_LEN); if (tor_addr_to_str(addrbuf_cur, cur, sizeof(addrbuf_cur), 1) == NULL)

1 0

[torspec/master] Say CREATE/CREATE2, etc. where needed
by nickm＠torproject.org 30 Jul '18

30 Jul '18

commit d5a0678ec727dfeb37127c9893903e9d6799e883 Author: Taylor Yu <catalyst(a)torproject.org> Date: Fri Jul 20 16:01:20 2018 -0500 Say CREATE/CREATE2, etc. where needed Not all of the text describing CREATE, CREATED, EXTEND, or EXTENDED cells was updated when the "2"-suffixed versions were added. Closes ticket 26894. --- tor-spec.txt | 79 ++++++++++++++++++++++++++++++++---------------------------- 1 file changed, 42 insertions(+), 37 deletions(-) diff --git a/tor-spec.txt b/tor-spec.txt index ef0e12e..b88befe 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -309,9 +309,10 @@ see tor-design.pdf. (When initiating a connection, if a reasonably live consensus is available, then the expected identity key is taken from that consensus. But when initiating a connection otherwise, the expected - identity key is the one given in the hard-coded authority or fallback - list. Finally, when creating a connection because of an EXTEND cell, the - expected identity key is the one given in the cell.) + identity key is the one given in the hard-coded authority or + fallback list. Finally, when creating a connection because of an + EXTEND/EXTEND2 cell, the expected identity key is the one given in + the cell.) When connecting to an OR, all parties SHOULD reject the connection if that OR has a malformed or missing certificate. When accepting an incoming @@ -468,8 +469,8 @@ see tor-design.pdf. The interpretation of 'Payload' depends on the type of the cell. PADDING: Payload is unused. - CREATE: Payload contains the handshake challenge. - CREATED: Payload contains the handshake response. + CREATE/CREATE2: Payload contains the handshake challenge. + CREATED/CREATED2: Payload contains the handshake response. RELAY: Payload contains the relay header and relay body. DESTROY: Payload contains a reason for closing the circuit. (see 5.4) @@ -483,8 +484,8 @@ see tor-design.pdf. If there is no other traffic, ORs and OPs send one another a PADDING cell every few minutes. - CREATE, CREATED, and DESTROY cells are used to manage circuits; - see section 5 below. + CREATE, CREATE2, CREATED, CREATED2, and DESTROY cells are used to + manage circuits; see section 5 below. RELAY cells are used to send commands and data along a circuit; see section 6 below. @@ -854,12 +855,12 @@ see tor-design.pdf. 5.1. CREATE and CREATED cells Users set up circuits incrementally, one hop at a time. To create a - new circuit, OPs send a CREATE cell to the first node, with the first - half of an authenticated handshake; that node responds with a CREATED - cell with the second half of the handshake. To extend a circuit past - the first hop, the OP sends an EXTEND relay cell (see section 5.1.2) - which instructs the last node in the circuit to send a CREATE cell to - extend the circuit. + new circuit, OPs send a CREATE/CREATE2 cell to the first node, with + the first half of an authenticated handshake; that node responds with + a CREATED/CREATED2 cell with the second half of the handshake. To + extend a circuit past the first hop, the OP sends an EXTEND/EXTEND2 + relay cell (see section 5.1.2) which instructs the last node in the + circuit to send a CREATE/CREATE2 cell to extend the circuit. There are two kinds of CREATE and CREATED cells: The older "CREATE/CREATED" format, and the newer "CREATE2/CREATED2" format. The @@ -912,21 +913,21 @@ see tor-design.pdf. 5.1.1. Choosing circuit IDs in create cells - The CircID for a CREATE cell is an arbitrarily chosen nonzero integer, - selected by the node (OP or OR) that sends the CREATE cell. In link - protocol 3 or lower, CircIDs are 2 bytes long; in protocol 4 or - higher, CircIDs are 4 bytes long. + The CircID for a CREATE/CREATE2 cell is an arbitrarily chosen + nonzero integer, selected by the node (OP or OR) that sends the + CREATE/CREATE2 cell. In link protocol 3 or lower, CircIDs are 2 + bytes long; in protocol 4 or higher, CircIDs are 4 bytes long. - To prevent CircID collisions, when one node sends a CREATE cell to - another, it chooses from only one half of the possible values based - on the ORs' public identity keys. + To prevent CircID collisions, when one node sends a CREATE/CREATE2 + cell to another, it chooses from only one half of the possible + values based on the ORs' public identity keys. In link protocol version 3 or lower, if the sending node has a lower key, it chooses a CircID with an MSB of 0; otherwise, it chooses a CircID with an MSB of 1. (Public keys are compared numerically by modulus.) With protocol version 3 or lower, a client with no public key MAY choose any CircID it wishes, since clients never need to process a - CREATE cell. + CREATE/CREATE2 cell. In link protocol version 4 or higher, whichever node initiated the connection sets its MSB to 1, and whichever node didn't initiate the @@ -1234,11 +1235,12 @@ see tor-design.pdf. 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 cell along the - connection, to be received by the first onion router. + 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 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. @@ -1248,11 +1250,11 @@ 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 + 2. Send the onion skin in a relay EXTEND/EXTEND2 cell along 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. + 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 @@ -1377,7 +1379,8 @@ see tor-design.pdf. 5.5.2. Forward Direction - The forward direction is the direction that CREATE cells are sent. + The forward direction is the direction that CREATE/CREATE2 cells + are sent. 5.5.2.1. Routing from the Origin @@ -1407,7 +1410,8 @@ see tor-design.pdf. 5.5.3. Backward Direction - The backward direction is the opposite direction from CREATE cells. + The backward direction is the opposite direction from + CREATE/CREATE2 cells. 5.5.3.1. Relaying Backward at Onion Routers @@ -1439,12 +1443,12 @@ see tor-design.pdf. inbound RELAY_EARLY cells, it MUST close the circuit immediately. When speaking v2 of the link protocol or later, clients MUST only send - EXTEND cells inside RELAY_EARLY cells. Clients SHOULD send the first ~8 + EXTEND/EXTEND2 cells inside RELAY_EARLY cells. Clients SHOULD send the first ~8 RELAY cells that are not targeted at the first hop of any circuit as RELAY_EARLY cells too, in order to partially conceal the circuit length. - [Starting with Tor 0.2.3.11-alpha, relays should - reject any EXTEND cell not received in a RELAY_EARLY cell.] + [Starting with Tor 0.2.3.11-alpha, relays should reject any + EXTEND/EXTEND2 cell not received in a RELAY_EARLY cell.] 6. Application connections and stream management @@ -1935,10 +1939,11 @@ see tor-design.pdf. 9.3. "Relay" - The "relay" protocols are those used to handle CREATE cells, and those that - handle the various RELAY cell types received after a CREATE cell. (Except, - relay cells used to manage introduction and rendezvous points are managed - with the "HSIntro" and "HSRend" protocols respectively.) + The "relay" protocols are those used to handle CREATE/CREATE2 + cells, and those that handle the various RELAY cell types received + after a CREATE/CREATE2 cell. (Except, relay cells used to manage + introduction and rendezvous points are managed with the "HSIntro" + and "HSRend" protocols respectively.) Current versions are:

1 0

[torspec/master] Clarify all-zeroes relay fingerprint behavior
by nickm＠torproject.org 30 Jul '18

30 Jul '18

commit 1f0d38a7632b1861039d040089b245eba24e3318 Author: Taylor Yu <catalyst(a)torproject.org> Date: Fri Jul 20 16:56:29 2018 -0500 Clarify all-zeroes relay fingerprint behavior The all-zeroes special case for EXTEND/EXTEND2 cells is for relay fingerprints/public keys, not cell crypto digests. Closes ticket 26893. --- tor-spec.txt | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/tor-spec.txt b/tor-spec.txt index b88befe..02bb9ae 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1264,11 +1264,12 @@ see tor-design.pdf. 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 + As special cases, if the EXTEND/EXTEND2 cell includes a legacy + identity, identity fingerprint, or Ed25519 identity 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.) When an onion router receives a CREATE/CREATE2 cell, if it already has a

1 0