Opened 8 years ago

Closed 5 weeks ago

#993 closed enhancement (duplicate)

Add ExitPolicy by country

Reported by: Zakhar Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: 0.2.0.34
Severity: Normal Keywords: tor-relay
Cc: Zakhar, arma, nickm, karsten, Sebastian Actual Points:
Parent ID: #22340 Points:
Reviewer: Sponsor:

Description (last modified by nickm)

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]

Child Tickets

Change History (11)

comment:1 Changed 8 years ago by arma

Well, we're definitely not going to do feature 2 at this point, since it basically
amounts to illegal wiretapping of our users. See e.g.
https://www.torproject.org/eff/tor-legal-faq.html.en#ExitSnooping

Feature 1 is not a crazy idea though. I wonder how to do it in a backward-compatible
way.

comment:2 Changed 7 years ago by Sebastian

That would mean geoip lookups for every new connection, and also
quite a lot connections would be refused by the exit if exit and client
don't have the same geoip info... I also don't see how police/others
couldn't use an IP that appears to be outside of your jurisdiction to
"prove" that you're sharing files.

comment:3 Changed 7 years ago by nickm

  • Description modified (diff)
  • Milestone set to Tor: 0.2.3.x-final

This kind of thing really really needs a design proposal on or-dev. It's incompatible with the current exit policy format, so somebody would need to figure out how to implement it without bloating up descriptors (and microdescriptors) beyond the bounds of reason.

comment:4 Changed 6 years ago by Sebastian

Another user reporting this opened #2367.

comment:5 follow-up: Changed 6 years ago by privacyresearch

Hi all,

we tried to do the same.

In order to implement the feature of country without modifying the exitpolicy syntax in the descriptors we would think to use a tricks.

The "ExitPolicy" parameter require an IP address.

There are certain networks unroutable trough TOR (like 127/8 and multicast 224/8).

Why not assign 127.127.0.0/16 for a mapping of IP/COUNTRYCODE .

That way the user configuring torrc can write:
ExitPolicy reject IT # block italy

but this would translate in the descriptors like 127.127.10.10 (if CountryCode "IT" is assigned by a convention to 127.127.10.10).

That way within TOR ExitPolicy syntax we would reserve some classes for added ExitPolicy information, now to be used for "Country", but in future who know.

This would also don't break backward compatibility of descriptors.

comment:6 in reply to: ↑ 5 Changed 6 years ago by rransom

Replying to privacyresearch:

Why not assign 127.127.0.0/16 for a mapping of IP/COUNTRYCODE .

Because, as Sebastian pointed out above, quite a lot of connections will be rejected when an exit relay upgrades its geoip file and clients do not. Your idea would also result in many rejected connections from current Tor clients that do not understand that an exit node which claims to reject 127.127.10.10 will actually reject many real IP addresses.

comment:7 Changed 6 years ago by mikeperry

Well, if the streams get closed with reason EXITPOLICY, tor will retry silently, right? The impact on clients will be way more minimal than say an iptables setup for the same.

comment:8 Changed 6 years ago by nickm

  • Milestone changed from Tor: 0.2.3.x-final to Tor: unspecified

comment:9 Changed 5 years ago by nickm

  • Keywords tor-relay added

comment:10 Changed 5 years ago by nickm

  • Component changed from Tor Relay to Tor

comment:11 Changed 5 weeks ago by nickm

  • Cc changed from Zakhar,arma,nickm,karsten,Sebastian to Zakhar, arma, nickm, karsten, Sebastian
  • Parent ID set to #22340
  • Resolution changed from None to duplicate
  • Severity set to Normal
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.