[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