Skip to content

GitLab

Last edited by Georg Koppen
Page history

Criteria for rejecting bad relays

As the Tor network is an open network where anybody can contribute to by setting up relays it might happen that operators either misconfigure those relays or are actively trying to harm our users. The bad-relays team is trying to catch those cases and this document explains what we do when we are detecting a bad relay and which criteria we are applying in the process of dealing with them.

Right now we are mainly concerned with two scenarios:

  1. An exit relay is not properly configured and breaks usability
  2. Relays trying to harm our users

Misconfigured exit relays

There is a range of issues that can make an exit relay being misconfigured:

  • DNS resolution is broken (totally or partially)
  • A DNS provider that censors its results is used (such as some OpenDNS or Quad (9.9.9.9) configurations)
  • The exit policy is not honored (i.e. there is a conflict between the announced policy and the actually possible destinations. Possible reasons: firewalling, downstream blocking on the network)
  • Any other criteria that would give a safe but not fully functional experience for Tor users

Once we get aware of any of those problems, be it through scanning or reports (see below for how to report issues), we first try to get into contact with the relay operator so they can fix the issue. That's the reason why it is important for us to have some way to reach operators, e.g. via the ContactInfo field. If that's not possible then we assign those exit nodes the BadExit flag which tells the Tor client they should not be used in an exit position anymore. We leave them in the network, however, as they are still useful for other purposes (e.g. middle or guard relays).

Malicious relays

We consider relays to be malicious if we find any of the following (potentially harmful) behaviors:

  • Lying about DNS resolution (DNS poisoning)
  • SSL stripping or doing other MitM attacks
  • Sniffing of user traffic
  • Running HSDirs that harvest and probe .onion addresses
  • Manipulating the DHT that is used for onion services, e.g., by positioning itself in the DHT.
  • Excessive logging (over notice) during normal operation, publishing traffic/destination/IP information, tampering with statistics
  • Evading MyFamily restrictions even though the operator is running more than one relay
  • Flooding the network with new relays (Sybil attacks)
  • Re-routing of exit traffic back into the Tor network (not actually exiting any traffic)
  • Any other behavior that would put users at risk

In contrast to the last section about misconfigured relays we don't contact operators of relays found with any of the above behaviors. Rather, we reject them from the network as fast as possible to keep our users safe. That means as well that we don't just assign the BadExit flag to exit nodes that got caught doing, say, SSL stripping attacks under the assumption that the relays could be usable for other purposes than exiting the network. We don't want to have relays in any position in the user's path if they got caught doing any attack.

Corner cases

When going over the list of malicious behavior above it is often straightforward to figure out when those cases apply to relays in question. But sometimes it is not. For instance, how do we know whether a group of relays is e.g. evading MyFamily restrictions contrary to merely being misconfigured? Maybe there is a new operator behind them who is just learning how to operate relays and is making mistakes but eager to adapt and contribute. It would be bad both for operator and likely for relay diversity if we kicked them out and moved on with our lives. On the other hand that would be the best course of action if we knew their intentions to be malicious.

Again, what helps us in those cases are ways to reach the operator, e.g. via a valid ContactInto field, and interact with them. Additionally, we have a couple of heuristics we apply based on past experiences with different relay groups and operators.

Reporting bad relays

If you detect relays with one of the above described issues or behaviors, please report them with a detailed description to our bad relays mailing list (bad-relays AT lists DOT torproject DOT org) including:

  1. The relay's IP address or fingerprint. The fingerprint is a forty-character hex string such as 203933ED4E55EF8A3C3518427D1A1ED6A4CC285E.
  2. What kind of behavior did you see?
  3. Any additional information we'll need to reproduce the issue.