Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-15T23:33:09Zhttps://gitlab.torproject.org/legacy/trac/-/issues/18267Enable Exit Policy by Autonomous System Numbers2020-06-15T23:33:09ZnaifEnable Exit Policy by Autonomous System NumbersThis ticket is to improve Tor in a way to enable Exit Policy to be able to accommodate AS numbers, other than just IP addresses/netblocks and ports.
This requirements come up when measuring how to make a Tor Exit Relay that enable conne...This ticket is to improve Tor in a way to enable Exit Policy to be able to accommodate AS numbers, other than just IP addresses/netblocks and ports.
This requirements come up when measuring how to make a Tor Exit Relay that enable connections only to high traffic, but very likely not abuse-generating, websites of major internet destinations.
Assuming that i may wish to make a Tor Exit nodes only for those destinations where we know there's high traffic to be routed trough the Tor Network, but with a limited risks of ISP/Provider takedown due to those large corporations not being automatic-abuse-generating, i tried to collect the numbers of AS for each of the following:
Google (17 AS)
Facebook (1 AS)
Twitter (3 AS)
Microsoft (28 AS)
Yahoo (59 AS)
Wikipedia (3 AS)
Linkedin (9 AS)
Github (1 AS)
Cloudflare (5 AS)
The amount of netblocks part of those AS are a lot and i don't think they will fit the Exit Policy. When it has been tried to load the list of all Italian netblocks (like at #993), weird things happened and it basically didn't worked out.
If Tor servers and clients would become AS-aware, then it would be possible to run a Tor Exit node, deciding to refine an exit policy for very-limited-liability and very-limited-abuse-generating-setup that could probably make it easier to run Tor also on my home broadband line (not being abuse generating destinations, my home ISP won't cut me the subscription!).
That's something that could become a brick of a building block to reach a point where the end-user (Tor Browser users) maybe able to route some traffic out by default (ex: route only the top target AS destinatation that would dynamically enable to offload the "bulk-but-not-abuse-generating" network traffic)Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/14424Enhance policies (exit, reachableaddresses, etc) to support hostnames2020-06-13T14:42:10ZTracEnhance policies (exit, reachableaddresses, etc) to support hostnamesHello. First of all, amazing software! Thank you for this. I was wondering if there is a way to edit torrc to only connect to comcast, att, mit.edu etc..As you can edit the file to only connect to US servers, but I need it for specific I...Hello. First of all, amazing software! Thank you for this. I was wondering if there is a way to edit torrc to only connect to comcast, att, mit.edu etc..As you can edit the file to only connect to US servers, but I need it for specific ISP's. Thank you!
**Trac**:
**Username**: KyuskeTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/993Add ExitPolicy by country2020-06-13T14:54:08ZTracAdd ExitPolicy by countryReason: 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 htt...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**: ZakharTor: unspecified