Incoming tor connections should use alternative port #8973

1. 
   laanwj commented at 10:40 am on October 19, 2016: member

   To be able to label incoming tor connections as different from normal localhost connections in e.g. getpeerinfo and the peers list in the GUI it’d be useful to have them connect on an alternative local-only port. Or even better, a UNIX socket.

   For manually set-up hidden services this would have to be configured manually and could add a hsport option or such. The external port would still appear as XXXXXXXXX.onion:8333, however internally it would redirect to a that port.

   In the case of torcontrol this would be easy to set up automatically. It could add a new (localhost) binding port automatically and this code would have to be changed:

   • https://github.com/bitcoin/bitcoin/blob/master/src/torcontrol.cpp#L441
   • https://github.com/bitcoin/bitcoin/blob/master/src/torcontrol.cpp#L477
2. laanwj added the label P2P on Oct 19, 2016
3. 
   laanwj commented at 9:22 am on March 5, 2017: member

   An interesting alternative to using an alternative port would be to have Tor HS connect on a UNIX socket. This avoids any risk of port collisions at all, and makes it just as easy to detect Tor connections. Tor apparantly supports this: https://trac.torproject.org/projects/tor/ticket/11485
4. 
   laanwj commented at 9:56 am on March 18, 2017: member

   Some information about using UNIX sockets with Tor (mostly for my own reference):

   • ControlPort on UNIX socket:

   0ControlPort PORT|unix:path|auto [flags]
   

   (looks like ControlSocket path can be used too, but I think this is equivalent to unix:path)

   • SOCKS through UNIX socket:

   0SocksPort [address:]port|unix:path|auto [flags] [isolation flags]
   

   • Hidden service that connects to UNIX socket:

   0HiddenServicePort 80 unix:/path/to/socket
   

   • Through ADD_ONION command:

   0ADD_ONION NEW:BEST Port=80,unix:/tmp/path/to/tor/socket
   

5. 
   practicalswift commented at 9:16 pm on June 21, 2020: contributor

   Concept ACK
6. 
   vasild commented at 1:33 pm on July 17, 2020: member

   Concept ACK

   Yes, unix sockets are preferred for local connections over TCP. However, I think it is better to implement both so that the users don’t lose the ability to run the Tor proxy on a different machine than Bitcoin Core (it could be just a different virtual machine on the same physical one). Also unix sockets are not supported on Windowz.

7. 
   jonatack commented at 1:41 pm on July 17, 2020: member

   Concept ACK
8. 
   vasild commented at 11:57 am on September 3, 2020: member

   Does it make sense to generalize this by extending the -bind option to allow the user to override GetBindAddress() on incoming connections like this:

   0-bind=<addr[=override_local_addr]>
   1     Bind to given address and always listen on it. Use [host]:port notation
   2     for IPv6. If =override_local_addr is supplied then incoming connections
   3     to addr will be treated as if they were made to override_local_addr.
   4     For example
   5     -bind=127.0.0.1:8444=pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion:8333
   6     would designate a bind to 127.0.0.1:8444 and consider that the peer actually connected to 
   7     pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion:8333 instead of
   8     127.0.0.1:8444.
   9     Can be specified multiple times.
   

   If the override is specified then in CConnman::AcceptConnection() we would use it instead of calling GetBindAddress().

   PS the line numbers in master have changed and the links in the OP probably should be: https://github.com/bitcoin/bitcoin/blob/d736a6eb1/src/torcontrol.cpp#L441 https://github.com/bitcoin/bitcoin/blob/d736a6eb1/src/torcontrol.cpp#L477

9. laanwj closed this on Oct 2, 2020

   ---

10. sidhujag referenced this in commit 9d14195e7b on Oct 4, 2020
11. DrahtBot locked this on Feb 15, 2022

Contributors
laanwj practicalswift vasild jonatack

Labels
P2P