tor-commits November 2017

tor-commits@lists.torproject.org

16 participants
2019 discussions

[tor/release-0.3.2] Test that IPv6-only clients can use microdescriptors
by nickm＠torproject.org 02 Nov '17

02 Nov '17

commit 27ea6fcd31ceb7dd9e48e5586aa05f05bfe86e0a Author: teor <teor2345(a)gmail.com> Date: Wed Nov 1 17:13:07 2017 +1100 Test that IPv6-only clients can use microdescriptors When running "make test-network-all", test that IPv6-only clients can use microdescriptors. IPv6-only microdescriptor client support was fixed in tor 0.3.0.1-alpha. Requires chutney master 61c28b9 or later. Closes ticket 24109. --- changes/ticket24109 | 4 ++++ src/test/include.am | 6 +++--- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/changes/ticket24109 b/changes/ticket24109 new file mode 100644 index 000000000..f66271817 --- /dev/null +++ b/changes/ticket24109 @@ -0,0 +1,4 @@ + o Minor features (integration tests): + - Test that IPv6-only clients can use microdescriptors when running + "make test-network-all". Requires chutney master 61c28b9 or later. + Closes ticket 24109. diff --git a/src/test/include.am b/src/test/include.am index 7300b8541..610918e9d 100644 --- a/src/test/include.am +++ b/src/test/include.am @@ -43,9 +43,9 @@ TEST_CHUTNEY_FLAVORS = basic-min bridges-min hs-v2-min hs-v3-min \ single-onion-v23 # only run if we can ping6 ::1 (localhost) # IPv6-only v3 single onion services don't work yet, so we don't test the -# single-onion-v23-ipv6 flavor -TEST_CHUTNEY_FLAVORS_IPV6 = bridges+ipv6-min ipv6-exit-min hs-v23-ipv6 \ - single-onion-ipv6 +# single-onion-v23-ipv6-md flavor +TEST_CHUTNEY_FLAVORS_IPV6 = bridges+ipv6-min ipv6-exit-min hs-v23-ipv6-md \ + single-onion-ipv6-md # only run if we can find a stable (or simply another) version of tor TEST_CHUTNEY_FLAVORS_MIXED = mixed+hs-v23

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.2' into release-0.3.2
by nickm＠torproject.org 02 Nov '17

02 Nov '17

commit 33652fce623b926551617873bcaa686d335794b4 Merge: aed642a4b 27ea6fcd3 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 2 10:26:30 2017 -0400 Merge branch 'maint-0.3.2' into release-0.3.2 changes/ticket24109 | 4 ++++ src/test/include.am | 6 +++--- 2 files changed, 7 insertions(+), 3 deletions(-)

1 0

[tor/master] Test that IPv6-only clients can use microdescriptors
by nickm＠torproject.org 02 Nov '17

02 Nov '17

1 0

[tor/master] Merge branch 'maint-0.3.2'
by nickm＠torproject.org 02 Nov '17

02 Nov '17

commit f865993653604d7e3e8256d052398591627f8989 Merge: a46dcc070 27ea6fcd3 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 2 10:26:30 2017 -0400 Merge branch 'maint-0.3.2' changes/ticket24109 | 4 ++++ src/test/include.am | 6 +++--- 2 files changed, 7 insertions(+), 3 deletions(-)

1 0

[tor/maint-0.3.2] Test that IPv6-only clients can use microdescriptors
by nickm＠torproject.org 02 Nov '17

02 Nov '17

1 0

[tor/release-0.3.2] Remove buggy IPv6 support from pick_intro_point() and service_intro_point_new()
by nickm＠torproject.org 02 Nov '17

02 Nov '17

commit b4aa8fc3d918cc3aea375985c44abd086f91ae7a Author: teor <teor2345(a)gmail.com> Date: Thu Oct 26 14:47:54 2017 +1100 Remove buggy IPv6 support from pick_intro_point() and service_intro_point_new() The previous version of these functions had the following issues: * they can't supply both the IPv4 and IPv6 addresses in link specifiers, * they try to fall back to a 3-hop path when the address for a direct connection is unreachable, but this isn't supported by launch_rendezvous_point_circuit(), so it fails. But we can't fix these things in a bugfix release. Instead, always put IPv4 addresses in link specifiers. And if a v3 single onion service can't reach any intro points, fail. This supports v3 hidden services on IPv4, dual-stack, and IPv6, and v3 single onion services on IPv4 only. Part of 23820, bugfix on 0.3.2.1-alpha. --- src/or/hs_service.c | 50 ++++++++++++++++++++++++++++++-------------------- 1 file changed, 30 insertions(+), 20 deletions(-) diff --git a/src/or/hs_service.c b/src/or/hs_service.c index 3d1945aa9..f334de643 100644 --- a/src/or/hs_service.c +++ b/src/or/hs_service.c @@ -375,7 +375,14 @@ service_intro_point_free_(void *obj) /* Return a newly allocated service intro point and fully initialized from the * given extend_info_t ei if non NULL. If is_legacy is true, we also generate - * the legacy key. On error, NULL is returned. */ + * the legacy key. On error, NULL is returned. + * + * If ei is NULL, returns a hs_service_intro_point_t with an empty link + * specifier list and no onion key. (This is used for testing.) + * + * ei must be an extend_info_t containing an IPv4 address. (We will add supoort + * for IPv6 in a later release.) When calling extend_info_from_node(), pass + * 0 in for_direct_connection to make sure ei always has an IPv4 address. */ STATIC hs_service_intro_point_t * service_intro_point_new(const extend_info_t *ei, unsigned int is_legacy) { @@ -427,8 +434,8 @@ service_intro_point_new(const extend_info_t *ei, unsigned int is_legacy) goto done; } - /* We'll try to add all link specifier. Legacy, IPv4 and ed25519 are - * mandatory. */ + /* We'll try to add all link specifiers. Legacy is mandatory. + * IPv4 or IPv6 is required, and we always send IPv4. */ ls = hs_desc_link_specifier_new(ei, LS_IPV4); /* It is impossible to have an extend info object without a v4. */ if (BUG(!ls)) { @@ -450,11 +457,7 @@ service_intro_point_new(const extend_info_t *ei, unsigned int is_legacy) smartlist_add(ip->base.link_specifiers, ls); } - /* IPv6 is optional. */ - ls = hs_desc_link_specifier_new(ei, LS_IPV6); - if (ls) { - smartlist_add(ip->base.link_specifiers, ls); - } + /* IPv6 is not supported in this release. */ /* Finally, copy onion key from the extend_info_t object. */ memcpy(&ip->onion_key, &ei->curve25519_onion_key, sizeof(ip->onion_key)); @@ -1520,10 +1523,17 @@ build_all_descriptors(time_t now) /* Randomly pick a node to become an introduction point but not present in the * given exclude_nodes list. The chosen node is put in the exclude list * regardless of success or not because in case of failure, the node is simply - * unsusable from that point on. If direct_conn is set, try to pick a node - * that our local firewall/policy allows to directly connect to and if not, - * fallback to a normal 3-hop node. Return a newly allocated service intro - * point ready to be used for encoding. NULL on error. */ + * unsusable from that point on. + * + * If direct_conn is set, try to pick a node that our local firewall/policy + * allows us to connect to directly. If we can't find any, return NULL. + * This function supports selecting dual-stack nodes for direct single onion + * service IPv6 connections. But it does not send IPv6 addresses in link + * specifiers. (Current clients don't use IPv6 addresses to extend, and + * direct client connections to intro points are not supported.) + * + * Return a newly allocated service intro point ready to be used for encoding. + * Return NULL on error. */ static hs_service_intro_point_t * pick_intro_point(unsigned int direct_conn, smartlist_t *exclude_nodes) { @@ -1537,12 +1547,9 @@ pick_intro_point(unsigned int direct_conn, smartlist_t *exclude_nodes) node = router_choose_random_node(exclude_nodes, get_options()->ExcludeNodes, direct_conn ? direct_flags : flags); - if (node == NULL && direct_conn) { - /* Unable to find a node for direct connection, let's fall back to a - * normal 3-hop node. */ - node = router_choose_random_node(exclude_nodes, - get_options()->ExcludeNodes, flags); - } + /* Unable to find a node. When looking for a node for a direct connection, + * we could try a 3-hop path instead. We'll add support for this in a later + * release. */ if (!node) { goto err; } @@ -1553,8 +1560,11 @@ pick_intro_point(unsigned int direct_conn, smartlist_t *exclude_nodes) smartlist_add(exclude_nodes, (void *) node); /* We do this to ease our life but also this call makes appropriate checks - * of the node object such as validating ntor support for instance. */ - info = extend_info_from_node(node, direct_conn); + * of the node object such as validating ntor support for instance. + * + * We must provide an extend_info for clients to connect over a 3-hop path, + * so we don't pass direct_conn here. */ + info = extend_info_from_node(node, 0); if (BUG(info == NULL)) { goto err; }

1 0

[tor/release-0.3.2] Remove buggy IPv6 and ed25519 handling from get_lspecs_from_extend_info()
by nickm＠torproject.org 02 Nov '17

02 Nov '17

commit 77ed99b1a79e61146d9e3b9f51aac4fd1c2f5b03 Author: teor <teor2345(a)gmail.com> Date: Thu Oct 26 16:30:24 2017 +1100 Remove buggy IPv6 and ed25519 handling from get_lspecs_from_extend_info() The previous version of this function had the following issues: * it didn't check if the extend_info contained an IPv6 address, * it didn't check if the ed25519 identity key was valid. But we can't add IPv6 support in a bugfix release. Instead, BUG() if the address is an IPv6 address, so we always put IPv4 addresses in link specifiers. And ignore missing ed25519 identifiers, rather than generating an all-zero link specifier. This supports v3 hidden services on IPv4, dual-stack, and IPv6, and v3 single onion services on IPv4 only. Part of 23820, bugfix on 0.3.2.1-alpha. --- src/or/hs_circuit.c | 37 ++++++++++++++++++++++++++----------- 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/src/or/hs_circuit.c b/src/or/hs_circuit.c index e1e513c5f..c8c9b4e56 100644 --- a/src/or/hs_circuit.c +++ b/src/or/hs_circuit.c @@ -533,7 +533,10 @@ retry_service_rendezvous_point(const origin_circuit_t *circ) } /* Using an extend info object ei, set all possible link specifiers in lspecs. - * IPv4, legacy ID and ed25519 ID are mandatory thus MUST be present in ei. */ + * legacy ID is mandatory thus MUST be present in ei. If IPv4 is not present, + * logs a BUG() warning, and returns an empty smartlist. Clients never make + * direct connections to rendezvous points, so they should always have an + * IPv4 address in ei. */ static void get_lspecs_from_extend_info(const extend_info_t *ei, smartlist_t *lspecs) { @@ -542,7 +545,11 @@ get_lspecs_from_extend_info(const extend_info_t *ei, smartlist_t *lspecs) tor_assert(ei); tor_assert(lspecs); - /* IPv4 is mandatory. */ + /* We require IPv4, we will add IPv6 support in a later tor version */ + if (BUG(!tor_addr_is_v4(&ei->addr))) { + return; + } + ls = link_specifier_new(); link_specifier_set_ls_type(ls, LS_IPV4); link_specifier_set_un_ipv4_addr(ls, tor_addr_to_ipv4h(&ei->addr)); @@ -560,15 +567,15 @@ get_lspecs_from_extend_info(const extend_info_t *ei, smartlist_t *lspecs) link_specifier_set_ls_len(ls, link_specifier_getlen_un_legacy_id(ls)); smartlist_add(lspecs, ls); - /* ed25519 ID is mandatory. */ - ls = link_specifier_new(); - link_specifier_set_ls_type(ls, LS_ED25519_ID); - memcpy(link_specifier_getarray_un_ed25519_id(ls), &ei->ed_identity, - link_specifier_getlen_un_ed25519_id(ls)); - link_specifier_set_ls_len(ls, link_specifier_getlen_un_ed25519_id(ls)); - smartlist_add(lspecs, ls); - - /* XXX: IPv6 is not clearly a thing in extend_info_t? */ + /* ed25519 ID is only included if the node has it. */ + if (!ed25519_public_key_is_zero(&ei->ed_identity)) { + ls = link_specifier_new(); + link_specifier_set_ls_type(ls, LS_ED25519_ID); + memcpy(link_specifier_getarray_un_ed25519_id(ls), &ei->ed_identity, + link_specifier_getlen_un_ed25519_id(ls)); + link_specifier_set_ls_len(ls, link_specifier_getlen_un_ed25519_id(ls)); + smartlist_add(lspecs, ls); + } } /* Using the given descriptor intro point ip, the extend information of the @@ -1053,6 +1060,14 @@ hs_circ_send_introduce1(origin_circuit_t *intro_circ, * object which is used to build the content of the cell. */ setup_introduce1_data(ip, rend_circ->build_state->chosen_exit, subcredential, &intro1_data); + /* If we didn't get any link specifiers, it's because our extend info was + * bad. */ + if (BUG(!intro1_data.link_specifiers) || + !smartlist_len(intro1_data.link_specifiers)) { + log_warn(LD_REND, "Unable to get link specifiers for INTRODUCE1 cell on " + "circuit %u.", TO_CIRCUIT(intro_circ)->n_circ_id); + goto done; + } /* Final step before we encode a cell, we setup the circuit identifier which * will generate both the rendezvous cookie and client keypair for this

1 0

[tor/release-0.3.2] Remove buggy IPv6 support from hs_get_extend_info_from_lspecs()
by nickm＠torproject.org 02 Nov '17

02 Nov '17

commit 20b0e9e07d4a1726029c8214e431237a2959f21f Author: teor <teor2345(a)gmail.com> Date: Thu Oct 26 14:38:06 2017 +1100 Remove buggy IPv6 support from hs_get_extend_info_from_lspecs() The previous version of this function has the following issues: * it doesn't choose between IPv4 and IPv6 addresses correctly, and * it doesn't fall back to a 3-hop path when the address for a direct connection is unreachable. But we can't fix these things in a bugfix release. Instead, treat IPv6 addresses like any other unrecognised link specifier and ignore them. If there is no IPv4 address, return NULL. This supports v3 hidden services on IPv4, dual-stack, and IPv6, and v3 single onion services on IPv4 only. Part of 23820, bugfix on 0.3.2.1-alpha. --- src/or/hs_common.c | 78 ++++++++++++++++++++---------------------------------- 1 file changed, 29 insertions(+), 49 deletions(-) diff --git a/src/or/hs_common.c b/src/or/hs_common.c index 42c15c80d..f79aeb598 100644 --- a/src/or/hs_common.c +++ b/src/or/hs_common.c @@ -1638,24 +1638,22 @@ hs_pick_hsdir(smartlist_t *responsible_dirs, const char *req_key_str) /* From a list of link specifier, an onion key and if we are requesting a * direct connection (ex: single onion service), return a newly allocated - * extend_info_t object. This function checks the firewall policies and if we - * are allowed to extend to the chosen address. + * extend_info_t object. This function always returns an extend info with + * an IPv4 address, or NULL. * - * if either IPv4 or legacy ID is missing, error. - * if not direct_conn, IPv4 is prefered. - * if direct_conn, IPv6 is prefered if we have one available. - * if firewall does not allow the chosen address, error. - * - * Return NULL if we can fulfill the conditions. */ + * It performs the following checks: + * if either IPv4 or legacy ID is missing, return NULL. + * if direct_conn, and we can't reach the IPv4 address, return NULL. + */ extend_info_t * hs_get_extend_info_from_lspecs(const smartlist_t *lspecs, const curve25519_public_key_t *onion_key, int direct_conn) { - int have_v4 = 0, have_v6 = 0, have_legacy_id = 0, have_ed25519_id = 0; + int have_v4 = 0, have_legacy_id = 0, have_ed25519_id = 0; char legacy_id[DIGEST_LEN] = {0}; - uint16_t port_v4 = 0, port_v6 = 0, port = 0; - tor_addr_t addr_v4, addr_v6, *addr = NULL; + uint16_t port_v4 = 0; + tor_addr_t addr_v4; ed25519_public_key_t ed25519_pk; extend_info_t *info = NULL; @@ -1671,14 +1669,6 @@ hs_get_extend_info_from_lspecs(const smartlist_t *lspecs, port_v4 = link_specifier_get_un_ipv4_port(ls); have_v4 = 1; break; - case LS_IPV6: - /* Skip if we already seen a v6. */ - if (have_v6) continue; - tor_addr_from_ipv6_bytes(&addr_v6, - (const char *) link_specifier_getconstarray_un_ipv6_addr(ls)); - port_v6 = link_specifier_get_un_ipv6_port(ls); - have_v6 = 1; - break; case LS_LEGACY_ID: /* Make sure we do have enough bytes for the legacy ID. */ if (link_specifier_getlen_un_legacy_id(ls) < sizeof(legacy_id)) { @@ -1700,55 +1690,45 @@ hs_get_extend_info_from_lspecs(const smartlist_t *lspecs, } } SMARTLIST_FOREACH_END(ls); - /* IPv4 and legacy ID are mandatory. */ + /* Legacy ID is mandatory, and we require IPv4. */ if (!have_v4 || !have_legacy_id) { goto done; } - /* By default, we pick IPv4 but this might change to v6 if certain - * conditions are met. */ - addr = &addr_v4; port = port_v4; - /* If we are NOT in a direct connection, we'll use our Guard and a 3-hop - * circuit so we can't extend in IPv6. And at this point, we do have an IPv4 - * address available so go to validation. */ + /* We know we have IPv4, because we just checked. */ if (!direct_conn) { + /* All clients can extend to any IPv4 via a 3-hop path. */ goto validate; - } - - /* From this point on, we have a request for a direct connection to the - * rendezvous point so make sure we can actually connect through our - * firewall. We'll prefer IPv6. */ - - /* IPv6 test. */ - if (have_v6 && - fascist_firewall_allows_address_addr(&addr_v6, port_v6, - FIREWALL_OR_CONNECTION, 1, 1)) { - /* Direct connection and we can reach it in IPv6 so go for it. */ - addr = &addr_v6; port = port_v6; - goto validate; - } - /* IPv4 test and we are sure we have a v4 because of the check above. */ - if (fascist_firewall_allows_address_addr(&addr_v4, port_v4, - FIREWALL_OR_CONNECTION, 0, 0)) { + } else if (direct_conn && + fascist_firewall_allows_address_addr(&addr_v4, port_v4, + FIREWALL_OR_CONNECTION, + 0, 0)) { /* Direct connection and we can reach it in IPv4 so go for it. */ - addr = &addr_v4; port = port_v4; goto validate; + + /* We will add support for falling back to a 3-hop path in a later + * release. */ + } else { + /* If we can't reach IPv4, return NULL. */ + goto done; } + /* We will add support for IPv6 in a later release. */ + validate: /* We'll validate now that the address we've picked isn't a private one. If * it is, are we allowing to extend to private address? */ - if (!extend_info_addr_is_allowed(addr)) { - log_warn(LD_REND, "Requested address is private and it is not " - "allowed to extend to it: %s:%u", - fmt_addr(&addr_v4), port_v4); + if (!extend_info_addr_is_allowed(&addr_v4)) { + log_fn(LOG_PROTOCOL_WARN, LD_REND, + "Requested address is private and we are not allowed to extend to " + "it: %s:%u", fmt_addr(&addr_v4), port_v4); goto done; } /* We do have everything for which we think we can connect successfully. */ info = extend_info_new(NULL, legacy_id, (have_ed25519_id) ? &ed25519_pk : NULL, NULL, - onion_key, addr, port); + onion_key, &addr_v4, port_v4); done: return info; }

1 0

[tor/master] Tweak a comment for a minor but important distinction
by nickm＠torproject.org 02 Nov '17

02 Nov '17

commit 6a9a118f9077c02ce60052275dcede88d9fd2aa3 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 2 10:22:32 2017 -0400 Tweak a comment for a minor but important distinction --- src/or/hs_circuit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/or/hs_circuit.c b/src/or/hs_circuit.c index a23edc36a..ee952f4d6 100644 --- a/src/or/hs_circuit.c +++ b/src/or/hs_circuit.c @@ -588,7 +588,7 @@ get_lspecs_from_extend_info(const extend_info_t *ei, smartlist_t *lspecs) link_specifier_set_ls_len(ls, link_specifier_getlen_un_legacy_id(ls)); smartlist_add(lspecs, ls); - /* ed25519 ID is only included if the node has it. */ + /* ed25519 ID is only included if the extend_info has it. */ if (!ed25519_public_key_is_zero(&ei->ed_identity)) { ls = link_specifier_new(); link_specifier_set_ls_type(ls, LS_ED25519_ID);

1 0

[tor/master] Merge branch 'maint-0.3.2'
by nickm＠torproject.org 02 Nov '17

02 Nov '17

commit a46dcc0709d29393a2cd1a0a547bf641f4a79aa6 Merge: a321f8f4a 6a9a118f9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 2 10:22:35 2017 -0400 Merge branch 'maint-0.3.2' changes/bug23820 | 5 ++++ src/or/hs_circuit.c | 66 ++++++++++++++++++++++++++++++++++----------- src/or/hs_client.c | 27 ++++++++++++++++--- src/or/hs_common.c | 78 ++++++++++++++++++++--------------------------------- src/or/hs_config.c | 16 ++++++++--- src/or/hs_service.c | 50 ++++++++++++++++++++-------------- src/test/include.am | 4 ++- 7 files changed, 153 insertions(+), 93 deletions(-)

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits November 2017