Hi,
I am running a number of Tor relays, in my own DC and at Amazon Singapore.
I got an email from Amazon last week, for the Windows instance:
== Hello,
It's come to our attention that one of your EC2 instances may be configured as a Tor exit node. Please note that any open proxy activity is prohibited in our AUP:
Please respond to this email detailing the corrective measures you plan to take. If you believe our findings to be in error, please provide additional information about how this activity relates to your use case.
Regards, Amazon EC2 Abuse Team
==
Since Tor Cloud https://cloud.torproject.org/ suggests running on Amazon EC2, I am confused.
On 28.10.2013 22:10, Sanjeev Gupta wrote:
Since Tor Cloud https://cloud.torproject.org/ suggests running on Amazon EC2, I am confused.
Tor Cloud images are configured to act as bridges. You can run non-exit relays on Amazon EC2, but the cost are comparatively expensive. As you've found out, Amazon does not allow exit relays.
If you want to run low-cost relays, I suggest you browse through the offers at lowendbox.com. If you're up for running an exit (read the Exit Guidelines first [1]), contact the ISP(s) if they're okay with that.
--Moritz
[1] https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines
Is there confusion between using the special version of Tor designed to be a bridge on Amazon's EC² which uses a limited volume of data so to stay within the free offer for the free year Amazon offers?
-----Original Message----- From: moritz@torservers.net Sent: Mon, 28 Oct 2013 23:17:15 -0700 To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Amazon abuse report
On 28.10.2013 22:10, Sanjeev Gupta wrote:
Since Tor Cloud https://cloud.torproject.org/ suggests running on Amazon EC2, I am confused.
Tor Cloud images are configured to act as bridges. You can run non-exit relays on Amazon EC2, but the cost are comparatively expensive. As you've found out, Amazon does not allow exit relays.
If you want to run low-cost relays, I suggest you browse through the offers at lowendbox.com. If you're up for running an exit (read the Exit Guidelines first [1]), contact the ISP(s) if they're okay with that.
--Moritz
[1] https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth
On Tue, Oct 29, 2013 at 7:49 PM, I beatthebastards@inbox.com wrote:
Is there confusion between using the special version of Tor designed to be a bridge on Amazon's EC² which uses a limited volume of data so to stay within the free offer for the free year Amazon offers?
Yes, to some extent. I edited the config, as I was willing to pay for the extra bandwidth, and enabled an Exit Relay.
I was under the impression that this was permitted.
On 29 October 2013 22:53, Sanjeev Gupta ghane0@gmail.com wrote:
Yes, to some extent. I edited the config, as I was willing to pay for the extra bandwidth, and enabled an Exit Relay.
I was under the impression that this was permitted.
Amazon does not like Exit Nodes running in EC2. I'm not sure if there was a specific reason bridge vs relay was chosen, but I do know that exit nodes weren't an option.
You can fight them on it, but you'll probably lose. Or you can switch them back to bridges or to relays, and tell them you've removed the exit node.
-tom
On Wednesday 30 Oct 2013 08:43:21 Tom Ritter wrote:
On 29 October 2013 22:53, Sanjeev Gupta ghane0@gmail.com wrote:
Yes, to some extent. I edited the config, as I was willing to pay for the extra bandwidth, and enabled an Exit Relay.
I was under the impression that this was permitted.
Amazon does not like Exit Nodes running in EC2. I'm not sure if there was a specific reason bridge vs relay was chosen, but I do know that exit nodes weren't an option.
You can fight them on it, but you'll probably lose. Or you can switch them back to bridges or to relays, and tell them you've removed the exit node.
-tom _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
This is something which has always confused/annoyed me. How can a Tor node (unless it's exposing its SOCKS interface to the whole world) be classed as an "open proxy"?
Yes, Exit Relays exit to the clear Internet but they're not exactly open to clients for connection (unless specifically configured that way).
On Thu, 31 Oct 2013 10:43:41 +0000, Paritesh Boyeyoko wrote: ...
This is something which has always confused/annoyed me. How can a Tor node (unless it's exposing its SOCKS interface to the whole world) be classed as an "open proxy"?
The 'open proxy' is simply a tag on the IP address; it does not say that the openness actually exists at that address.
Yes, Exit Relays exit to the clear Internet but they're not exactly open to clients for connection (unless specifically configured that way).
Oh, but they are. Anybody with a tor client can use them, and if only a single tor client is run with its socks port exposed then all of the exit relays become 'open proxies' more along your definition.
Andreas
On Thursday 31 Oct 2013 15:34:20 Andreas Krey wrote:
On Thu, 31 Oct 2013 10:43:41 +0000, Paritesh Boyeyoko wrote: ...
This is something which has always confused/annoyed me. How can a Tor node (unless it's exposing its SOCKS interface to the whole world) be classed as an "open proxy"?
The 'open proxy' is simply a tag on the IP address; it does not say that the openness actually exists at that address.
Yes, Exit Relays exit to the clear Internet but they're not exactly open to clients for connection (unless specifically configured that way).
Oh, but they are. Anybody with a tor client can use them, and if only a single tor client is run with its socks port exposed then all of the exit relays become 'open proxies' more along your definition.
Andreas
Hi Andreas --
Thanks for the clarification, and yes in that regard Exit Nodes are open; I suppose I considered "open" to refer to the clear Internet.
On a related note, just out of interest why was the decision taken that the default exit policy for an out-of-the-box relay allows any exits at all?
Considering that
a) the majority of people running Tor would be TBB users (and therefore clients) and
b) running exits can lead to unwanted grief
I would have thought that the default exit policy would be reject *:* for (can't think of a better word) "safety" reasons. If someone wants to run an exit, it is then a deliberate action on their part, as opposed to a default setting.
Thoughts?
On Fri, Nov 01, 2013 at 12:53:48AM +0000, Paritesh Boyeyoko wrote:
On a related note, just out of interest why was the decision taken that the default exit policy for an out-of-the-box relay allows any exits at all?
Out of the box, relays don't allow exit at all.
A relay admin has to explicitly choose to run an exit relay, and should be aware of what that might mean for ISP policy compliance.
Considering that
a) the majority of people running Tor would be TBB users (and therefore clients) and
Clients aren't running relays at all. TBB and similar client installs are non-relay.
b) running exits can lead to unwanted grief
I would have thought that the default exit policy would be reject *:* for
That's correct, the default is reject *.
(can't think of a better word) "safety" reasons. If someone wants to run an exit, it is then a deliberate action on their part, as opposed to a default setting.
That's correct, it takes a deliberate action on the part of the administrator to become a relay; and another deliberate action to become an exit relay.
-andy
On Thu, Oct 31, 2013 at 06:12:47PM -0700, Andy Isaacson wrote:
That's correct, it takes a deliberate action on the part of the administrator to become a relay; and another deliberate action to become an exit relay.
Actually, that second part isn't true. Once you decide to become a relay, the default is to exit to most popular ports.
(If you're using Vidalia to configure your relay, it makes you choose whether you want to be a non-exit relay or an exit relay. But just Tor by itself, the default exit policy is in the man page.)
The main reason for this choice is the number of people who've told us that they are only able to run exit relays because "it's what Tor does when you run a relay", and their institution wouldn't let them do it if it required a manual config change to become an exit.
Then again, that was a long time ago, and maybe it's gotten harder to sustain exits these days?
--Roger
On Thu, Oct 31, 2013 at 09:52:41PM -0400, Roger Dingledine wrote:
On Thu, Oct 31, 2013 at 06:12:47PM -0700, Andy Isaacson wrote:
That's correct, it takes a deliberate action on the part of the administrator to become a relay; and another deliberate action to become an exit relay.
Actually, that second part isn't true. Once you decide to become a relay, the default is to exit to most popular ports.
Whoops, thanks for the correction Roger. I guess I've been configuring exit relays for so long that I forget what it's like to configure a non-exit. :)
(If you're using Vidalia to configure your relay, it makes you choose whether you want to be a non-exit relay or an exit relay. But just Tor by itself, the default exit policy is in the man page.)
The Vidalia behavior you describe seems like a principle of least surprise to me.
The main reason for this choice is the number of people who've told us that they are only able to run exit relays because "it's what Tor does when you run a relay", and their institution wouldn't let them do it if it required a manual config change to become an exit.
Then again, that was a long time ago, and maybe it's gotten harder to sustain exits these days?
I can easily imagine that folks who get their first warning from their ISP simply say "well, guess I can't run Tor at all then" and turn it off.
-andy
On Thursday 31 October 2013 19:14:47 Andy Isaacson wrote:
On Thu, Oct 31, 2013 at 09:52:41PM -0400, Roger Dingledine wrote:
On Thu, Oct 31, 2013 at 06:12:47PM -0700, Andy Isaacson wrote:
That's correct, it takes a deliberate action on the part of the administrator to become a relay; and another deliberate action to become an exit relay.
Actually, that second part isn't true. Once you decide to become a relay, the default is to exit to most popular ports.
Whoops, thanks for the correction Roger. I guess I've been configuring exit relays for so long that I forget what it's like to configure a non-exit. :)
Same for me. I also thought that setting up a relay would still make it a non- exit by default, as it was in the old days.
I am wondering if the advantage of what Roger stated outweighs the disadvantages for tor operators who do not fully overlook what it means to run an exit node.
I would make non-exit the default.
Regards,
Torland
On Mon, Nov 04, 2013 at 08:53:11AM +0100, tor-admin wrote:
Whoops, thanks for the correction Roger. I guess I've been configuring exit relays for so long that I forget what it's like to configure a non-exit. :)
Same for me. I also thought that setting up a relay would still make it a non- exit by default, as it was in the old days.
It was never that way in the old days. The default exit policy has been the default exit policy since we added the notion of exit policies in 2003.
I would make non-exit the default.
Lunar opened https://trac.torproject.org/projects/tor/ticket/10067
I've retitled this thread to try to get more opinions.
I'm inclined to agree with the idea -- first because the Internet abuse landscape has changed a lot since 'the old days', but mainly because I worry about the "slash and burn agriculture" approach to running Tor relays, where you set up an exit relay, and if anybody gets angry you move on to another ISP. That approach is really appealing since it's simple, but it assumes the Internet is infinite. If in fact we're destroying land without regard to sustainability, and we run out of land...
Today's interactions with ISPs influence Tor's future viability. So if people are accidentally exit relays without knowing it, I worry as much about the damage to the ISP's view of Tor as I do about the temporary hassle for the operator.
--Roger
On Monday 04 Nov 2013 04:10:55 Roger Dingledine wrote:
Today's interactions with ISPs influence Tor's future viability. So if people are accidentally exit relays without knowing it, I worry as much about the damage to the ISP's view of Tor as I do about the temporary hassle for the operator.
Exactly this. I recently made a list of Tor-tolerant VPS hosters, based on the offers available on Low End Box. Out of the 14 I found, three in their AUP stipulated "no exit" and one would allow Tor relays of any kind on their US servers only.
So out of all of the companies I found on LEB, only 11 allowed "full" Tor support, with the others permitting "partial" support. I think more and more hosting and service providers are seeing Tor as a source of legal hassle and don't want to be bothered with it.
If Tor is made non-exit by default, it can be explained to the hosters that Tor out-of-the box will not bring any legal stress their way. It may even encourage them to run a few relays themselves. :)
Best,
This is something I raised a few months ago. I found that an reinstall of an old relay defaulted to exit, I only noticed after a few days... since the relay was on a residential address I immediately reconfigured it. I would assume that the majority of users who run relays on vps in the cloud will have enough technical competence to uncomment a simple exit policy in torrc and restart the service. Whereas someone who just throws up a relay at home may not bother to check torrc at all. Thus it should default to non exit. This is important because, as Roger said, we need to keep isps onside in the long run, I guess most isps don't care what service you run provided they don't get any legal headaches. Running as exit relay should be a consensual and informed decision of the operator.
Tom. On Nov 4, 2013 1:05 PM, "Paritesh Boyeyoko" parity.boy@gmail.com wrote:
On Monday 04 Nov 2013 04:10:55 Roger Dingledine wrote:
Today's interactions with ISPs influence Tor's future viability. So if people are accidentally exit relays without knowing it, I worry as much about the damage to the ISP's view of Tor as I do about the temporary hassle for the operator.
Exactly this. I recently made a list of Tor-tolerant VPS hosters, based on the offers available on Low End Box. Out of the 14 I found, three in their AUP stipulated "no exit" and one would allow Tor relays of any kind on their US servers only.
So out of all of the companies I found on LEB, only 11 allowed "full" Tor support, with the others permitting "partial" support. I think more and more hosting and service providers are seeing Tor as a source of legal hassle and don't want to be bothered with it.
If Tor is made non-exit by default, it can be explained to the hosters that Tor out-of-the box will not bring any legal stress their way. It may even encourage them to run a few relays themselves. :)
Best,
Parity parity.boy@gmail.com _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Mon, 4 Nov 2013 13:43:29 +0000 Thomas Hand th6045@gmail.com allegedly wrote:
Running as exit relay should be a consensual and informed decision of the operator.
Agreed. I'll add my voice to those voting in favour of the default policy for a relay being non-exit. As Tom said, those competent enough to run tor in a VPS can be trusted to be competent enough to edit torrc to allow exit (and apply an appropriate policy). A naive, or new, tor user should not be bitten by a default exit. As I believe Gordon M said earlier, that is a serious "WTF?"
Mick
---------------------------------------------------------------------
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
All,
"If Tor is made non-exit by default, it can be explained to the hosters that Tor out-of-the box will not bring any legal stress their way. It may even encourage them to run a few relays themselves. :) Parity.Boy"
That's on the right track. If running a non-exit relay were clearly separated from running an exit one in everyone's minds 'running Tor' would not be one thing to wholly reject.
The terms need change to make the three states clear.
Tor for browsing - using the network Tor relaying - being a benign part of and expanding the network Tor exiting - from the network to the wider internet
Robert
____________________________________________________________ GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Roger Dingledine:
On Thu, Oct 31, 2013 at 06:12:47PM -0700, Andy Isaacson wrote:
That's correct, it takes a deliberate action on the part of the administrator to become a relay; and another deliberate action to become an exit relay.
Actually, that second part isn't true. Once you decide to become a relay, the default is to exit to most popular ports.
I don't think this is a good enough reason these days, when people who haven't read the fine fine print are putting them up on VPSes. A friend of mine did it and had to get his Linode IP changed after getting on a bunch of blacklists in like two days.
(If you're using Vidalia to configure your relay, it makes you choose whether you want to be a non-exit relay or an exit relay. But just Tor by itself, the default exit policy is in the man page.)
The main reason for this choice is the number of people who've told us that they are only able to run exit relays because "it's what Tor does when you run a relay", and their institution wouldn't let them do it if it required a manual config change to become an exit.
Yeah... you guys would know better than me about that, but speaking from the perspective of a small fish, the exit-as-default torrc is a serious "WTF?" and always has been, given potential legal trouble in privacy-hostile countries.
$.02
Best, - -Gordon M.
Gordon Morehouse:
Yeah... you guys would know better than me about that, but speaking from the perspective of a small fish, the exit-as-default torrc is a serious "WTF?" and always has been, given potential legal trouble in privacy-hostile countries.
I have phrased this differently but I basically agree and opened #10067: https://trac.torproject.org/projects/tor/ticket/10067
On Thursday 31 Oct 2013 21:52:41 Roger Dingledine wrote:
The main reason for this choice is the number of people who've told us that they are only able to run exit relays because "it's what Tor does when you run a relay", and their institution wouldn't let them do it if it required a manual config change to become an exit.
Then again, that was a long time ago, and maybe it's gotten harder to sustain exits these days?
--Roger
I think the Tor exit climate may well have gotten tougher. Invariably people abuse Tor, and from what I've been reading on the likes of LowEndTalk like this thread
http://lowendtalk.com/discussion/1347/tor-node-on-low-end-boxes
more than a few hosters (VPS and dedi) just don't want to have to deal with issues such as abuse and DMCA, so they either
a) Ban Tor completely or
b) Do not allow exits.
Some hosters actually have software that will check the /etc/tor/torrc file on their VPS images to check that the software isn't configured for exit.
Best,
On the other hand the reports, of actual problems, don't seem to be many. The mutterings and rumours do seem to echo.
Of the eighteen exit relays I've run (for just a few months) only a couple have brought letters over copyright and they were in the USA. I am having to deal with the providers's overreaction but I pay by the month so at worst I will lose them. The advice on how to manage exit problems seems to be very sound and Tor is defensible because it is being abused by torrenting also.
Ten exits are going happily on a major provider in Europe who is said to have a policy against them.
Just have a go.
Robert
-----Original Message----- From: parity.boy@gmail.com Sent: Fri, 01 Nov 2013 11:18:53 +0000 To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Amazon abuse report
On Thursday 31 Oct 2013 21:52:41 Roger Dingledine wrote:
The main reason for this choice is the number of people who've told us that they are only able to run exit relays because "it's what Tor does when you run a relay", and their institution wouldn't let them do it if it required a manual config change to become an exit.
Then again, that was a long time ago, and maybe it's gotten harder to sustain exits these days?
--Roger
I think the Tor exit climate may well have gotten tougher. Invariably people abuse Tor, and from what I've been reading on the likes of LowEndTalk like this thread
http://lowendtalk.com/discussion/1347/tor-node-on-low-end-boxes
more than a few hosters (VPS and dedi) just don't want to have to deal with issues such as abuse and DMCA, so they either
a) Ban Tor completely or
b) Do not allow exits.
Some hosters actually have software that will check the /etc/tor/torrc file on their VPS images to check that the software isn't configured for exit.
Best,
Parity parity.boy@gmail.com _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth
On Friday 01 Nov 2013 05:37:14 I wrote:
The advice on how to manage exit problems seems to be very sound and Tor is defensible because it is being abused by torrenting also.
...and this is something else I don't quite understand. People who know about Tor (which obviously includes exit operators) are well aware of the stress that BitTorrent puts on the Tor network.
The paper http://planete.inrialpes.fr/papers/TorTraffic-NSS10.pdf shows 54.48% of the traffic passing through the sample exit nodes was BiTorrent traffic.
Myself and others (I'm sure) look forward to the day when the Tor network comprises 100,000+ 100Mb/s nodes. However, until that time comes I would think that exit node operators would (wrong choice of words incoming) make more effort to use a whitelisted exit policy, thereby starving BitTorrent of bandwidth, and forcing those users away from this "free VPN". The likes of Vuze (Azureus) don't help the situation by offering Tor as an option.
Would it be worth putting together selection of template Exit Policies which exit node operators can cut & paste into their torrc? Or (and this is more a dev question) have an "include" directive where separate policy files can be specified (and therefore substituted), something like this:
ExitPolicy include /etc/tor/mail.exit ExitPolicy include /etc/tor/rdp.exit ExitPolicy include /etc/tor/web.exit ExitPolicy include /etc/tor/chat.exit
Combine this with a default reject *:* policy and it *may* lead to a change of culture and squeeze BitTorrent out. It may even help reduce the number of DMCA notices that exit operators get.
Thoughts?
Please excuse my ignorance operating Tor relays, but if I run an exit node on Windows 7 and use something like Peerblock and correspoding block lists of P2P sites, wouldn't this be somewhat effective in stopping this sort of undesired traffic on Tor?
On 11/1/2013 10:48 AM, Paritesh Boyeyoko wrote:
On Friday 01 Nov 2013 05:37:14 I wrote:
The advice on how to manage exit problems seems to be very sound and Tor is defensible because it is being abused by torrenting also.
...and this is something else I don't quite understand. People who know about Tor (which obviously includes exit operators) are well aware of the stress that BitTorrent puts on the Tor network.
The paper http://planete.inrialpes.fr/papers/TorTraffic-NSS10.pdf shows 54.48% of the traffic passing through the sample exit nodes was BiTorrent traffic.
Myself and others (I'm sure) look forward to the day when the Tor network comprises 100,000+ 100Mb/s nodes. However, until that time comes I would think that exit node operators would (wrong choice of words incoming) make more effort to use a whitelisted exit policy, thereby starving BitTorrent of bandwidth, and forcing those users away from this "free VPN". The likes of Vuze (Azureus) don't help the situation by offering Tor as an option.
Would it be worth putting together selection of template Exit Policies which exit node operators can cut & paste into their torrc? Or (and this is more a dev question) have an "include" directive where separate policy files can be specified (and therefore substituted), something like this:
ExitPolicy include /etc/tor/mail.exit ExitPolicy include /etc/tor/rdp.exit ExitPolicy include /etc/tor/web.exit ExitPolicy include /etc/tor/chat.exit
Combine this with a default reject *:* policy and it *may* lead to a change of culture and squeeze BitTorrent out. It may even help reduce the number of DMCA notices that exit operators get.
Thoughts?
On Fri, 01 Nov 2013 11:22:19 -0700, Nelson nelson@net2wireless.net wrote:
Please excuse my ignorance operating Tor relays, but if I run an exit node on Windows 7 and use something like Peerblock and correspoding block lists of P2P sites, wouldn't this be somewhat effective in stopping this sort of undesired traffic on Tor?
Completely aside from the ethical and censorship-related buzzsaw you're about to run into for posting this (perennial) question, I believe some actual developers on Tor have written a paper about the problems with Bittorrent et al (and I think there's a more specific one than the Why Tor Is Slow[1] paper) but I can't currently find it. Anybody know?
1. https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf
NB: the above paper is from 2009.
Best, -Gordon M.
On 11/1/2013 10:48 AM, Paritesh Boyeyoko wrote:
On Friday 01 Nov 2013 05:37:14 I wrote:
The advice on how to manage exit problems seems to be very sound and Tor is defensible because it is being abused by torrenting also.
...and this is something else I don't quite understand. People who know about Tor (which obviously includes exit operators) are well aware of the stress that BitTorrent puts on the Tor network.
The paper http://planete.inrialpes.fr/papers/TorTraffic-NSS10.pdf shows 54.48% of the traffic passing through the sample exit nodes was BiTorrent traffic.
Myself and others (I'm sure) look forward to the day when the Tor network comprises 100,000+ 100Mb/s nodes. However, until that time comes I would think that exit node operators would (wrong choice of words incoming) make more effort to use a whitelisted exit policy, thereby starving BitTorrent of bandwidth, and forcing those users away from this "free VPN". The likes of Vuze (Azureus) don't help the situation by offering Tor as an option.
Would it be worth putting together selection of template Exit Policies which exit node operators can cut & paste into their torrc? Or (and this is more a dev question) have an "include" directive where separate policy files can be specified (and therefore substituted), something like this:
ExitPolicy include /etc/tor/mail.exit ExitPolicy include /etc/tor/rdp.exit ExitPolicy include /etc/tor/web.exit ExitPolicy include /etc/tor/chat.exit
Combine this with a default reject *:* policy and it *may* lead to a change of culture and squeeze BitTorrent out. It may even help reduce the number of DMCA notices that exit operators get.
Thoughts?
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Friday 01 Nov 2013 14:39:28 Gordon Morehouse wrote:
Completely aside from the ethical and censorship-related buzzsaw you're about to run into for posting this (perennial) question, I believe some actual developers on Tor have written a paper about the problems with Bittorrent et al (and I think there's a more specific one than the Why Tor Is Slow[1] paper) but I can't currently find it. Anybody know?
https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf
NB: the above paper is from 2009.
I've just had a quick scan of that paper and it makes for an interesting read. :) I'm going to go away and read it properly but a couple observations.
2.3 Throttle certain protocols at the client side I agree this is not a good idea BUT it sparked off another idea in my head. In order to get better utilisation of slower relays, would it be worth introducing a behaviour whereby "slow" circuits are deliberately built for low volume traffic?
For example, sending email and IM messages doesn't (usually) require a huge amount of bandwidth, so when the Tor client detects that a user wants to send/receive data on certain slow ports such as POP3, IMAP4, MSA and Jabber it deliberately builds a "slow" circuit to handle that traffic. Obviously it would have to be port based, but since people tend to send data on well-known ports, it shouldn't be an issue.
I think this would play well with the circuit-bonding work here
http://freehaven.net/anonbib/#pets13-splitting
3.1.2 Better Support for relay operators This caught my eye: "We lose relays when the operator reboots and forgets to set up the relay to start on boot." Does installing the .deb package (for example) not configure Tor to start on boot, in the same way that Apache would be? I ask because I haven't rebooted my VPS yet. :p
3.1.3 Facebook app to show off your relay I liked this bit: "Opportunities for expansion include allowing relay operators to form “teams”, and for these teams to be ranked on the contribution to the network. (Real world examples here include the SETI screensaver and the MD5 hash crack challenges.)"
What would be really interesting would be to find sponsors (read: hosters) willing to put their name to it and gain/risk some publicity.
3.2 Funding Relays Directly 100 10Mb/s relays at $10/month is $12K a year, not $120k/year. :)
Best,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Paritesh Boyeyoko:
On Friday 01 Nov 2013 14:39:28 Gordon Morehouse wrote:
Completely aside from the ethical and censorship-related buzzsaw you're about to run into for posting this (perennial) question, I believe some actual developers on Tor have written a paper about the problems with Bittorrent et al (and I think there's a more specific one than the Why Tor Is Slow[1] paper) but I can't currently find it. Anybody know?
https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf
NB: the above paper is from 2009.
I've just had a quick scan of that paper and it makes for an interesting read. :) I'm going to go away and read it properly but a couple observations.
And I swear there's a more bittorrent-specific paper but I can't find it.
2.3 Throttle certain protocols at the client side I agree this is not a good idea BUT it sparked off another idea in my head. In order to get better utilisation of slower relays, would it be worth introducing a behaviour whereby "slow" circuits are deliberately built for low volume traffic?
For example, sending email and IM messages doesn't (usually) require a huge amount of bandwidth, so when the Tor client detects that a user wants to send/receive data on certain slow ports such as POP3, IMAP4, MSA and Jabber it deliberately builds a "slow" circuit to handle that traffic. Obviously it would have to be port based, but since people tend to send data on well-known ports, it shouldn't be an issue.
That might have at least been thought about, but it's a good idea. It'd also help with better allocating bandwidth offered by "slow" or "fast but at the bottom end" nodes, which I've seen devs in here say they are well aware is not optimally allocated.
I think this would play well with the circuit-bonding work here
http://freehaven.net/anonbib/#pets13-splitting
3.1.2 Better Support for relay operators This caught my eye: "We lose relays when the operator reboots and forgets to set up the relay to start on boot." Does installing the .deb package (for example) not configure Tor to start on boot, in the same way that Apache would be? I ask because I haven't rebooted my VPS yet. :p
I've not seen this with .debs, but Windows? If so, maybe the "restart on reboot?" dialog - if there is one, and not a hidden checkbox - should be front and center when opting to relay traffic.
3.1.3 Facebook app to show off your relay I liked this bit: "Opportunities for expansion include allowing relay operators to form “teams”, and for these teams to be ranked on the contribution to the network. (Real world examples here include the SETI screensaver and the MD5 hash crack challenges.)"
I'd go for an embeddable badge, first. Then maybe a Facebook app. It's only a hunch, but I think we'd get a lot more mileage out of an embeddable badge (for web sites, tumblr, and anything else tumblr-like that allows embedding) than out of a Facebook app, though if there were time, money and spoons[1] to do both, I'd certainly do both with the Facebook thing coming second. Well, maybe. Nobody should be on Facebook, least of all anybody who is running Tor for the right reasons, but we have reality to contend with here.
My hunch is based on demographics, BTW. :P
What would be really interesting would be to find sponsors (read: hosters) willing to put their name to it and gain/risk some publicity.
Start by asking XMission, GANDI and maybe even (though they don't do VPS) NearlyFreeSpeech.net if this ever happens. Also, dig back into news articles about industry response to the NSA wiping its butt with the Fourth Amendment, and see which VPS providers were yelling the loudest, especially the mom-n-pop to mid-tier providers. $.02.
Best, - -Gordon M.
On Sat, 02 Nov 2013 21:58:57 +0000, Paritesh Boyeyoko parity.boy@gmail.com wrote:
On Friday 01 Nov 2013 14:39:28 Gordon Morehouse wrote:
Completely aside from the ethical and censorship-related buzzsaw you're about to run into for posting this (perennial) question, I believe some actual developers on Tor have written a paper about the problems with Bittorrent et al (and I think there's a more specific one than the Why Tor Is Slow[1] paper) but I can't currently find it. Anybody know?
https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf
NB: the above paper is from 2009.
I've just had a quick scan of that paper and it makes for an interesting read. :) I'm going to go away and read it properly but a couple observations.
Here are some more links:
https://trac.torproject.org/projects/tor/ticket/9368
http://www-users.cs.umn.edu/~jansen/papers/throttling-sec2012.pdf
https://blog.torproject.org/blog/research-problem-adaptive-throttling-tor-cl...
Finally found em just as another user brought some of them back to my attention. :)
Best, -Gordon M.
My main concern, and the reason I asked about blocking specific traffic (ip's from blacklisted p2p sites), is mainly due to the problem the original poster faces with DMCA; abuse complaints and the possibility of being shutdown. No one wants to volunteer a service and then face legal issues. Who in the hell wants or needs the headache?
That being said I can see that the original poster's issue has raised much needed debate, and a few ideas that I was not personally aware of that I believe can help everyone contribute to the Tor network in a more effective and safe manner.
In my opinion if a well intentioned Tor "contributor" has no other choice but to shutdown his exit node due to legal threats and restrictions primarily based on P2P abuse, then this will be just another reason why Tor is frowned upon and people just don't want to deal with legal issues. A lot more can be done to emphasize to "do the right thing" and then somehow "shape public opinion" on the issues of the necessity of Privacy/Anonymity in light of the NSA's (and friends') abusive and unconstitutional activities and how the Tor network as another tool can effectively help keep people secure while online.
I do believe there is a benefit to Torrents as many of us can attest to, ex: fast downloads of different Linux distros; but if your use of Torrents is in fact legit then why use Tor for downloading your legal content in the first place? This doesn't pass the smell test. As I understand it downloading from a P2P site on Tor is not a smart thing to do in the first place, if you're downloading illegal content, so why do it? Doesn't make sense. People can't claim ignorance that they didn't know that Tor does not protect their identity online when using P2P sites.
But the ones who get clobbered day-in and day-out because of the ignorant few are the Tor operators who contribute ($$$) substantially for everyone's right to freedom and privacy online. I think this act alone should be respected.
+1 for restricting bandwidth
On 11/4/2013 1:41 PM, Gordon Morehouse wrote:
On Sat, 02 Nov 2013 21:58:57 +0000, Paritesh Boyeyoko parity.boy@gmail.com wrote:
On Friday 01 Nov 2013 14:39:28 Gordon Morehouse wrote:
Completely aside from the ethical and censorship-related buzzsaw you're about to run into for posting this (perennial) question, I believe some actual developers on Tor have written a paper about the problems with Bittorrent et al (and I think there's a more specific one than the Why Tor Is Slow[1] paper) but I can't currently find it. Anybody know?
https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf
NB: the above paper is from 2009.
I've just had a quick scan of that paper and it makes for an interesting read. :) I'm going to go away and read it properly but a couple observations.
Here are some more links:
https://trac.torproject.org/projects/tor/ticket/9368
http://www-users.cs.umn.edu/~jansen/papers/throttling-sec2012.pdf
https://blog.torproject.org/blog/research-problem-adaptive-throttling-tor-cl...
Finally found em just as another user brought some of them back to my attention. :)
Best, -Gordon M. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Nov 4, 2013, at 7:13 PM, Nelson nelson@net2wireless.net wrote:
I do believe there is a benefit to Torrents as many of us can attest to, ex: fast downloads of different Linux distros; but if your use of Torrents is in fact legit then why use Tor for downloading your legal content in the first place? This doesn't pass the smell test.
What about someone in a highly censored locale that wants to download a copy of Tails or TBB without "them" knowing?
+1 for restricting bandwidth
For the record, my exit node does limit the ports as per the reduced exit policy [1] and I'd happily open it up wide if I could throttle just the torrenting to a minimally-usable level. However, I honestly don't think it's realistic to spend so much effort to solve the throttling of torrents when those efforts could be better spent elsewhere [2].
Just my 0.00000000002BTC
Cheers!
From all that I have read in these lists not all exit nodes are
configured exactly the same, so some level of traffic control is being rightly exercised by the operator(s). For any given reason be it moral, ethical or legal many well known ports are being blocked, as was previously discussed, as an example by setting up a "white-listing" config rather than blacklisting, and these white-listed ports exclude known ports used by Torrent sites. The choice to configure the exit node should be left to the operator based on their own legitimate preference and criteria.
The argument to "what if" is indeed relative to the level of control and access to legitimate torrents such as "Tails", and therefore any argument against freedom of access to legitimate content defeats the purpose of Tor. This is not really an issue. I'll ask a stupid question: "what comes first, the chicken or the egg?" If you have access to Tor client in the first place and want to download Tails, where's the problem?
..and if you don't have Tor client installed in the first place, where do you get it, so "they" (mel gibson quote) don't know.
On 11/4/2013 5:23 PM, Kevin C. Krinke wrote:
On Nov 4, 2013, at 7:13 PM, Nelson <nelson@net2wireless.net mailto:nelson@net2wireless.net> wrote:
I do believe there is a benefit to Torrents as many of us can attest to, ex: fast downloads of different Linux distros; but if your use of Torrents is in fact legit then why use Tor for downloading your legal content in the first place? This doesn't pass the smell test.
What about someone in a highly censored locale that wants to download a copy of Tails or TBB without "them" knowing?
+1 for restricting bandwidth
For the record, my exit node does limit the ports as per the reduced exit policy [1] and I'd happily open it up wide if I could throttle just the torrenting to a minimally-usable level. However, I honestly don't think it's realistic to spend so much effort to solve the throttling of torrents when those efforts could be better spent elsewhere [2].
Just my 0.00000000002BTC
Cheers!
-- Kevin C. Krinke <kevin@krinke.ca mailto:kevin@krinke.ca> GnuPG - 851662D2 - 0x18C67F61851662D2 http://kevin.c.krinke.ca/851662D2.asc
[1] https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy
[2] No idea what would be better deserving but I'm sure there's plenty of work in Tor-project-land that doesn't involve throttling hard-target services.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Access to tails does not depend on any specific transfer protocol such as torrents correct?
Could it not be made available on a hidden service, a website. an email or ftp server within tor?
On 11/4/2013 11:45 PM, Nelson wrote:
From all that I have read in these lists not all exit nodes are configured exactly the same, so some level of traffic control is being rightly exercised by the operator(s). For any given reason be it moral, ethical or legal many well known ports are being blocked, as was previously discussed, as an example by setting up a "white-listing" config rather than blacklisting, and these white-listed ports exclude known ports used by Torrent sites. The choice to configure the exit node should be left to the operator based on their own legitimate preference and criteria.
The argument to "what if" is indeed relative to the level of control and access to legitimate torrents such as "Tails", and therefore any argument against freedom of access to legitimate content defeats the purpose of Tor. This is not really an issue. I'll ask a stupid question: "what comes first, the chicken or the egg?" If you have access to Tor client in the first place and want to download Tails, where's the problem?
..and if you don't have Tor client installed in the first place, where do you get it, so "they" (mel gibson quote) don't know
On 11/4/2013 5:23 PM, Kevin C. Krinke wrote:
On Nov 4, 2013, at 7:13 PM, Nelson <nelson@net2wireless.net mailto:nelson@net2wireless.net> wrote:
I do believe there is a benefit to Torrents as many of us can attest to, ex: fast downloads of different Linux distros; but if your use of Torrents is in fact legit then why use Tor for downloading your legal content in the first place? This doesn't pass the smell test.
What about someone in a highly censored locale that wants to download a copy of Tails or TBB without "them" knowing?
+1 for restricting bandwidth
For the record, my exit node does limit the ports as per the reduced exit policy [1] and I'd happily open it up wide if I could throttle just the torrenting to a minimally-usable level. However, I honestly don't think it's realistic to spend so much effort to solve the throttling of torrents when those efforts could be better spent elsewhere [2].
Just my 0.00000000002BTC
Cheers!
-- Kevin C. Krinke <kevin@krinke.ca mailto:kevin@krinke.ca> GnuPG - 851662D2 - 0x18C67F61851662D2 http://kevin.c.krinke.ca/851662D2.asc
[1] https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy
[2] No idea what would be better deserving but I'm sure there's plenty of work in Tor-project-land that doesn't involve throttling hard-target services.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
gq:
Access to tails does not depend on any specific transfer protocol such as torrents correct?
Could it not be made available on a hidden service, a website. an email or ftp server within tor?
An http hidden service with the .onion link in Tor docs might be an obvious choice.
On 11/4/2013 11:45 PM, Nelson wrote:
From all that I have read in these lists not all exit nodes are configured exactly the same, so some level of traffic control is being rightly exercised by the operator(s). For any given reason be it moral, ethical or legal many well known ports are being blocked, as was previously discussed, as an example by setting up a "white-listing" config rather than blacklisting, and these white-listed ports exclude known ports used by Torrent sites. The choice to configure the exit node should be left to the operator based on their own legitimate preference and criteria.
The argument to "what if" is indeed relative to the level of control and access to legitimate torrents such as "Tails", and therefore any argument against freedom of access to legitimate content defeats the purpose of Tor. This is not really an issue. I'll ask a stupid question: "what comes first, the chicken or the egg?" If you have access to Tor client in the first place and want to download Tails, where's the problem?
..and if you don't have Tor client installed in the first place, where do you get it, so "they" (mel gibson quote) don't know
On 11/4/2013 5:23 PM, Kevin C. Krinke wrote:
On Nov 4, 2013, at 7:13 PM, Nelson <nelson@net2wireless.net mailto:nelson@net2wireless.net> wrote:
I do believe there is a benefit to Torrents as many of us can attest to, ex: fast downloads of different Linux distros; but if your use of Torrents is in fact legit then why use Tor for downloading your legal content in the first place? This doesn't pass the smell test.
What about someone in a highly censored locale that wants to download a copy of Tails or TBB without "them" knowing?
+1 for restricting bandwidth
For the record, my exit node does limit the ports as per the reduced exit policy [1] and I'd happily open it up wide if I could throttle just the torrenting to a minimally-usable level. However, I honestly don't think it's realistic to spend so much effort to solve the throttling of torrents when those efforts could be better spent elsewhere [2].
Just my 0.00000000002BTC
Cheers!
-- Kevin C. Krinke <kevin@krinke.ca mailto:kevin@krinke.ca> GnuPG - 851662D2 - 0x18C67F61851662D2 http://kevin.c.krinke.ca/851662D2.asc
[1] https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy
[2] No idea what would be better deserving but I'm sure there's plenty
of work in Tor-project-land that doesn't involve throttling hard-target services.
_______________________________________________ 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
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Gonna throw this out there. I've seen it written ealier that in certain jurisdictions Tor operators are protected under the DMCA by being classed as a "common carrier", same as ISPs. Is that correct?
If so, well ISPs rate limit or QoS certain types of traffic all the time, usually at peak times. As far as any kind of throttling mechanism is concerned, this can be achieved outside of Tor, at least on Linux.
Best,
Kevin C. Krinke:
On Nov 4, 2013, at 7:13 PM, Nelson nelson@net2wireless.net wrote:
I do believe there is a benefit to Torrents as many of us can attest to, ex: fast downloads of different Linux distros; but if your use of Torrents is in fact legit then why use Tor for downloading your legal content in the first place? This doesn't pass the smell test.
What about someone in a highly censored locale that wants to download a copy of Tails or TBB without "them" knowing?
+1 for restricting bandwidth
For the record, my exit node does limit the ports as per the reduced exit policy [1] and I'd happily open it up wide if I could throttle just the torrenting to a minimally-usable level. However, I honestly don't think it's realistic to spend so much effort to solve the throttling of torrents when those efforts could be better spent elsewhere [2].
One could have a wide-open exit policy and then do adaptive throttling of all the ports not on the ReducedExitPolicy, without censoring traffic. This can be accomplished entirely with tools that are outside of Tor, e.g. iptables.
Also, educating any of the bigger BitTorrent software providers (uTorrent, Transmission, librtorrent, the knuckledraggers from Vuze probably being a lost cause) to add a *configurable option* to look up peer IPs in a Tor DNSBL and refuse to communicate them would reduce, uh, supply I guess it would be. That's something that can also be done pretty independently of Tor core development - i.e. somebody else can spend the time to do it.
Best, - -Gordon M.
Er, the quoting on my last post was incorrect, it should look like this:
Kevin C. Krinke:
On Nov 4, 2013, at 7:13 PM, Nelson nelson@net2wireless.net wrote:
I do believe there is a benefit to Torrents as many of us can attest to, ex: fast downloads of different Linux distros; but if your use of Torrents is in fact legit then why use Tor for downloading your legal content in the first place? This doesn't pass the smell test.
What about someone in a highly censored locale that wants to download a copy of Tails or TBB without "them" knowing?+1 for restricting bandwidth
For the record, my exit node does limit the ports as per the reduced exit policy [1] and I'd happily open it up wide if I could throttle just the torrenting to a minimally-usable level. However, I honestly don't think it's realistic to spend so much effort to solve the throttling of torrents when those efforts could be better spent elsewhere [2].
One could have a wide-open exit policy and then do adaptive throttling of all the ports not on the ReducedExitPolicy, without censoring traffic. This can be accomplished entirely with tools that are outside of Tor, e.g. iptables.
Also, educating any of the bigger BitTorrent software providers (uTorrent, Transmission, librtorrent, the knuckledraggers from Vuze probably being a lost cause) to add a *configurable option* to look up peer IPs in a Tor DNSBL and refuse to communicate them would reduce, uh, supply I guess it would be. That's something that can also be done pretty independently of Tor core development - i.e. somebody else can spend the time to do it.
Best, --Gordon M.
On Mon, Nov 04, 2013 at 04:13:00PM -0800, Nelson wrote:
I do believe there is a benefit to Torrents as many of us can attest to, ex: fast downloads of different Linux distros; but if your use of Torrents is in fact legit then why use Tor for downloading your legal content in the first place? This doesn't pass the smell test. As I
Sniff harder. You forgot about targeted attacks. The exits can be as malicious as the wider Internet, but unlike the wider Internet they don't know you from Adam.
understand it downloading from a P2P site on Tor is not a smart thing to do in the first place, if you're downloading illegal content, so why do it? Doesn't make sense. People can't claim ignorance that they didn't know that Tor does not protect their identity online when using P2P sites.
On Friday 01 Nov 2013 11:22:19 Nelson wrote:
Please excuse my ignorance operating Tor relays, but if I run an exit node on Windows 7 and use something like Peerblock and correspoding block lists of P2P sites, wouldn't this be somewhat effective in stopping this sort of undesired traffic on Tor?
In return, please excuse my ignorance regarding Windows software. :) I've heard of Peerblock, but have never used it. However, if it does what it says on the tin, then yes it will help by blocking the IPs of well-known trackers, thereby denying the peer list from BitTorrent clients.
However, I'm not sure this will be particularly effective against DHT (the mainstay of TPB content these days); unless you have all the addresses of the DHT jump-off points (a client has to start *somewhere* to get DHT addresses).
Nelson:
Please excuse my ignorance operating Tor relays, but if I run an exit node on Windows 7 and use something like Peerblock and correspoding block lists of P2P sites, wouldn't this be somewhat effective in stopping this sort of undesired traffic on Tor?
No. If the relay says it will deliver a connection in its exit policy, it has to carry it. Otherwise, it will give erratic behaviour on the client side and this is bad. The relay should be flagged BadExit by the authority operators.
On Sat, 2013-11-02 at 01:27 +0100, Lunar wrote:
Nelson:
Please excuse my ignorance operating Tor relays, but if I run an exit node on Windows 7 and use something like Peerblock and correspoding block lists of P2P sites, wouldn't this be somewhat effective in stopping this sort of undesired traffic on Tor?
No. If the relay says it will deliver a connection in its exit policy, it has to carry it. Otherwise, it will give erratic behaviour on the client side and this is bad. The relay should be flagged BadExit by the authority operators.
Of course, there's nothing stopping you from hooking something like Peerblock up to Tor's control port interface and automatically updating your exit policy to block connections to torrent trackers and peers.
On Friday 01 Nov 2013 20:57:54 Ted Smith wrote:
On Sat, 2013-11-02 at 01:27 +0100, Lunar wrote:
Nelson:
Please excuse my ignorance operating Tor relays, but if I run an exit node on Windows 7 and use something like Peerblock and correspoding block lists of P2P sites, wouldn't this be somewhat effective in stopping this sort of undesired traffic on Tor?
No. If the relay says it will deliver a connection in its exit policy, it has to carry it. Otherwise, it will give erratic behaviour on the client side and this is bad. The relay should be flagged BadExit by the authority operators.
Of course, there's nothing stopping you from hooking something like Peerblock up to Tor's control port interface and automatically updating your exit policy to block connections to torrent trackers and peers.
Good idea. :) So let me revise my earlier posts: to reject connections to trackers do something like
ExitPolicy reject *:2710
This will block connections to the Ocelot and XBTT (I think) tracker software on their standard ports. Blocking trackers on port 80 is more difficult, obviously.
To be honest, I wouldn't worry too much about blocking peers; a whitelisted exit policy will take of that, since torrent peers tend to use fairly high range non-standard ports.
One (perhaps nasty) rare case is someone using OpenVPN over Tor, and then torrenting over the VPN, especially since VPN providers will permit port forwarding at their endpoint.
I can see people wanting to VPN over Tor for increased anonymity (especially if the VPN provider accepts anonymous payment) but how popular is this use case? Does anyone have any hard numbers?
On 11/01/2013 07:22 PM, Nelson wrote:
Please excuse my ignorance operating Tor relays, but if I run an exit node on Windows 7 and use something like Peerblock and correspoding block lists of P2P sites, wouldn't this be somewhat effective in stopping this sort of undesired traffic on Tor?
Please don't do this! You really don't want to mess with user traffic apart from what is possible using the exit policy. The whole point of Tor is to create a censorship free, neutral network. Until there is a way to reflect back to the clients what kind of traffic you want to see so they can choose different relays, blacklists such as Peerblock really don't achieve what you seem to think it does. Peerblock especially does not block P2P traffic at all, to the contrary: It is meant to *optimize* your file sharing experience by blocking IP addresses of "bad peers". I have not checked, but I suspect the blacklist to contain Tor relay IPs, so you will mess with Tor routing and break clients in subtle ways. Not only file sharers.
Relays, and exit relays especially, should *never* filter their traffic. Be it "anti virus" solutions, Peerblock, or anything else.
Apart from that, are we really discussing that "any kind of file sharing is bad"?
If you want to minimize file sharing, simply reduce the number of allowed ports. You can start with the extensive "reduced exit policy" [1], and potentially reduce further, to, say, port 22, 80, 443 etc.
Apart from the technical difficulty, there's also legal reasons not to mess with relay traffic: You will likely lose liability protection as "common carrier" as soon as you influence traffic like that.
[1] https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy
On Fri, 01 Nov 2013 17:48:44 +0000, Paritesh Boyeyoko parity.boy@gmail.com wrote:
On Friday 01 Nov 2013 05:37:14 I wrote:
The advice on how to manage exit problems seems to be very sound and Tor is defensible because it is being abused by torrenting also.
...and this is something else I don't quite understand. People who know about Tor (which obviously includes exit operators) are well aware of the stress that BitTorrent puts on the Tor network.
The paper http://planete.inrialpes.fr/papers/TorTraffic-NSS10.pdf shows 54.48% of the traffic passing through the sample exit nodes was BiTorrent traffic.
Myself and others (I'm sure) look forward to the day when the Tor network comprises 100,000+ 100Mb/s nodes. However, until that time comes I would think that exit node operators would (wrong choice of words incoming) make more effort to use a whitelisted exit policy, thereby starving BitTorrent of bandwidth, and forcing those users away from this "free VPN". The likes of Vuze (Azureus) don't help the situation by offering Tor as an option.
Would it be worth putting together selection of template Exit Policies which exit node operators can cut & paste into their torrc? Or (and this is more a dev question) have an "include" directive where separate policy files can be specified (and therefore substituted), something like this:
ExitPolicy include /etc/tor/mail.exit ExitPolicy include /etc/tor/rdp.exit ExitPolicy include /etc/tor/web.exit ExitPolicy include /etc/tor/chat.exit
I *love* the idea of an conf.d/ style exit config.
Combine this with a default reject *:* policy and it *may* lead to a change of culture and squeeze BitTorrent out. It may even help reduce the number of DMCA notices that exit operators get.
I would very much like to see the default policy to be no-exit, because as I mentioned before I suspect we're losing some nodes started up by noobs who then get screamed at and just shut them down, without ever really becoming part of the community. It needs to be as easy as possible to run a relay, and given that one *can* face legal consequences in some jurisdictions over what goes into and out of a computer one rents, no-exit should be the default.
Best, -Gordon M.
On 13-11-01 01:48 PM, Paritesh Boyeyoko wrote:
On Friday 01 Nov 2013 05:37:14 I wrote: The paper http://planete.inrialpes.fr/papers/TorTraffic-NSS10.pdf shows 54.48% of the traffic passing through the sample exit nodes was BiTorrent traffic.
Isnt that about the same percentage on the non-Tor internet?
Would it be worth putting together selection of template Exit Policies which exit node operators can cut & paste into their torrc? Or (and this is more a dev question) have an "include" directive where separate policy files can be specified (and therefore substituted), something like this:
ExitPolicy include /etc/tor/mail.exit ExitPolicy include /etc/tor/rdp.exit ExitPolicy include /etc/tor/web.exit ExitPolicy include /etc/tor/chat.exit
Examples are great if they are kept up to date. Could they be put in the wiki with suitable comments?
Combine this with a default reject *:* policy and it *may* lead to a change of culture and squeeze BitTorrent out. It may even help reduce the number of DMCA notices that exit operators get.
It would help if most bittorrent trackers enforced sharing ratios of around 1:1 (since Tor clients cannot accept incoming connections, unless on a .onion HS). Also helpful if they switched to UDP-only for data which would exclude Tor (until Tor suppports UDP).
On the other hand, i had a reduced exit policy and still got DMCA complaints just for the .torrent file being downloaded via HTTP through my exit.
On Friday 01 Nov 2013 19:36:11 krishna e bera wrote:
Isnt that about the same percentage on the non-Tor internet?
Probably. :)
It would help if most bittorrent trackers enforced sharing ratios of around 1:1 (since Tor clients cannot accept incoming connections, unless on a .onion HS).
Private trackers do this, while open ones like TBP don't care about ratio enforcement. You also raise a good point about incoming connections, however BitTorrent clients can still seed as long as *someone* in the swarm can accept incoming connections, and not necessarily the original seeder. Not every torrent user will be using Tor, obviously.
Also helpful if they switched to UDP-only for data which would exclude Tor (until Tor suppports UDP).
Agreed, but most of the trackers use HTTP.
On the other hand, i had a reduced exit policy and still got DMCA complaints just for the .torrent file being downloaded via HTTP through my exit.
Let me run a couple ideas past you:
1. Configure Squid as a forward proxy with Squidguard and configure Squidguard to reject any URL with "announce" in it. Use IPTables to transparently redirect anything destined for ports 80, 2710 and other well known tracker ports to Squid.
2. Do not exit port 80. While security and anonymity are separate things, they are tightly coupled, so why not exit only secure ports: HTTPS, POP3S, IMAPS etc.
Obviously some protocols use TLS on the same port as the clear traffic, but how detrimental do you think restricting to SSL/TLS enabled protocols (with a few exceptions) would be?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Paritesh Boyeyoko:
On Friday 01 Nov 2013 19:36:11 krishna e bera wrote:
On the other hand, i had a reduced exit policy and still got DMCA complaints just for the .torrent file being downloaded via HTTP through my exit.
Let me run a couple ideas past you:
- Configure Squid as a forward proxy with Squidguard and
configure Squidguard to reject any URL with "announce" in it. Use IPTables to transparently redirect anything destined for ports 80, 2710 and other well known tracker ports to Squid.
- Do not exit port 80. While security and anonymity are separate
things, they are tightly coupled, so why not exit only secure ports: HTTPS, POP3S, IMAPS etc.
Obviously some protocols use TLS on the same port as the clear traffic, but how detrimental do you think restricting to SSL/TLS enabled protocols (with a few exceptions) would be?
What if someone inside a totalitarian state is attempting to upload evidence of a massacre to a service which runs on port 80?
I'd love to get the bandwidth back from the 16 year olds downloading movies and terrible porn over Tor, too, but this won't fly, and y'all are gonna get flamed into cinders in about 5... 4... 3... for the types of reasons I just mentioned above.
Best, - -Gordon M.
On Friday 01 Nov 2013 20:02:29 Gordon Morehouse wrote:
What if someone inside a totalitarian state is attempting to upload evidence of a massacre to a service which runs on port 80?
Yeah, I did think of this but I thought I'd put it out there anyway. Unfortunately, too many sites/services don't use SSL. Well, it's a no-no.
I'd love to get the bandwidth back from the 16 year olds downloading movies and terrible porn over Tor, too, but this won't fly, and y'all are gonna get flamed into cinders in about 5... 4... 3... for the types of reasons I just mentioned above.
So would I, hence my looking at this to try and knock such 16 year olds off of the network. :) However, yourself and Lunar make good points especially concerning the legal position over traffic redirection and/or manipulation.
Unfortunately, too many BitTorrent trackers are written in PHP, which makes them easy to integrate into a typical web hosting setup, as opposed to requiring a VPS or dedi to run the tracker software on a separate port.
So what's the answer? Education? Educating torrent users to not use Tor isn't going to work - if they know enough to use Tor (thanks Azureus, NOT) - then they're gonna use it, so that's pretty much out.
Publication of sample exit policies? Would that encourage exit node operators to run restricted exit policies, and save themselves loads of bandwidth and DMCA headache?
Is there a forum where one can put up a sticky post with sample exit policies so that operators can simply cut and paste them into their setups?
Best,
On 11/02/2013 01:15 PM, Paritesh Boyeyoko wrote:
Publication of sample exit policies? Would that encourage exit node operators to run restricted exit policies, and save themselves loads of bandwidth and DMCA headache? Is there a forum where one can put up a sticky post with sample exit policies so that operators can simply cut and paste them into their setups?
There's https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy , but you probably know that one?
On Saturday 02 Nov 2013 13:21:39 Moritz Bartl wrote:
On 11/02/2013 01:15 PM, Paritesh Boyeyoko wrote:
Publication of sample exit policies? Would that encourage exit node operators to run restricted exit policies, and save themselves loads of bandwidth and DMCA headache? Is there a forum where one can put up a sticky post with sample exit policies so that operators can simply cut and paste them into their setups?
There's https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy , but you probably know that one?
Thanks, yes I've seen that one. :)
I'm just finding it difficult to accept that there's little to be done. As far as I can see, the only way BitTorrent content distibution can work across Tor is because exits are allowing accept *:* as their exit policy - torrent clients are typically on non-standard ports.
The effect of this is that Tor gets a bad rep for copyright abuse right alongside BitTorrent, and people shy away from running exits due to the hassle involved.
Observation: the URI you linked above is accessed from this page
https://trac.torproject.org/projects/tor/wiki//doc/TorExitGuidelines
but you must go halfway down the page, under "Handling abuse complaints" to get to it. Perhaps on this page
https://www.torproject.org/docs/tor-relay-debian.html.en
running an exit should be given its own section on this page, since running an exit is rather more involved than running a middle relay? Perhaps make the reduced exit policy more prominent so that people are more aware of it?
Question: why not ship the reduced ExitPolicy as part of the default torrc, but commented out, and with reject *:* as the default ExitPolicy? That way, an exit node operator simply has to uncomment the lines they need, or at least use it as a guide if they want a less cluttered torrc.
Best,
On 11/02/2013 02:46 PM, Paritesh Boyeyoko wrote:
I'm just finding it difficult to accept that there's little to be done. As far as I can see, the only way BitTorrent content distibution can work across Tor is because exits are allowing accept *:* as their exit policy - torrent clients are typically on non-standard ports. The effect of this is that Tor gets a bad rep for copyright abuse right alongside BitTorrent, and people shy away from running exits due to the hassle involved.
As one of the large operators that indeed allows exiting on all ports except 25: This is on purpose. I don't consider applications that choose random ports as bad, I don't consider file sharing per se as bad. I don't want to interfere with user traffic. I wish I could leave 25 open as well, but our ISPs don't like that.
Observation: the URI you linked above is accessed from this page https://trac.torproject.org/projects/tor/wiki//doc/TorExitGuidelines but you must go halfway down the page, under "Handling abuse complaints" to get to it. Perhaps on this page https://www.torproject.org/docs/tor-relay-debian.html.en running an exit should be given its own section on this page.
I can understand the intention. The exit guidelines should be linked from there, I agree. On the other hand, I am not a fan of "making it easier" to run exit relays. Reading a (somewhat lengthy) document as the exit guidelines should really be the least you can require. There's some things you just can't optimize away.
Question: why not ship the reduced ExitPolicy as part of the default torrc, but commented out, and with reject *:* as the default ExitPolicy?
The current torrc ships with
#ExitPolicy accept *:6660-6667,reject *:* # allow irc ports but no more #ExitPolicy accept *:119 # accept nntp as well as default exit policy #ExitPolicy reject *:* # no exits allowed
So, "reject *:*" is already an example rule in there. Listing all examples from the reduced exit policy will make reading the file more complicated, especially for the majority that will not want to run an exit relay in the first place.
Also, it has:
## Look at https://www.torproject.org/faq-abuse.html#TypicalAbuses ## for issues you might encounter if you use the default exit policy.
And that URL mentions the DMCA problem and links to both the reduced exit policy and the exit guidelines.
On Saturday 02 Nov 2013 17:10:50 Moritz Bartl wrote:
As one of the large operators that indeed allows exiting on all ports except 25: This is on purpose. I don't consider applications that choose random ports as bad, I don't consider file sharing per se as bad. I don't want to interfere with user traffic. I wish I could leave 25 open as well, but our ISPs don't like that.
I suppose you and I have different philosophies regarding this. :)
If the paper I linked earlier can be considered reflective of the entire Tor network, knowing that 54% of the traffic on Tor is BitTorrent traffic is frustrating.
Like you and others, I'd like to see people take advantage of Tor, rather than simply abuse it. I have a VPS running a middle relay and I've had to restrict the line rate on it to 3Mb/s to avoid going over the 1TB monthly quota and avoid the relay from hibernating.
Knowing that more than half that traffic is BitTorrent traffic is disheartening when
a) I will happily support Tor for its intended purpose (I hate anyone who tries to control/negate free speech) and
b) I know full well, as we all do, that 90%+ of BitTorrent traffic is copyrighted works.
As I said earlier, if Tor was 100,000+ nodes strong with 100Mb/s per node and unlimited bandwidth nobody would care. Unfortunately, that isn't the case and the BitTorrent users very obviously don't know or care about the very real effect they are having.
Don't get me wrong, it's not like I hate BitTorrent and have a crusade against it - I don't. In fact I use it regularly. :p I'd just like a way of actively discouraging its use on Tor, and as far as I can see the line is drawn (quite literally) at the exits.
Best,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Paritesh Boyeyoko:
On Friday 01 Nov 2013 20:02:29 Gordon Morehouse wrote:
What if someone inside a totalitarian state is attempting to upload evidence of a massacre to a service which runs on port 80?
Yeah, I did think of this but I thought I'd put it out there anyway. Unfortunately, too many sites/services don't use SSL. Well, it's a no-no.
That's changing, not fast enough, but the NSA did a great job of raising awareness (even if they *can* crack it)...
I'd love to get the bandwidth back from the 16 year olds downloading movies and terrible porn over Tor, too, but this won't fly, and y'all are gonna get flamed into cinders in about 5... 4... 3... for the types of reasons I just mentioned above.
So would I, hence my looking at this to try and knock such 16 year olds off of the network. :) However, yourself and Lunar make good points especially concerning the legal position over traffic redirection and/or manipulation.
Well, plus, there are ethical questions about managing the traffic itself, and the fact that if tampering is detected, you'll get a BadExit flag. It's mostly ethical questions, IMO.
So what's the answer? Education? Educating torrent users to not use Tor isn't going to work - if they know enough to use Tor (thanks Azureus, NOT) - then they're gonna use it, so that's pretty much out.
Education does help - I've crashed many a thread suggesting Tor for BitTorrent and explained why it's harmful. I mean, I guess I don't have any metrics to back me up, but a lot of the people seem to say "oh, jeez, well in that case maybe I won't."
Publication of sample exit policies? Would that encourage exit node operators to run restricted exit policies, and save themselves loads of bandwidth and DMCA headache?
That's been done, but a link in the default torrc above those config areas would be *great*.
Best, - -Gordon M.
Putting the extensive exit restriction policy in the responses to take-down demands seems like a good idea.
Robert
Publication of sample exit policies? Would that encourage exit node operators to run restricted exit policies, and save themselves loads of bandwidth and DMCA headache?
Is there a forum where one can put up a sticky post with sample exit policies so that operators can simply cut and paste them into their setups?
parity.boy@gmail.com
____________________________________________________________ TRY FREE IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if5 Capture screenshots, upload images, edit and send them to your friends through IMs, post on Twitter®, Facebook®, MySpace™, LinkedIn® – FAST!
Paritesh Boyeyoko:
On the other hand, i had a reduced exit policy and still got DMCA complaints just for the .torrent file being downloaded via HTTP through my exit.
Let me run a couple ideas past you:
- Configure Squid as a forward proxy with Squidguard and configure Squidguard
to reject any URL with "announce" in it. Use IPTables to transparently redirect anything destined for ports 80, 2710 and other well known tracker ports to Squid.
Big no-no. Once an exit relay has accepted traffic (through it's exit policy), it has to carry on with the connection, untampered. Otherwise, this is BadExit.
Also, having Squid looking at the *content* of the connections is likely to mean that you now become legally responsible for everything that you let go through in several jurisdictions I know. Pretty bad idea.
On Wed, Oct 30, 2013 at 12:43 PM, Tom Ritter tom@ritter.vg wrote:
On 29 October 2013 22:53, Sanjeev Gupta ghane0@gmail.com wrote:
Yes, to some extent. I edited the config, as I was willing to pay for the extra bandwidth, and enabled an Exit Relay.
I was under the impression that this was permitted.
Amazon does not like Exit Nodes running in EC2. I'm not sure if there was a specific reason bridge vs relay was chosen, but I do know that exit nodes weren't an option.
When deciding whether or not to build Tor Cloud relay-by-default images, we first estimated how much bandwidth an average relay is pushing per week [1] - 251 GiB/wk. Instead of offering users to run slow, expensive, and less than average, relays in the cloud, we opted for bridges only.
[1]: https://trac.torproject.org/projects/tor/ticket/4387
tor-relays@lists.torproject.org
-
Andreas Krey -
Andy Isaacson -
Eugen Leitl -
Gordon Morehouse -
gq -
I -
Kevin C. Krinke -
krishna e bera -
Lunar -
mick -
Moritz Bartl -
Nelson -
Paritesh Boyeyoko -
Roger Dingledine -
Runa A. Sandvik -
Sanjeev Gupta -
Ted Smith -
Thomas Hand -
Tom Ritter -
tor-admin