Opened 12 months ago

Closed 12 months ago

Last modified 12 months ago

#32115 closed defect (not a bug)

Hidden Service in TestingTorNetwork connected to non-Exit Nodes

Reported by: lewis85 Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Hi folks,

I set up a testing environment made of lxd containers on Ubuntu 18.04. Each container is based on the Ubuntu 18.04 image and runs Tor version
Specifically, I have the following running machines:

  • 3 Authorities (named as TorAuthoritity[01,02,03])
  • 1 Hidden Service (named as TorHs01)
  • 1 Client (named as TorClient01)

The torrc file has the "TestingTorNetwork 1" configuration value.

Moreover, only the torrc of Exit Relays has the following configuration values:

ExitRelay 1 ExitPolicy accept *:*

whereas all the other torrc files (i.e., Authorities and non-Exit Relays) have the following configuration values:

ExitRelay 0 ExitPolicy reject *:*

All the Tor relays and hidden service are configured in order to use the three Authorities

However, I noticed that the Hidden Service is always connected to one or more non-Exit Relays whereas I expected to see only connections to Exit Relays.
For example, by running the command lsof -i on the container providing the Hidden Service, I get the following result:

root@TorHs01:~# lsof -i COMMAND   PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME systemd-n 180 systemd-network   14u  IPv4 128314      0t0  UDP TorHs01.lxd:bootpc systemd-r 182 systemd-resolve   12u  IPv4  52219      0t0  UDP localhost:domain systemd-r 182 systemd-resolve   13u  IPv4  52240      0t0  TCP localhost:domain (LISTEN) sshd      251            root    3u  IPv4  77216      0t0  TCP *:ssh (LISTEN) sshd      251            root    4u  IPv6  77314      0t0  TCP *:ssh (LISTEN) apache2   260            root    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) apache2   272        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) apache2   273        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) apache2   274        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) apache2   275        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) apache2   276        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) tor       396             tor    9u  IPv4 116948      0t0  TCP localhost:9050 (LISTEN) tor       396             tor   14u  IPv4 117902      0t0  TCP TorHs01.lxd:54948->TorAuthority03.lxd:5000 (ESTABLISHED) tor       396             tor   15u  IPv4 117904      0t0  TCP TorHs01.lxd:41538->TorRelay02Exit.lxd:5000 (ESTABLISHED)

where the last two lines represent connections to TorAuthority03 (which is configured as a non-Exit Relay) and TorRelay02Exit (which is configured as an Exit Relay) respectively.
Generally, the Hidden Service is always connected at least to a non-Exit Relay (e.g., TorRelay04, TorAuthority03, etc) whereas I expected that the Hidden Service was only connected to Exit Relays (in my lxd environment, TorRelay01Exit, TorRelay02Exit, TorRelay03Exit).
Looking at the network traffic through Wireshark, it looks like the Hidden Service is using a non-Exit Relay as an exit node, although the consensus already includes the three Exit Relays in my testing environment.
Is this behavior related to the testing environment only? If yes, do you already know why this happens? Is it possible to avoid this behavior?


Child Tickets

Change History (3)

comment:1 Changed 12 months ago by nickm

Component: - Select a componentCore Tor/Tor
Status: newneeds_information

Why do you expect a hidden service only to connect to exit relays? Exit relays are ones that allow connections outside the Tor network; they are not relevant for hidden services.

comment:2 Changed 12 months ago by dgoulet

Resolution: not a bug
Status: needs_informationclosed

Hidden services do _not_ connect specifically to Exit nodes. They stay inside the network.

They can use Exit nodes as a "Regular" node of the hidden service connection process. But there is no concept of "exiting the network" with an hidden service.

Also remember, tor client (which includes hidden service) will pick a Guard node and keep it for a while so you will always see the first connection to be the same node over and over again.

With TestingTorNetwork, many many timings are changed within tor to accelerate many interactions between tor nodes so it is not like the real public network where for instance you would keep your Guard for around 3 months.

comment:3 Changed 12 months ago by lewis85

Thank you very much for this clarification. I was errouneously referring to exit nodes as the nodes responsible to be the first hop for the hidden service in the circuit from the hidden service to the rendezvous point. As you mentioned, I should expect that the hidden service connects to the nodes flagged as "Guard" and this is what is happening in my testing environment.
I am sorry for the confusion, it was my mistake. Thank you very much for providing this clarification. It was very helpful.

Note: See TracTickets for help on using tickets.