Red bulbs aside

Analysis of DNS persistent error on Tor exit nodes

2020-Oct.-30

Introduction

Starting to develop a tor exit scanner, some exit errors were detected while testing the robustness of the scanner. Then these errors were manually confirmed as DNS error on the exit node level.

Applications using Tor should not perform DNS resolutions themselves, otherwise DNS resolvers would learn to which servers connections are being made [1][2]. It is therefore important that exit nodes provide reliable DNS resolution.

In this context, studying the rate and persistence of such errors on exit nodes sounds interesting. This small opportunistic analysis was lauched.

Protocol

The scanner has been written to use Onionoo to get a daily up-to-date list of the running exit nodes, to establish a circuit for testing each exit with Stem (the Python controller library for Tor) and to test it with URL and IP requests. The default target was https://check.torproject.org assuming that it should be reachable with any exit node. The test has been completed for all the exits on a daily basis during five days.

Results

Results shows a daily average of 3,50% errors that seems quite high at first sight. It represents 0.7875% of the total exit probability. If we dig a little bit, we found that errors are very temporary and are rarely repeated on the next day. So it can be a temporary network problem or a scanner artefact (false positive). Studing the error repetition give more information.

More than 75% of the relays presenting an error on one day will answer correctly on the next days. This rate keep increasing on the next days but relays with error on day 5 will mainly stay in error after that. This represents an exit probability of 0.18%.

Examining the relays with a 5-days error duration leads to listing :

• 10 relays with a manually confirmed DNS error and a specific error on the scanner,
• 4 relays were already flagged as “Bad Relay” (confirming our analysis),
• 4 relays with circuit establishment error but no DNS error. To be investigated.

Conclusion

The 10 relays have been reported to bad-relays@lists.torproject.org. As the affected exit probability is low and errors are frequently temporary, we suggest that such a scanner will be executed only with a weekly analysis. There is no need to run it more frequently. Then relays that will appeared in two consecutives analysis will be reported. Bad relays will be excluded from the next analysis.

Further work

• Setting up this automatic weekly scan (as suggested above). [Done here]
• The scanner could be pushed further to contribute to map DNS resolvers used by Tor exit nodes. Great work [3] has already been done by Nusenu on this subject.
• The scanner could also be used to test DNS censorship on the Tor network, to detect lying DNS resolvers but also SSL-striping or other bad behaviours.

Useful links and further readings

• [1] Tor: The Second-Generation Onion Router
• [2] Tor FAQ : I keep seeing these warnings about SOCKS and DNS and information leaks. Should I worry?
• [3] Who controls Tor's DNS traffic?
• Onionoo
• Stem
• Tor Issue Exit relay DNS cache leaks information

Special thanks

to Guinness who have taken time to read this before publication and share their opinion and advices !

Comment ?

Should you have any comment on this page, get in touch !