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.
This commit is contained in:
teor 2017-10-26 16:30:24 +11:00 committed by Nick Mathewson
parent b4aa8fc3d9
commit 77ed99b1a7

View File

@ -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