Retrieving a list of connections to own hidden service
Hello, I am wondering if it is possible to retrieve, via tor-control, the list of connections the tor daemon has opened to a hidden service it manages. For example, an application connects to tor-control and issues: ADD_ONION NEW:BEST Port=8333,127.0.0.1:8333 Which creates a hidden service addrwhatever.onion. Later somebody connects to addrwhatever.onion:8333 and the tor daemon opens a TCP connection like 127.0.0.1:46153 -> 127.0.0.1:8333. Next, some other application (not the tor daemon) connects directly to 127.0.0.1:8333 and that is 127.0.0.1:52490 -> 127.0.0.1:8333. What if the application running at 127.0.0.1:8333 wants to distinguish incoming tor connections from the rest? From its point of view the connections from the example above are just TCP connections coming from 127.0.0.1:46153 and 127.0.0.1:52490. GETINFO stream-status comes close, but it only prints addrwhatever.onion:8333 which is not sufficient. Thanks! -- Vasil Dimov gro.DSBeerF@dv % A complex system that works is invariably found to have evolved from a simple system that works.
On Thu, 24 Sep 2020 at 13:33, Vasil Dimov <vd@freebsd.org> wrote:
Which creates a hidden service addrwhatever.onion. Later somebody connects to addrwhatever.onion:8333 and the tor daemon opens a TCP connection like 127.0.0.1:46153 -> 127.0.0.1:8333. Next, some other application (not the tor daemon) connects directly to 127.0.0.1:8333 and that is 127.0.0.1:52490 -> 127.0.0.1:8333.
What if the application running at 127.0.0.1:8333 wants to distinguish incoming tor connections from the rest? From its point of view the connections from the example above are just TCP connections coming from 127.0.0.1:46153 and 127.0.0.1:52490.
I describe a useful workaround for this issue by using virtual IP addresses, in this document but especially in this section: https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-productio... ...which also has the benefit of providing better auditability. - alec -- http://dropsafe.crypticide.com/aboutalecm
Date: Thu, 24 Sep 2020 12:46:13 +0200 From: Vasil Dimov <vd@freebsd.org>
Which creates a hidden service addrwhatever.onion. Later somebody connects to addrwhatever.onion:8333 and the tor daemon opens a TCP connection like 127.0.0.1:46153 -> 127.0.0.1:8333. Next, some other application (not the tor daemon) connects directly to 127.0.0.1:8333 and that is 127.0.0.1:52490 -> 127.0.0.1:8333.
What if the application running at 127.0.0.1:8333 wants to distinguish incoming tor connections from the rest? From its point of view the connections from the example above are just TCP connections coming from 127.0.0.1:46153 and 127.0.0.1:52490.
Can you just use two different sockets, one for connections via Tor and one for non-Tor connections? Then you won't have to go to the trouble of communicating with the tor daemon, worrying about race conditions, &c. You can use local sockets instead of IP sockets too -- just do: ADD_ONION <secretkey> Port:8333,unix:/var/service/torsocket to make the tor daemon connect to /var/service/torsocket instead of 127:0.0.1:8333. Then you can use ordinary file system permissions to control access to it so nobody other than the tor daemon can connect to that socket. This is the mechanism that my ucspi-onion tool uses: https://mumble.net/~campbell/hg/ucspi-onion
Alec, Taylor, Your replies imply that this is not possible. The use of different port or address, dedicated only for incoming tor, is some workaround, but it has the obvious downside that if somebody manages to reach it and connect outside of tor, then the target application will perceive it as an incoming tor connection. This is mitigated if using unix sockets at the cost of added complexity of managing filesystem permissions and only works on the same host and not on Windows. Some firewalls support maching by user, so one could setup a rule that only allows connections to the dedicated port from the tor user. Alec, incoming tor connections do not have a "from onion address". Thanks! -- Vasil Dimov gro.DSBeerF@dv % Everyone who has lived has died, but not everyone who has died has lived.
The use of different [address], dedicated only for incoming tor, is some workaround, but it has the obvious downside that if somebody manages to reach it and connect outside of tor, then the target application will perceive it as an incoming tor connection.
Hi Vasil! The rest of the document, at length, describes how to prevent someone reaching it and connecting from outside the machine which is running Tor. Unix sockets are also a very good solution. I use them in EOTK, for that reason, and also because it reduces the risk of a port-exhaustion attack. - alec -- http://dropsafe.crypticide.com/aboutalecm
participants (3)
-
Alec Muffett -
Taylor R Campbell -
Vasil Dimov