HiddenServicePort should connect to localhost by default

HiddenServicePort currently connects to 127.0.0.1 by default, but this will fail in configs where localhost is somewhere else in 127.0.0.0/8 or is [::1]. (Such as BSD jails.)

Instead, we can:

• resolve "localhost", and check that it's in 127.0.0.0/8 or [::1], and use the IPv4 address first for compatibility with existing configurations
• default to 127.0.0.1 if that exists
• default to [::1] if 127.0.0.1 does not exist

This is not a security issue, as it results in a failed hidden service connection on unusual configs. It's a minor usability issue.

(Split from #17901 (moved) / #11360 (moved).)

changed milestone to %Tor: unspecified

added component::core tor/tor easy ipv6 maybe-bad-idea-or-maybe-not milestone::Tor: unspecified owner::teor points::small priority::low resolution::wontfix severity::normal status::closed tor-hs type::enhancement labels

I think there's a better algorithm here that doesn't require address resolution:

• check for interface addresses in 127/8 and ::1
• try to connect to an address in 127/8
  • if there are multiple addresses, choose the one closest to 127.0.0.1
  • if no IPv4 or IPv6 addresses can be discovered on the system, try 127.0.0.1
• if the first connection fails , try to connect to ::1 if
  • ::1 is present on the system, or
  • no IPv4 or IPv6 addresses can be discovered on the system

This supports IPv4 and IPv6, and preserves the existing IPv4 127.0.0.1 default behaviour, and the existing preference for IPv4 over IPv6, yet also supports IPv6-only systems.

See https://trac.torproject.org/projects/tor/ticket/17901#comment:16 for the related behaviour in #17901 (moved).

Trac:
Owner: N/A to teor
Status: new to assigned

If both connections fail, log a warning that tells the user to use AF_UNIX if their system and backend server support it, or to supply an explicit IP address.

Trac:
Priority: Medium to Low

I honestly think this is a security risk. Hidden service operators should have to explicitly supply IP addresses.

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final
Resolution: N/A to wontfix
Status: assigned to closed
Keywords: N/A deleted, easy added

How can you explicitly supply address if it can be IPv4 or IPv6, or both? Hardcoded 127.0.0.1 should be avoided at all (not only for HS). https://stackoverflow.com/questions/3715925/localhost-vs-127-0-0-1

Replying to bugzilla:

How can you explicitly supply address if it can be IPv4 or IPv6, or both? Hardcoded 127.0.0.1 should be avoided at all (not only for HS). https://stackoverflow.com/questions/3715925/localhost-vs-127-0-0-1

HiddenServicePort VIRTPORT [TARGET]

Your options are:

HiddenServicePort 80 127.0.0.1:80 HiddenServicePort 80 [::1]:80 HiddenServicePort 80 unix:/var/app/socket

127.0.0.1:VIRTPORT is a sensible default.

Please see the Tor manual page for more details.

Trac:
Status: closed to reopened
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???
Resolution: wontfix to N/A

Plus

somewhere else in 127.0.0.0/8 Plus It's a common practice to use addr of current network interface by default (on some systems) Can it be automated for all local connections? (in tor-client, etc)

Replying to bugzilla:

Plus

somewhere else in 127.0.0.0/8 Plus It's a common practice to use addr of current network interface by default (on some systems) Can it be automated for all local connections? (in tor-client, etc)

If the current network interface is not a loopback interface, it's security risk, so we want users to configure it explicitly.

If the current network interface is a loopback interface, then sure. But I think we might have trouble finding a portable API for discovering the current loopback network interface. Do you know of any?

Also, there's value in cross-platform consistency. Using the same algorithm on different platforms would provide this. I suggested localhost IPv4, localhost IPv6, 127.0.0.1, and [::1], but we might want to consider other 127/8 addresses as well.

Trac:
Points: N/A to small

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: N/A deleted, maybe-bad-idea-or-maybe-not tor-hs added
Reviewer: N/A to N/A

I agree with teor that it's a security risk.

We should let the user say what address to point the onion service connections to.

I've seen cases where a local resolve attempt for localhost went out to Comcast's dns servers, which helpfully told me that localhost was 127.0.0.1, so then my application correctly went there.

Let's leave DNS the heck out of local computer decisions. :)

Ok, let's close this one, because 127.0.0.1:VIRTPORT is a sensible default, and it's hard to configure an OS without IPv4 localhost.

Trac:
Resolution: N/A to wontfix
Status: reopened to closed

closed

moved to tpo/core/tor#17948 (closed)