2

I've built a tor (2.4.19) test environment. Clients build circuits and all seems to function properly. However, I noticed that while my entry and relay nodes communicate with the directory server using a one hop circuit (encrypted), the exit node appears to communicate directly to the dir port on the directory server. When communicating directly to the dir port using http. You are able to see, in the clear, enough information to enumerate my tor test environment.

All of the nodes are built within a Xen hypervisor, TestingTorNetwork set to 1 on all nodes.

Sort of crazy, but when I remove the "accept" policy on the exit and leave the "deny :" statement, it appears that one hop circuit is then used by the exit server to communicate with the directory server.

Update Since the initial submission of this issue I have done some further isolation based on Jen's observation. It appears that when there is an exit policy that "accepts" anything, even the default accept policy, I see a "use_begindir 0" in the log file. shown at the end of the line here:

Apr 30 13:43:28.000 [debug] void directory_initiate_command_rend(const char *, const tor_addr_t *, uint16_t, uint16_t, const char *, uint8_t, uint8_t, dir_indirection_t, const char *, const char *, size_t, time_t, const rend_data_t *)(): anonymized 0, use_begindir 0.

When I have an exit policy that "rejects" everything, I see a "use begindir 1" in the log file. shown at the end of the line here:

Apr 30 13:43:42.000 [debug] void directory_initiate_command_rend(const char *, const tor_addr_t *, uint16_t, uint16_t, const char *, uint8_t, uint8_t, dir_indirection_t, const char *, const char *, size_t, time_t, const rend_data_t *)(): anonymized 0, use_begindir 1.

When I see "use_begindir 0" the node connects to the directory unencrypted. When I see "use_begindir 1" the node connects to the directory encrypted using the one-hop circuit.

As Jens suggested, this seems similar to the behavior discussed in Trac Ticket 10849. I applied the patch referred to in ticket 10849 but that did resolve this issue.

Seems like it would be a big deal... If I'm not the only one seeing this. Thanks.

  • The trac entry #10849 might be relevant for you. Could you try to use the patch and recompile the software? Furthermore do you see any loglines that might be relevant? – Jens Kubieziel Apr 10 '14 at 15:04
  • Thanks, Jens for the suggestion. I've been sidetracked, but now will focus again on this. The trac entry does look relevant. – DevOps Apr 29 '14 at 12:44
  • Jens, I followed your suggestion, applying that patch, but unfortunately that did not address the issue that I'm seeing. I will look closer at the debug output, but on first glance nothing popped out as the culprit. Seems like this issue might be a big deal if others are able to reproduce it. – DevOps Apr 29 '14 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.