New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connect to Tor hidden services by default #7090

Merged
merged 1 commit into from Nov 27, 2015

Conversation

Projects
None yet
9 participants
@petertodd
Contributor

petertodd commented Nov 24, 2015

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 laanwj added the P2P label Nov 24, 2015

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 24, 2015

Member

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)

Member

laanwj commented Nov 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Nov 24, 2015

Contributor

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.

Contributor

petertodd commented Nov 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 24, 2015

Member

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.

Member

laanwj commented Nov 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Nov 24, 2015

Contributor

@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.

Contributor

petertodd commented Nov 24, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Nov 24, 2015

Contributor

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

Contributor

petertodd commented Nov 24, 2015

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

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 24, 2015

Member

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?

Member

laanwj commented Nov 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 24, 2015

Member

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!

Member

gmaxwell commented Nov 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Nov 24, 2015

Contributor

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)

Contributor

TheBlueMatt commented Nov 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 25, 2015

Member

@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)

Member

laanwj commented Nov 25, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Nov 25, 2015

Contributor

@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.

Contributor

petertodd commented Nov 25, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 26, 2015

Member

utACK.

Member

gmaxwell commented Nov 26, 2015

utACK.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 26, 2015

Member

@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
Member

laanwj commented Nov 26, 2015

@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

View changes

Show outdated Hide outdated src/torcontrol.cpp
// Now that we know Tor is running setup the proxy for onion addresses
// if -onion isn't set to something else.
if (GetArg("-onion", "") == "") {
bool proxyRandomize = GetBoolArg("-proxyrandomize", true);

This comment has been minimized.

@laanwj

laanwj Nov 26, 2015

Member

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.

@laanwj

laanwj Nov 26, 2015

Member

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.

This comment has been minimized.

@petertodd

petertodd Nov 26, 2015

Contributor

Fixed.

@petertodd

petertodd Nov 26, 2015

Contributor

Fixed.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 26, 2015

Member

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
    }
Member

laanwj commented Nov 26, 2015

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
    }
Connect to Tor hidden services by default
Adds 127.0.0.1:9050 for the .onion proxy if we can succesfully connect
to the control port.

Natural followup to creating hidden services automatically.
@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Nov 26, 2015

Contributor

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

Contributor

petertodd commented Nov 26, 2015

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

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 26, 2015

Member

Concept ACK

Member

sipa commented Nov 26, 2015

Concept ACK

@laanwj laanwj merged commit cde857f into bitcoin:master Nov 27, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Nov 27, 2015

Merge pull request #7090
cde857f Connect to Tor hidden services by default (Peter Todd)
@leif

This comment has been minimized.

Show comment
Hide comment
@leif

leif Nov 28, 2015

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.

leif commented Nov 28, 2015

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

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 28, 2015

Member
Member

sipa commented Nov 28, 2015

@paveljanik

This comment has been minimized.

Show comment
Hide comment
@paveljanik

paveljanik Nov 28, 2015

Contributor

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

Contributor

paveljanik commented Nov 28, 2015

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

@leif

This comment has been minimized.

Show comment
Hide comment
@leif

leif Nov 28, 2015

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?

leif commented Nov 28, 2015

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

This comment has been minimized.

Show comment
Hide comment
@paveljanik

paveljanik Nov 28, 2015

Contributor

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

Contributor

paveljanik commented Nov 28, 2015

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

@MarcoFalke

This comment has been minimized.

Show comment
Hide comment
@MarcoFalke

MarcoFalke Nov 28, 2015

Member

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

Member

MarcoFalke commented Nov 28, 2015

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

@tailsjoin

This comment has been minimized.

Show comment
Hide comment
@tailsjoin

tailsjoin Nov 29, 2015

Contributor

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?

Contributor

tailsjoin commented Nov 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 30, 2015

Member

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

listenonion=0 to disable any automatic tor behavior

Member

laanwj commented Nov 30, 2015

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

listenonion=0 to disable any automatic tor behavior

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment