May I do security inspection on exit relays?

Question

If I decide to run an exit relay may I run security inspection (Intrusion Prevention System, anti-spam, anti-malware etc.) on the traffic leaving the Tor network? Would this be considered legally and ethically correct? Can I let the Tor users know that there is such a security policy on the exit relay?

Answer 1

The short answer is: You shouldn't do it! Do not mess with user data.

A large portion of Tor users use it to stay anonymous and they would be very upset when someone messes with their traffic. It is quite hard to decide what spam, malware etc. from the perspective of each user is. So a general filter doesn't fit all your users.

If you want to let your users know you probably have to insert data in their traffic. So what happens when someone hacks into your machine and inserts malware itself?

Answer 2

To add to the other reasons of why this is a bad idea, there are also legal issues with monitoring or modifying traffic going through your exit node.

From the Tor legal FAQ:

Should I snoop on the plaintext traffic that exits through my Tor relay?

No. You may be technically capable of modifying the Tor source code or installing additional software to monitor or log plaintext that exits your relay. However, Tor relay operators in the United States can possibly create civil and even criminal liability for themselves under state or federal wiretap laws if they monitor, log, or disclose Tor users' communications, while non-U.S. operators may be subject to similar laws. Do not examine the contents of anyone's communications without first talking to a lawyer.

Also, malware researchers do use Tor to monitor malicious websites. If you remove malware you will be interfering with this research.

Answer 3

As Jens said, you shouldn't do it simply because it's not very nice; however, Tor also takes measures to penalize exit relays that do this sort of thing. Your relay will quickly get the BadExit flag. From the dir spec:

"BadExit" if the router is believed to be useless as an exit node (because its ISP censors it, because it is behind a restrictive proxy, or for some similar reason).

and won't be used as often when building circuits.

Answer 4

It's definitively considered a bad practice, for a number of reasons:

1. Possible legal repercussions (personally I doubt this holds up, unless you actively target for and process personally identifiable information).
2. The obvious privacy/ethical questions raised.
3. Tor does not like it and will penalize you if caught modifying exit data.

HOWEVER

1. Possible legal repercussions -- explanation: Atleast with respect to most european service providers in a consumer capacity, YOU are held legally accountable for the traffic leaving your network.
2. (European) Service providers are required by law to log traffic, it could be argued that you are legally a service provider (Hosting an exit node, you provide a service)
3. It IS your network.. and should be free to choose what to allow on and off your network. You should not MODIFY foreign tor data under any circumstance, but you can damn well decide to DROP a connection because it does not comply with YOUR policy or even local law, whether you come by this decision port based, protocol based, further inspected or otherwise -- net neutrality does not come in effect. Trying to decrypt further layers however is a different matter e.g. https or other ssl/tls enabled protocols.

So like others stated, most likely you SHOULD NOT but YOU CAN AND MAY and under certain conditions maybe even SHOULD. Also the tor RFC's specify you should not.

Personally I would security inspect, not because I'm a censoring sysop from hell(tm), but because there is certain traffic I do NOT want leaving my network(s) under any condition (virii, cnc traffic, spam, certain forms of porn the network is famous for), and because I believe in protocol enforcement as an effective defence (or attack) against malicious traffic and to ensure the quality of service on the internet as a whole (think software not adhering to rfc's). However I would also go out of my way to ensure these metadata is not stored or read by humans (except for perhaps policy violations).

It's a personal choice in the end, at least when it comes to filtering, with both pro's and (arguably more) con's depending on the situation. As for inline traffic modification or packet mangling, that's certainly a big NO (perhaps slight protocol adjustments excluded, which can actually result in better secured connections or anonymity). At least until this case ends up in court and a legal precedent is created.