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:
- An exit relay is not properly configured and breaks usability
- 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 (220.127.116.11) 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).
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
MyFamilyrestrictions 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.
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
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:
- The relay's IP address or fingerprint. The fingerprint is a forty-character
hex string such as
- What kind of behavior did you see?
- Any additional information we'll need to reproduce the issue.