[tor-bugs] #32115 [- Select a component]: Hidden Service in TestingTorNetwork connected to non-Exit Nodes

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Oct 16 16:35:56 UTC 2019


#32115: Hidden Service in TestingTorNetwork connected to non-Exit Nodes
---------------------+--------------------------------------
 Reporter:  lewis85  |          Owner:  (none)
     Type:  defect   |         Status:  new
 Priority:  Medium   |      Component:  - Select a component
  Version:           |       Severity:  Normal
 Keywords:           |  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
 0.4.1.6.
 Specifically, I have the following running machines:

  * 3 Authorities (named as !TorAuthoritity[01,02,03])


  * 3 Exit Relays (named as !TorRelay[01,02,03]Exit)


  * 3 non-Exit Relays (named as !TorRelay[04,05,06])


  * 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 at 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?

 Sincerely,
 lewis85

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32115>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list