Connect to Tor hidden services by default

[petertodd]

Sets -onion=127.0.0.1:9050 by default, which means we're able to connect to hidden services automatically if Tor is running locally. Natural followup to @laanwj's #6639, which creates hidden services automatically.

Currently the way addrman works hidden service peers won't be chosen very often, as there just aren't all that many of them on the network right now. It might be worth addressing that in a future pull-req to deliberately set aside connection slots groups for different types of peers, rather than having all outgoing connections be picked in the same way.

[laanwj]

Concept ACK, but I'm not sure setting onion proxy to 127.0.0.1:9051 by default is a good idea.
Even if no tor is present it will try and try and keep trying to connect to onions.

Maybe a better approach would be to have torcontrol set -onion proxy automatically, when it manages to negotiate with tor?
(possibly it could even ask tor what its port it)

[petertodd]

So, the disadvantage with that idea is support for the HS control thing is actually pretty recent, while connecting to 127.0.0.1:9050 works with any Tor version. OTOH, come to think of it there's a valid argument that we want the # of nodes connecting to HS's to grow in line with the number of nodes making them available.

[laanwj]

In principle the tor control port authentication/communication works with older versions. It's just the HS creation itself that is recent. If the control connection is also used for other things it could tolerate that failing.

[petertodd]

@laanwj How about this?

I looked into getting the proxy info automatically; doesn't look to be trivial as you have to use the GETCONF command on the control port to read the config file values yourself, and what they actually mean for you is non-trivial. I'm inclined to just use the hardcoded default - pretty rare for that to be setup differently.

[petertodd]

(and yeah, the duplication of code is kinda ugly; open to suggestions)

[laanwj]

Agree that this may be the best thing to do for now. This sets -onion when tor is there, unless an explicit -onion proxy was given, or it was explicitly disabled using -onion=0.

(and you are right, actually getting a proxy port from Tor given just the control port seems to be non-trivial! I thought it was just me)

Maybe also disable the NET_TOR proxy in disconnected_cb, if it was enabled by this mechanism?

[gmaxwell]

Concept ACK. We should do something like this; otherwise we could get a strange result where listening gets commonly setup but we can't connect out to it!

[TheBlueMatt]

Concept ACK

On November 24, 2015 2:24:50 PM PST, Gregory Maxwell notifications@github.com wrote:

Concept ACK. We should do something like this; otherwise we could get
a strange result where listening gets commonly setup but we can't
connect out to it!

---

Reply to this email directly or view it on GitHub:
#7090 (comment)

[laanwj]

@petertodd Not saying it has to be done in this pull, but requesting the proxy port(s) seems easy enough, after experimenting a bit:

$ nc 127.0.0.1 9051
AUTHENTICATE <hexify(control_auth_cookie)>
250 OK
GETCONF SocksPort
250 SocksPort=9050

(see posts below for better option)

[petertodd]

@laanwj The problem is SocksPort can be in many different formats depending on the local configuration, not to mention multiple lines of SocksPort's.

Re: disconnected_cb, I'm inclined to just leave the behavior the same as what -onion would do anyway for simplicity.

Removed the first two reverted commits; ready for merging.

[gmaxwell]

utACK.

[laanwj]

@petertodd OK, yeah, the option itself is reasonable complicated

SOCKSPort [address:]port|unix:path|auto [flags] [isolation flags]

It even has Set it to "auto" to have Tor pick a port for you. This makes querying this option a no-go. I wonder what the way is to find out what the port is in that case.
Hm https://trac.torproject.org/projects/tor/ticket/3076
Apparently the official way is:

GETINFO net/listeners/socks
250-net/listeners/socks="127.0.0.1:9050"
250 OK

[laanwj]

Nit: Probably, proxyRandomize should be always true if we know this is Tor. The option exists because people may want to disable it for non-tor SOCKS5 proxies, there's not really a reason to disable it for Tor.

[petertodd]

Fixed.

[laanwj]

Tested ACK. getnetworkinfo when starting bitcoind with Tor running:

    {
      "name": "onion",
      "limited": false,
      "reachable": true,
      "proxy": "127.0.0.1:9050",
      "proxy_randomize_credentials": true
    }

Starting it without Tor running:

    {
      "name": "onion",
      "limited": false,
      "reachable": false,
      "proxy": "",
      "proxy_randomize_credentials": false
    }

[petertodd]

@isislovecruft See above - can you confirm that this GETINFO thing what we're supposed to be doing?

[sipa]

Concept ACK

[leif]

Two thoughts:

1. Many (most?) desktop users will have tor installed via Tor Browser Bundle, which has its SOCKS listener on port 9150 rather than 9050 (which the "system tor", eg tor installed via apt-get, does). Some applications that want to use Tor will automatically try both ports, for instance: https://github.com/agl/pond/blob/master/client/client.go#L686
2. Using Tor opportunistically by default will cause many users who want to use Tor to take no action to configure it since it appears to already be doing what they want it to by default. But, if at some point in the future their Tor process is not running, they will unwittingly fail open!

So, I'd recommend not using tor automatically when it is found. It would be better to probe for tor (on both port 9050 and 9150, in that order) and if it is found prompt the user "We noticed you have Tor running. Do you want to connect using it? [Just Once] [Never] [Always (default)]"

When "Always" is selected, a configuration option should be set which causes it to fail closed if tor is not running in the future.

[sipa]

To be clear: this will not by default route all Bitcoin traffic over Tor. It will only enable connecting to hidden services (nodes listening on a port "on" the tor network, so to speak).

[paveljanik]

BTW, how do we know that the app listening on the port is tor?

[leif]

Thanks @sipa, i missed that.

I suppose there are actually four possible tor configurations:

1. No Tor
2. Tor for Hidden Service connections, but make regular connections without Tor
3. Make all connections via Tor
4. Only connect to Hidden Services

Hopefully (4) can be the default in a future release after there are enough onion nodes running!

For nodes advertising both a hidden service and a regular IP address, are their two advertisements linkable?

@paveljanik you can't really. you could do some checking to see if it seems like tor, but what would your threat model be?

[paveljanik]

Well, it could be some other application run by other user of the same system. Of course the user is not supposed to be doing anything important on such system, but anyway...

[maflcko]

@petertodd I assume this does not work when the user defines no password nor cookie?

[tailsjoin]

To avoid the behaviour of this merge one must set something for onion, correct?

Currently I have nothing set for onion, but I am running a hidden service for listening. Will this effect my setup? I have 127.0.0.1:905x ports setup for tor, but they're not the ports I use for bitcoin. I have special, isolated ports set up (not locally) for bitcoin and my hidden service. Is this going to cause drama for me if I don't set onion, essentially creating two hidden services?

[laanwj]

To avoid the behaviour of this merge one must set something for onion, correct?

listenonion=0 to disable any automatic tor behavior