Add ExitPolicy by country

Reason: more and more country are voting laws to censor internet: browsing, P2P,... As browsing would probably be banned at your country's DNS level, there's not big risk of being charge of abuse, because if you serve as exit node to http://offending.site.com and this site is banned by your own country, your local DNS would direct you to somewhere else or give an error. The TOR Client would then get this wrong answer but the exit node would not be charged of anything. However, you could appear to be involved in illegal P2P. Even if TOR natively filters out well known P2P ports, anyone can set his P2P software to port 443, port 80,...

So being able to filter out by country (usually your own country) is important to prevent this kind of abuse.

That's because laws are applicable generally country by country. To check that you are actually doing P2P (as an exit node) governments have to simulate a P2P client and connect to you. This would most probably be done in your own country otherwise charges could easily be dismissed during a trial.

So banning your own country can be useful, and not too hard to implement, as it is already done with ExitNodes.

An alternative I tried: I blocked individual IP ranges. But unfortunately that doen't seem to work and has quite nasty side effects.

I tried it out taking FR (France) IP addresses as example. FR ranges of IP give around 19,7K ranges Feeding 19,7K lines of

ExitPolicy reject so.me.fr.ip/mask

result is:

• TOR consuming 100% CPU (on 1 CPU of a Dual core 2,4GHZ) for around 1 min at startup
• Vidalia doing same thing
• /var/log/tor/log contains at lot of messages: [warn] router_dump_router_to_string(): Bug: descriptor policy_write_item ran out of room! [warn] router_rebuild_descriptor(): Bug: Couldn't generate router descriptor.
• ps -aux | grep tor shows that the TOR process is at 98,8% memory (hence the previous "bug" messages I suppose)
• complained at startup about raising file handles (ulimit) to 32767 [this might be unrelated]

Quite clearly, feeding into TOR around 20K ranges of blocked IP wasn't a good idea, and wasn't in the architectural design of TOR. I do also guess TOR my advertise to other nodes what it is blocking (is it... I admit I didn't read all the protocol !) and blocking so many ranges could result in a lot of useless traffic. So obviously, the tricky part would be to make an evolution to the protocol just to tell other nodes your blocking (or allowing) on a specific country code.

Other altenative: TOR could also be blocking/allowing on a protocol (as Wireshark can do) and not on a ports, which is not very reliable. This could be more difficult as this type of code is not already in TOR. Depending on the level of the protocol you specify than could be quite tricky. (Isn't WireShark Open Source, could be an inspiration for coding such a feature).

Severity: I put medium, as if every TOR exit node is charged by it's own country's authority, there will be less exit nodes and this could lead to severe network congestion. (I did personnaly revert to entry-middlenode, and removed my accept *:80, *:443)

Summary:

• Feature 1:

ExitPolicy reject {fr}, allow {ca}

• Feature 2:

ExitPolicy allow [HTTP], reject [FTP]

(In fact WireShark recognises HTTP traffic but it you cannot set a capture filter on this criteria, so such a "high level" protocol could be difficult to track properly)

// Configuration: Ubuntu 8.10 - 64bits - TOR 0.2.0.34-1~intrepid from ppa.launchpad.net/e-stealth/ubuntu Vidalia 0.1.8 from same repository //

[Automatically added by flyspray2trac: Operating System: Other Linux]

Trac:
Username: Zakhar