Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 328
    • Issues 328
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 32
    • Merge requests 32
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #33796
Closed
Open
Issue created Apr 02, 2020 by David Goulet@dgoulet🐼Owner

socks: Prefer IPv6 by default on SOCKS port broke torsocks: re-enable a better version after 0.4.4?

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)

Edited Aug 13, 2020 by Nick Mathewson
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking