Automatically create hidden service, listen on Tor

laanwj commented at 9:59 am on August 24, 2015: member

Starting with Tor version 0.2.7.1 it is possible, through Tor’s control socket API, to create and destroy ’ephemeral’ hidden services programmatically. https://stem.torproject.org/api/control.html#stem.control.Controller.create_ephemeral_hidden_service

This means that if Tor is running (and proper authorization is available), bitcoin could automatically create a hidden service to listen on, without user manual configuration. That would positively affect the number of available .onion nodes.

This would involve the following, if enabled:

When the node is started, connect to Tor through control socket
Send create_ephemeral_hidden_service command
First time:
- Make it create a hidden service key
- Save the key in the data directory for later usage (optional: Could also use a new key every time. Better for privacy, less so for having stable identifiers, so this should be configurable)
Make it redirect port 8333 to the local port 8333 (or whatever port we’re listening on). E.g.

0response = controller.create_ephemeral_hidden_service({8333: 8333}, key_type='NEW', key_content='BEST', await_publication = True)
1# Advertize <response.service_id>.onion
2# Optionally save response.private_key, response.private_key_type

Keep control socket connection open for as long node is running. The hidden service will (by default) automatically go away when the connection is closed.

Challenges:

Except for experimentation we probably don’t want to rely on a Python script. This means the create_ephemeral_hidden_service STEM interface has to be implemented in C++. Internal command is ADD_ONION, see https://gitweb.torproject.org/torspec.git/commit/?id=f5ff369 for the appropriate addition to torspec.

Edit: the controller.create_ephemeral_hidden_service will take a while (I suppose the reason is that it needs to generate a key) - maybe execute it in a thread and not in the main initialization. Edit.2: FYI the part that takes significant time is not the key generation, but waiting for publication await_publication = True.

laanwj added the label P2P on Aug 24, 2015

laanwj added the label Privacy on Aug 24, 2015

casey commented at 9:10 pm on August 25, 2015: contributor

This would still require some user configuration. Tor control ports can be unsecured (any local process can connect and issue commands), password protected, or protected with a cookie file (any process that can read the cookie file can connect and issue commands).

I’m going to try to implement the simplest case, connecting to an unsecured control port running on the default port. After that it’ll just be a matter of adding flags to handle more complicated configurations. (Non-default ports, password/cookie file protection, etc.)

casey commented at 4:52 am on August 26, 2015: contributor

I notice that boost::asio is only used in bitcoin-cli and the rpc server. Is this a conscious choice, meaning that I should avoid boost::asio for code which is destined for bitcoind?

laanwj commented at 6:28 am on August 26, 2015: member

@casey not necessarily. If you know the control port, generally 127.0.0.1:9051, you can send a “PROTOCOLINFO” command to find out what auth is expected and what cookie file. Tor Browser Bundle is set up using coookie authentication by default. Though I’d say the user does have at least to give an ‘OK’ to do this.

Only in the case of HashedPassword, credentials have to be manually configured.

I have a base implementation based on libevent (from #5677) here: https://github.com/laanwj/bitcoin/blob/2015_08_tor_hs/src/torcontrol.cpp It authenticates and requests the hidden service, ~~but does not actually integrate into bitcoin yet ;)~~

casey commented at 8:09 pm on August 26, 2015: contributor

Ahh, okay, I guess you’ve got it covered then. I’m assuming that the best thing to do in that case is to just wait until #5677 lands and then merge in your version.

laanwj commented at 11:02 am on August 31, 2015: member

See https://github.com/laanwj/bitcoin/tree/2015_08_tor_hs . Going to PR this soon, but I first want #5677 in due to libevent.

BTW @petertodd @isislovecruft any recommendations to check COOKIEFILE from PROTOCOLINFO? would it make sense to check that the cookie filename ends with control_auth_cookie? I’m mostly afraid of “hello, I’m listening on the control port and pretend to be Tor, hand me your wallet” kind of attacks.

isislovecruft commented at 10:43 pm on August 31, 2015: none

@laanwj Hmm… checking the filename might be a little klugey, since I would assume some locally installed malware that’s pretending to be Tor could might be capable of doing some workaround, e.g. symlinking evil_control_auth_cookie to wallet.dat, and then asking you to read it. You could use SAFECOOKIE authentication, and then you’d have the guarantee that whatever is listening is also able to read the contents of the cookie file. (The protocol for using SAFECOOKIE is described here.)

laanwj commented at 2:09 pm on September 4, 2015: member

Ah yes, I hadn’t thought about symlinks yet. Good point.

I’ll take a look at SAFECOOKIE.

laanwj commented at 4:41 pm on September 4, 2015: member

I had also missed this in my last read of the spec:

0  All authentication cookies are 32 bytes long.  Controllers MUST NOT
1  use the contents of a non-32-byte-long file as an authentication
2  cookie.

Restricting the cookie files to 32 byte files at least avoids passing the wallet. Sure, there may still be other 32 byte files worth pilfering, SAFECOOKIE is better.

laanwj commented at 3:23 pm on November 16, 2015: member

Solved by #6639

laanwj closed this on Nov 16, 2015

DrahtBot locked this on Sep 8, 2021

Automatically create hidden service, listen on Tor #6586