[tor-bugs] #23820 [Core Tor/Tor]: Make sure v3 single onion services and v3 onion service clients only send IPv4 addresses

[Tor Bug Tracker & Wiki]

#23820: Make sure v3 single onion services and v3 onion service clients only send
IPv4 addresses
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  teor
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.2.1-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:  1
Parent ID:  #23493                               |         Points:  1
 Reviewer:  dgoulet                              |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 @teor, I can fix those if you have no time but just let me know what you
 think about them. If you do fix them, I propose we go in Gitlab mode next
 time.

 * To be clear, I know Tor can't extend to an IPv6 so this should NEVER
 happened in theory right? (in get_lspecs_from_extend_info())

 {{{
 +  if (BUG(!tor_addr_is_v4(&ei->addr))) {
 +    return;
 +  }
 }}}

 * The `intro1_data` is initialized with `setup_introduce1_data()` which
 guarantee that the link specifier list will be a valid smartlist pointer
 and never uninit. So here, I would remove the NULL check so we don't hide
 bugs.

 {{{
 +  if (!intro1_data.link_specifiers ||
 +      !smartlist_len(intro1_data.link_specifiers)) {
 }}}

 * We could have a function that returns a static string for this so we
 make sure that every logs will have the same keywords. Something like
 `service_type_str()`

 {{{
 service->config.is_single_onion ? "direct" : "multi-hop"
 }}}

 * I'm skeptical that this will help our logging. I think base32 would be
 closer to the onion address than the hex string:

 {{{
 +               safe_str_client(hex_str((const char *)service_pk->pubkey,
 +                                       ED25519_PUBKEY_LEN)));
 }}}

 * Hmm this is possible that is SingleHopMode 0 and NonAnonymous 1 ? ...
 Looking at `rend_service_non_anonymous_mode_enabled()` seems to me that
 they have to be consistent?

 {{{
 +      log_warn(LD_CONFIG, "IPv6-only v3 single onion services are not "
 +               "supported. Set HiddenServiceSingleHopMode 0 and "
 +               "HiddenServiceNonAnonymousMode 1, or set ClientUseIPv4
 1.");
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23820#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online