Forgive my ignorance, I am new to tor and learning. On closer inspection, I find that bittorrent can run over the tor network, like any other traffic. Personally, I cannot afford complaints and spend time on legal issues; however groundless they may be it is not what I do.

It leaves me with a question: how do the Paramount people know that my server carried their stuff? Did they download it themselves, or do they have their own bittorrent servers? They must be at either end, or am I mistaken?

Another thing is filtering on bittorrent. The tor site suggests a filter: https://trac.torproject.org/projects/tor/wiki/BlockingBittorrent

Looking at it, I find it slightly flawed, because of the port numbers. Instead of using this: wget -qO- http://www.trackon.org/api/all | awk -F/ ' { print $3 }'

I would use: wget -qO- http://www.trackon.org/api/all | awk -F: '{ print $2 }' | awk -F/ ' { print $3 }'

It would explain why only most bittorrent traffic is blocked. Can anybody confirm this? I don't want to be the newbie messing up someone else's wiki.

- Bartels

On 04/09/2013 11:21 AM, bartels wrote:

Hello Mo,

Thanks for answering. My question was not really clear, but the issue is resolved anyway. The server was hacked and is re-installed. So, nothing to do with tor; the exit relay is up and running again.

• Bartels

On 04/09/2013 10:21 AM, Moritz Bartl wrote:

...

Hi,

Most countries have liability exemptions for passing traffic. There is no legal obligation to shut down or anything.

See also https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines .

What is your question exactly?

--Mo

On 08.04.2013 18:28, bartels wrote:

...

Hi People,

Two days ago I opened two fast tor exit relays v2.3 on debian wheezy. Now I get complaints from paramount that I have unwittingly distributed Hansel and Gretel via BitTorrent

<Port>39585</Port> <Type>BitTorrent</Type>

Can this be linked to tor, or is that impossible? I don't want to shut down tor for no reason.

• Bartels.

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

On Tuesday, April 9, 2013 12:04pm, "bartels" bartels@mailme.ath.cx said:

Forgive my ignorance, I am new to tor and learning. On closer inspection, I find that bittorrent can run over the tor network, like any other traffic. Personally, I cannot afford complaints and spend time on legal issues; however groundless they may be it is not what I do.

Just make life easy for yourself and use the Reduced Exit Policy:

https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy

To use, just paste these lines into your torrc file.

On Tue, 09 Apr 2013 18:33:26 +0200 bartels bartels@mailme.ath.cx allegedly wrote:

On 04/09/2013 06:24 PM, Steve Snyder wrote:

...

Just make life easy for yourself and use the Reduced Exit Policy:

https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy

Good advice. Had not seen that.

Must say it is a pretty loose list. I do not see the point in accessing a squid proxy server over tor. It sort of defeats the purpose.

Or if you really feel you /must/ run an exit at this stage, try limiting yourself to just http and https.

ExitPolicy accept *:80 ExitPolicy accept *:443 ExitPolicy reject *.*

Though personally I'm with Romanov here. Just relay with no exit until you have a better feel for tor.

Mick

---------------------------------------------------------------------

blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312

---------------------------------------------------------------------

On Tue, 9 Apr 2013 18:01:40 +0100 mick mbm@rlogin.net allegedly wrote:

Though personally I'm with Romanov here.

Correction. "Roman" (forgive me Roman).

Mick

---------------------------------------------------------------------

blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312

---------------------------------------------------------------------

On Tue, 9 Apr 2013 12:50:09 -0400 krishna e bera keb@cyblings.on.ca wrote:

So at the risk of being labelled a BadExit (or at best a non-net-neutral exit) i blocked all of ThePirateBay's ip addresses from my exit node for a while.

I assume you mean firewall-based blocking? You could have simply rejected those IPs via ExitPolicy (see "man tor"). That's a clear-cut way to tell the network you don't accept connections to those IPs, and no risk of being labeled a BadExit.

On 09/04/13 20:46, krishna e bera wrote:

On Tue, 9 Apr 2013 22:59:06 +0600 Roman Mamedov rm@romanrm.ru wrote:

...

On Tue, 9 Apr 2013 12:50:09 -0400 krishna e bera keb@cyblings.on.ca wrote:

...

So at the risk of being labelled a BadExit (or at best a non-net-neutral exit) i blocked all of ThePirateBay's ip addresses from my exit node for a while.

I assume you mean firewall-based blocking? You could have simply rejected those IPs via ExitPolicy (see "man tor"). That's a clear-cut way to tell the network you don't accept connections to those IPs, and no risk of being labeled a BadExit.

The latter. I dont know if it complicates routing decisions in the Tor network to have lots of ip address exceptions at the exits...

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

It possibly does slightly but we are talking about the sort of "complication" that a modern CPU can resolve in timescales short enough I doubt it would make that much difference especially if hash tables were used if ipset match can handle hash table lookups containing over 20,000 CIDR ranges while processing 75,000 packets per second I suspect tor could easily be made to efficiently use a similar mechanism, if it doesn't already in order to perform the lookups to compute the answer to "What is the subset of exit nodes allowing exit to IP addr X on port Y?" to come close to the same volume of lookups as the above setup with just over 1k exit nodes the client would need to be building 70+ circuits per second assuming a separate lookup table was used for every node, two factors make me think it's unlikely to go anywhere near this load and if it did that it would only be for brief periods of time as opposed to constant as in the former example, those being that I don't see many exit nodes ever having policies 20k entries long and I can't see that many clients needing to connect to 70+ IP address per second at least not on any continual basis perhaps short bursts (Opening a browser and restoring a few dozen tabs at once or something similar).

Bittorrent may be an exception to the above but the performance cost would be at the clients end and for one bittorrent is hardly a realtime protocol a little delay making each connection would not make much difference, two it performs poorly if you insist on running it over tor anyway and thirdly the average consumer desktop system is not exactly lacking spare CPU cycles due to the bursty nature of their workloads they statistically tend to spend the majority of their time idling.

Maybe someone can correct me if I missed something glaringly obvious but I certainly don't think anyone should be reluctant to add any exit policy entries they deem necessary at least not for this reason.

On 12/04/13 15:03, Moritz Bartl wrote:

On 12.04.2013 13:33, Matt Joyce wrote:

...

...

...

I assume you mean firewall-based blocking? You could have simply rejected those IPs via ExitPolicy (see "man tor"). That's a clear-cut way to tell the network you don't accept connections to those IPs, and no risk of being labeled a BadExit.

The latter. I dont know if it complicates routing decisions in the Tor network to have lots of ip address exceptions at the exits...

It possibly does slightly but we are talking about the sort of "complication" that a modern CPU can resolve in timescales short enough I doubt it would make that much difference especially if hash tables were used

That's not the issue here. You don't want to make the "routing table" (consensus and descriptors) that every Tor client needs to have too large. Users in developing countries, on mobile connections or generally instable connections already have issues.

It would help a lot if we used versioning and stopped sending almost unchanged data constantly and instead only providing the changes they are after all text files and there is a whole range of open source projects out there with the functionality to manage versioning and incremental updates for text files, the tradeoff of course would be in the slightly increased disk space requirements for dirmirriors.

That said I'm not arguing that we *should* do this merely that it is possible and there are technical options to accommodate it if it were required by enough of the community to pose a potential issue. Basically my point is that the it's possible the question therefore more one of whether we should, I don't particularly see the need and there are arguments against it I don't like censorship at the best of times which is why I run the exits I have I am just countering the technical arguments which I believe are potentially solvable if there was consensus that it is warranted and therefore are not good reasons to dismiss the idea.

As for the unstable connections issue, yeah that I can understand that said tor uses TCP only and TCP is *known* to perform at less than optimum in the event of unstable connections with random drops, it will get the data there but it will also do it very slowly interpreting dropped packets as congestion. Radio communications frequently cause TCP to have problems which is why the FAQ for almost any high bandwidth TCP application will invariably suggest things like "Use a hardwired connection if possible not wireless". I'm not dismissing it as an issue of course but no TCP application is going to work well if the underlying network infrastructure is poor and I am not sure how that is going to be solved without A) Replacing TCP with something else (But what?) or B) Major investment in those networks which is unfortunately unlikely until there is a large enough user base to create the demand to make someone with capital actually pay the slightest bit of attention because they generally are only interested when they can generate a profit.

On 12/04/13 22:54, Moritz Bartl wrote:

On 12.04.2013 19:16, Matt Joyce wrote:

...

It would help a lot if we used versioning and stopped sending almost unchanged data constantly and instead only providing the changes

I doubt that this is easy to do in a privacy-preserving way. You don't want to be able to discriminate relays based on what diffs/what amount of data they pull, right?

That could be a valid point I hadn't considered that but yes in theory if a node used only one dir mirror or a collection of dir mirrors that all co-operated you could gain profiling info based on which version they claim to have etc.

Bittorrent may be an exception to the above but the performance cost would be at the clients end and for one bittorrent is hardly a realtime protocol a little delay making each connection would not make much difference, two it performs poorly if you insist on running it over tor anyway and thirdly the average consumer desktop system is not exactly lacking spare CPU cycles due to the bursty nature of their workloads they statistically tend to spend the majority of their time idling.

As opposed to torrenting via exits, I'm amazed more people haven't moved their torrenting to operate entirely within anonymous networks. The performance of I2P and Tor (and I guess Phantom during tests) is actually quite usable so long as the user excercises content selection and patience. And regarding this thread, the freedom of operators and users from complaints regarding takedown would be invaluable. I'm not sure if these networks could scale to handle the node count and chatter, but I think the bit about spare cycles is right and might even act as a natural limiter to that sort of traffic. For instance, my tests show that establishing connections to many onions in parallel is quite costly and prone to failure without available headroom. But once connected, things are ok. Perhaps torrenters simply can't put aside their 'must download it all right now' mentality which keeps them away from our nodes. Or there is a major influx waiting to happen upon some future enlightenment whether they're misguided or not.

On 04/10/2013 12:35 PM, Moritz Bartl wrote:

Spending time on "legal issues" is part of the job of an exit operator. Sorry.

Thanks for educating me.

As a C programmer, I can probably contribute in other ways.

- bartels

On Wednesday, April 10, 2013 3:42pm, "Jorge-Leon" jorge-tor@magma.com.ni said: [snip]

Oh! I too use the filter as in "BlockingBittorrent".

I did not want to restrict my relay to the "ReducedExitPolicy". Almost all complaints were Bittorrent related. So I hoped "BlockingBittorent" would be the right ting to do.

• should the "BlockingBittorrent" recipe be changed in a way, that it

changes the exit policy of the relay instead of the firewall?

• How to block torrents from ThePirateBay anyway?

• Is there a way to block any bittorrent traffic?

I would advise, again, just to use the Reduced Exit Policy. I never get DCMA/copyright complaints. Most of the complaints I get are due to morons port-scanning through Tor, or from webmail spamming.

On 10.04.2013 23:42, theo@caber.nl wrote:

It sounds very handy to use the Reduced Exit Policy. But if we _all_ do that there will be too little exits for users who want to connect to 'strainge' ports. That way they get less anonyimity because they can't choose from hundreds of exits. In general it is best practice to block/reduce as little traffic as possible. Than we can guarantee enough diversity for everyone, even those people using exotic applications/protocols.

I totally agree. That's why our relays allow every port except 25. But, in the event that DMCA complaints scare away the ISP (or the exit operator), they should go for the reduced exit policy (and look for a better ISP), instead of randomly dropping packets or otherwise filtering traffic, which is just mean (and probably illegal).

On 11.04.2013 11:56, bartels wrote:

...

I totally agree. That's why our relays allow every port except 25. But, in the event that DMCA complaints scare away the ISP (or the exit operator), they should go for the reduced exit policy (and look for a better ISP), instead of randomly dropping packets or otherwise filtering traffic, which is just mean (and probably illegal).

Illegal? Why would it be illegal? Or mean?

Mean: Tor specifically has the exit policy to be able to select an exit that allows that outgoing connection. If an exit relay then drops that connection silently, Tor (and the user) cannot know it needs to select a different exit. The connections simply fail. That is totally mean.

What you do with that iptables rule (or similar rules) is block a bunch of URLs. Even worse: If I control your DNS server, I can make you block random sites. In general, you are censoring the user, and following the argumentation of mig media monopolies: "everyting on PirateBay must be illegal", or, worse, "everything using the Bittorrent protocol must be illegal". The Bittorrent protocol is in fact a very efficient and good protocol to spread information.

Illegal: As an exit operator, you should know about the relevant laws that protect you from liability. I've started a list, and many other added the ones they think might be relevant in their country (thanks!), at https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines -- a document every Tor exit operator should read.

Let me quote the full paragraph DMCA 512(a) here, then you should understand why interference with connections might not be a good idea from a legal standpoint. As far as I am aware, other ("western") countries have similar provisions.

(a) Transitory Digital Network Communications.— A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the provider’s transmitting, routing, or providing connections for, material through a system or network controlled or operated by or for the service provider, or by reason of the intermediate and transient storage of that material in the course of such transmitting, routing, or providing connections, if— (1) the transmission of the material was initiated by or at the direction of a person other than the service provider; (2) the transmission, routing, provision of connections, or storage is carried out through an automatic technical process without selection of the material by the service provider; (3) the service provider does not select the recipients of the material except as an automatic response to the request of another person; (4) no copy of the material made by the service provider in the course of such intermediate or transient storage is maintained on the system or network in a manner ordinarily accessible to anyone other than anticipated recipients, and no such copy is maintained on the system or network in a manner ordinarily accessible to such anticipated recipients for a longer period than is reasonably necessary for the transmission, routing, or provision of connections; and (5) the material is transmitted through the system or network without modification of its content.

http://www.law.cornell.edu/uscode/text/17/512

I can see some drawbacks, sure, but what seems to happen now is that each exit relay makes up their own mind about what is the way to go.

In a perfect world we would still need Tor, but it would automatically assign a BadExit flag to any exit that censors. I will suggest to add such a check specifically for Bittorrent trackers to the next generation of exit scanners.

If you don't want to allow Bittorrent tracker connections (again, this does NOT block the actual Bittorrent transfers, and is useless for torrenting via DHT!), do it via Exit Policy.

On 11.04.2013 22:17, bartels wrote:

I don't see the legal issue, though. Maybe it is there, but I don't see how rejecting sites via Exit Policy ;) would trigger any one of (1) through (5).

Yes, rejecting via exit policy should not, but direct filtering/tampering via iptables might.

On 12.04.2013 11:00, bartels wrote:

...

...

I don't see the legal issue, though. Maybe it is there, but I don't see how rejecting sites via Exit Policy ;) would trigger any one of (1) through (5).

Yes, rejecting via exit policy should not, but direct filtering/tampering via iptables might.

How do you figure that? Where's the legal difference?

(2) the transmission, routing, provision of connections, or storage is carried out through an automatic technical process without selection of the material by the service provider

(5) the material is transmitted through the system or network without modification of its content.

One could argue that dropping packets is "modification of content", as well as "selection of material". By specifying an exit policy, you don't get to see the data in the first place, so no modification or selection happens.

On 04/12/2013 11:35 AM, Troy Arnold wrote:

On Fri, Apr 12, 2013 at 11:00:42AM +0200, bartels wrote:

...

On 04/12/2013 10:06 AM, Moritz Bartl wrote:

...

On 11.04.2013 22:17, bartels wrote:

...

I don't see the legal issue, though. Maybe it is there, but I don't see how rejecting sites via Exit Policy ;) would trigger any one of (1) through (5).

Yes, rejecting via exit policy should not, but direct filtering/tampering via iptables might.

How do you figure that? Where's the legal difference?

Rejecting via exit policy means that those packets/traffic never reach your relay because the rest of the network won't select your relay as part of the circuit.

Rejecting via iptables means those packets reach your machine but never leave. Therefor, you are making a judgement about which traffic is abusive or illegal. In some jurisdictions this has, by some twisted logic, been interpreted to mean that the operator is giving tacit approval for anything that has not been rejected.

This is even more clear-cut if you are rejecting specific hosts rather than all traffic on a given set of ports.

I find Klingon easier to understand than the perverse logic of lawyers. But there is no arguing with jurisdiction.

So, how can isps get away with blocking port 25? Just curious. And/or offering a deliberately corrupted dns?

It really is spelled out in the doc that Moritz linked: https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines

Okay.

In any case it *is* mean to tell the network that you'll relay certain traffic but then in fact not pass it on. Nobody likes a liar :)

Apparently, I gave the impression that I am in favor of exit relays rejecting or dropping packets. I am not. Exit policy, or any other tor policy is good.

My only concern is abuse and the best way to deal with it.

Thank for the feedback.

- bartels

Moritz Bartl schreef op 2013-04-11 09:48:

On 10.04.2013 23:42, theo@caber.nl wrote:

...

It sounds very handy to use the Reduced Exit Policy. But if we _all_ do that there will be too little exits for users who want to connect to 'strainge' ports. That way they get less anonyimity because they can't choose from hundreds of exits. In general it is best practice to block/reduce as little traffic as possible. Than we can guarantee enough diversity for everyone, even those people using exotic applications/protocols.

I totally agree. That's why our relays allow every port except 25. But, in the event that DMCA complaints scare away the ISP (or the exit operator), they should go for the reduced exit policy (and look for a better ISP), instead of randomly dropping packets or otherwise filtering traffic, which is just mean (and probably illegal).

Ok. I can also agree with that it is unwanted to drop 'random' packages. But if it is sufficient to stop the Bittorrent complaints I myself would prefer that above setting the Reduced Exit Policy.

I am not an expert on the legal part of the packet dropping - I don't think you can get any RL trouble by it. But it is true that if we block certain sites/IP-addresses we don't have an excuse anymore why we did/will not do the same for some other 'unwanted' sites.

If we want to avoid the packet-dropping problem: We could also reject the IP-addresses of those sites with torrc. What is your opinion about that Moritz? And, would it ok for the authorities and users with little bandwith if I reject ~100 ip-adresses? (Not that I am going to)

On 11/04/13 20:00, Moritz Bartl wrote:

On 11.04.2013 12:15, theo@caber.nl wrote:

...

If we want to avoid the packet-dropping problem: We could also reject the IP-addresses of those sites with torrc. What is your opinion about that Moritz? And, would it ok for the authorities and users with little bandwith if I reject ~100 ip-adresses? (Not that I am going to)

Apart from the last section of my answer to bartels: Yes, listing 100+ IPs in the exit policy is not very nice for the Tor network either. :(

I guess the simple answer would be:

1. Allow everything (except port 25, which is reasonable to block)
2. If you don't want the DMCA spam notices, use the reduced exit policy.

It's not ideal if everyone does it however that's primarily due to the distribution mechanism, for now it is sending the *entire* file every time over HTTP there are however ways this could be distributed better if the community of exit operators were to decide such was necessary and the size of the descriptors thus began to increase such as versioning and distributing diffs to clients a conversation along the lines of:

Client: Request descriptor for relay with $FINGERPRINT have revision X. DirMirror: Descriptor for relay $FINGERPRINT diff revision X current revision Y data follows.

This would increase the necessary storage space on each mirror a little using a storage system like git, hg or svn use code from these could probably be reused, or even just use hg as a dependency and make a local repo with no daemon but unless everyone is changing their descriptors in major ways on a regular basis I suspect it would be quite small especially if older copies were expired after a reasonable period of time maybe 30 days and clients with older versions are just sent the full current version so only clients that use the network very infrequently would be actually downloading the entire policy. We are talking plain text files here too so I cant see the storage issue being a massive one given that HDD space is inexpensive now and even inexpensive VPS servers typically offer hundreds of GB of it, the main issue would be bandwidth which honestly I suspect would be lower or at worst similar if we only distributed diffs to the majority of clients.

On 13.04.2013 09:05, Jorge-Leon wrote:

...

1. Allow everything (except port 25, which is reasonable to block)
2. If you don't want the DMCA spam notices, use the reduced exit policy.

Please expand on "except port 25, which is reasonable to block", or point me to an explanation.

In short: We had port 25 (SMTP) open for a while, which results in a lot of spam directly sent to mailservers across the globe, which then immediately will get your IP blacklisted at a lot of DNSBLs. Many ISPs don't like their own ranges to contain blacklisted IPs, because that results in lower overall "reputation scores", and sometimes blacklistings are extended to a whole range of IPs, which then affects other customers.