Opened 2 years ago

Closed 8 months ago

#17948 closed enhancement (wontfix)

HiddenServicePort should connect to localhost by default

Reported by: teor Owned by: teor
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6, easy, maybe-bad-idea-or-maybe-not tor-hs
Cc: Actual Points:
Parent ID: Points: small
Reviewer: Sponsor:

Description

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 / #11360.)

Child Tickets

Change History (16)

comment:1 Changed 2 years ago by teor

Owner: set to teor
Status: newassigned

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.

comment:2 Changed 2 years ago by teor

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.

comment:3 Changed 2 years ago by nickm

Priority: MediumLow

comment:4 Changed 2 years ago by teor

Keywords: easy added
Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final
Resolution: wontfix
Status: assignedclosed

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

comment:5 Changed 2 years ago by 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

comment:6 in reply to:  5 Changed 2 years ago by teor

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.

comment:7 Changed 2 years ago by teor

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???
Resolution: wontfix
Status: closedreopened

comment:8 Changed 2 years ago by 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)

comment:9 in reply to:  8 Changed 2 years ago by teor

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.

comment:10 Changed 2 years ago by nickm

Points: small

comment:11 Changed 18 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:12 Changed 17 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

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

comment:13 Changed 12 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:14 Changed 11 months ago by nickm

Keywords: maybe-bad-idea-or-maybe-not tor-hs added

comment:15 Changed 8 months ago by arma

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. :)

comment:16 Changed 8 months ago by teor

Resolution: wontfix
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.