Opened 7 months ago

Last modified 5 months ago

#33796 assigned defect

socks: Prefer IPv6 by default on SOCKS port broke torsocks

Reported by: dgoulet Owned by: dgoulet
Priority: Medium Milestone: Tor: 0.4.4.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-dns, torsocks, ipv6, 044-should, postfreeze-ok
Cc: teor Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In commit bf2a399fc0d90df76e091fa3259f7c1b8fb87781 we made all SocksPort to prefer IPv6 which means that any DNS resolution answer will pick IPv6, if exists, over IPv4.

For torsocks, this is a problem because by default it tries to resolve an IPv4. This can be fixed _except_ when the libc call (ex: getaddrinfo()) is specifically requesting an IPv4 (hints.ai_family = AF_INET).

There is currently no way for torsocks to ask tor, via the SocksPort, a specific INET family and thus torsocks receives back the IPv6 and can't handle it because the application was expecting an IPv4.

So this example fails often as we have more and more Exits are able to resolve IPv6:

wget -4 some.url

And still many applications by default will request an IPv4 because they don't handle IPv6.

Bottom line is that torsocks use case is broken for when an application is specifically requesting an INET family...

As a reminder, torsocks can _not_ pass the hostname directly in the SOCKS connection because it hijacks libc calls and thus flow can only be 1) DNS resolution, 2) connect() with an IP address.

I'm not sure what to do here... I think the ideal scenario would be to have a way for our "resolve" SOCKS extension to specify an address family value.

For instance, the F0 (RESOLVE command) would be "return whatever" and then we could extend to have RESOLVE4 and RESOLVE6..... HACK-ish but those extensions are already a hack so...

(That prefer IPv6 change went in 043)

Child Tickets

TicketStatusOwnerSummaryComponent
#33804closeddgouletDefer "PreferIPv6 by default" to 0.4.4Core Tor/Tor

Change History (5)

comment:1 Changed 7 months ago by teor

Tor Browser has set PreferIPv6 for some time.
But I guess that isn't a common config for torsocks?

And there aren't any unit tests or integration tests that make sure that torsocks keeps working?
That's a shame, we would have caught this issue much earlier.

We thought that allowing users to configure NoPreferIPv6 in tor was enough. But that only works if people control their system tor instance.

Here's what I suggest we do:

  • undo the default PreferIPv6 flag change in 0.4.3
  • re-do the default PreferIPv6 flag change in 0.4.4
  • add new socks commands for IPv4-only and IPv6-only in 0.4.4
  • update torsocks to use those commands (when available)
  • write unit tests or integration tests that cover the Torsocks use cases

How much of that work are you able to do, dgoulet?

comment:2 Changed 7 months ago by teor

Keywords: 043-must added

comment:3 in reply to:  1 Changed 7 months ago by dgoulet

Replying to teor:

Tor Browser has set PreferIPv6 for some time.
But I guess that isn't a common config for torsocks?

Since we don't set it by default (until now), no not a common use case at all.

And there aren't any unit tests or integration tests that make sure that torsocks keeps working?

Jenkins builders don't do outbound tor connections so torsocks DNS tests are disabled :(.

And this problem is seen "sometimes" when we hit an IPv6 exits basically.

That's a shame, we would have caught this issue much earlier.

I personally use torsocks every day but only with .onion ... so I didn't caught it until I tried yesterday multiple things that never worked and so I investigated.

Torsocks is _not_ under active development so unless users report issues (which I try to be a very active one), we don't caught that many with the tests. Jenkins builder runs on last commit but then doesn't re-run them regularly but even if Jenkins was able to run the DNS tests, if run once, there is a good chance it would just work.

I run tor git master on my computer and so if I had a use case with a non .onion, I think I would have caught that much earlier. Thus, maybe time for me to add that regular use case to my daily flow :).

We thought that allowing users to configure NoPreferIPv6 in tor was enough. But that only works if people control their system tor instance.

Here's what I suggest we do:

  • undo the default PreferIPv6 flag change in 0.4.3
  • re-do the default PreferIPv6 flag change in 0.4.4
  • add new socks commands for IPv4-only and IPv6-only in 0.4.4
  • update torsocks to use those commands (when available)
  • write unit tests or integration tests that cover the Torsocks use cases

How much of that work are you able to do, dgoulet?

Since TB uses PreferIPv6, we won't break that use case by moving this commit to 044 as long as we introduce that new "resolve IPv4/v6" feature on the SOCKS port in 044.

I could implement all this (including the spec) in couple days of work top _but_ it is always the review round that eats up the time with this. So let say time 3 or 4 would results in couple weeks to have it all imo. Then I can adapt torsocks after.

I thought of other applications that could be using our SocksPort the way torsocks do (that is DNS + connect()) but except for specific DNS tools like dig or host (which most people probably use _with_ torsocks), I assume the _common_ use is to pass the hostname to Tor.

comment:4 Changed 7 months ago by teor

Keywords: 044-should added; 043-must removed
Milestone: Tor: 0.4.3.x-finalTor: 0.4.4.x-final
Owner: set to dgoulet
Status: newassigned

I made #33804 for the urgent change to 0.4.3: defer the PreferIPv6 default change to 0.4.4.

The rest of this ticket can be done any time in 0.4.4.

comment:5 Changed 5 months ago by nickm

Keywords: postfreeze-ok added

Mark tickets which are important or safe enough to look at post-freeze for 0.4.4.

Note: See TracTickets for help on using tickets.