[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #993 [Tor Relay]: Add ExitPolicy by country



#993: Add ExitPolicy by country
--------------------------------+-------------------------------------------
 Reporter:  Zakhar              |         Type:  enhancement
   Status:  new                 |     Priority:  minor      
Milestone:  Tor: 0.2.3.x-final  |    Component:  Tor Relay  
  Version:  0.2.0.34            |   Resolution:  None       
 Keywords:                      |       Parent:             
--------------------------------+-------------------------------------------
Changes (by nickm):

  * milestone:  => Tor: 0.2.3.x-final


Old description:

> 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]

New description:

 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]

--

Comment:

 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/993#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs