Dear all,
I’ve been running tor non-exit relay freshhumbug at torrelay.nl http://torrelay.nl/ for about 3 months now. Recently, I tried running it as an exit relay for a week, with following interesting results.
Set up: - Ubuntu 14.04 running as VPS with transip.nl http://transip.nl/, latest release version of Tor - bandwidth rate set to between 1 MB/s and 2 MB/s - VERY reduced exit policy (listed below)
Part 1: Abuse over HTTP.
Within one week of being an exit, my provider forwarded the following abuse notification to me (XXXX is the abused Russian website, ZZZZ is me): ==== Greetings,
XXXX abuse team like to inform you, that we have had mass bruteforce attempts to the Joomla / WordPress control panel on the our shared-hosting server XXXX from your network, from IP address ZZZZ
During the last 30 minutes we recorded 333 attempts like this:
XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-“ XXXX - [14/Oct/2014:14:17:54 +0400] "POST /administrator/index.php HTTP/1.1" 499 0 "-" "-" ====
Lesson (for me at least): since HTTP was used, even a very reduced exit policy is does not make one immune to abuse problems. At this point I reverted back to being a non-exit relay, as I have no interest in having to deal with this.
Part 2: Stealrat infection.
As part of being an exit relay, I set reverse DNS to this-is-a-tor-exit.torrelay.nl http://this-is-a-tor-exit.torrelay.nl/, and I displayed the this-is-a-tor-exit-node.html web page on port 80, using the DirPortFrontPage option. A few days after having shut down my exit, I received notification from my provider that they have been told that my IP address was infected with Stealrat. It hosted a Stealrat PHP file, used to send spam. - http://blog.trendmicro.com/trendlabs-security-intelligence/compromised-sites... http://blog.trendmicro.com/trendlabs-security-intelligence/compromised-sites-conceal-stealrat-botnet-operations/ - http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-... http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-stealrat.pdf
However, the only thing I do with my VPS is run tor. I don’t run a web site, and don’t have apache or whatever installed. I didn’t investigate much further, but my hypothesis is that when publishing the tor-exit notice on port 80 either tor internally uses a web server or enables a web server that’s present in the system. Either way, that webserver was hacked through a PHP hack. (Note that I received the Stealrat notification only after stopping my exit node. I’m not sure if the Stealrat hack was still active or not. I couldn’t find relevant PHP files on my system.) Since I didn’t want to spend time or effort (figuring out how to) clean my system, I reinstalled ubuntu & tor (only ~40 min work anyway).
Lesson (for me): using the DirPortFrontPage option opens up an unexpected web server vulnerability.
Perhaps this information is useful for others.
With best regards, Kees
Relevant parts of the torrc:
ORPort 9001 # port used for relaying traffic DirPort 80 # port used for mirroring directory information - not used, since have accountingmax SocksPort 0 # prevents tor from being used as a client RelayBandwidthRate 1000 KB # limit for the bandwidth we'll use to relay RelayBandwidthBurst 10 MB # maximum rate when relaying bursts of traffic BandwidthRate 1000 KB # same as RelayBandwidthRate BandwidthBurst 10 M # same as RelayBandwidthBurst DirPortFrontPage /home/administrator/.arm/this-is-a-tor-exit.html ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:749 # kerberos ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8082 # HTTPS Electrum Bitcoin port ExitPolicy accept *:8332-8333 # Bitcoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:50002 # Electrum Bitcoin SSL ExitPolicy reject *:*
On Sun, Oct 19, 2014 at 01:24:31PM +0200, Kees Goossens wrote:
However, the only thing I do with my VPS is run tor. I don???t run a web site, and don???t have apache or whatever installed. I didn???t investigate much further, but my hypothesis is that when publishing the tor-exit notice on port 80 either tor internally uses a web server or enables a web server that???s present in the system. Either way, that webserver was hacked through a PHP hack.
It is much more likely that this was a false positive. That is, whoever sent you the mail was using a wrong-in-your-case mechanism for detecting whether you're infected with "stealrat". They probably just make a list of all the computers that connect to them and send certain traffic. And if your computer connected to them and sent that traffic, onto their list you go.
The Internet is full of people telling other people that they're infected and ought to clean up their computer. Sometimes they're right, sometimes they're wrong. Usually, when it comes to Tor relays they're wrong, because it never occurred to them that you might be proxying the traffic from somebody else.
Hope that helps, --Roger
Dear Roger,
Thanks for quick reply. This possibility did occur to me. When I asked my VPS provider about getting more information for further diagnosis told me they didn’t have more, but that the party that sent them the notification had been reliable in the past. My provider has been relatively friendly during this process, and I didn’t want to push them further.
Overall, let’s just hope that I’ve been an atypical case in getting two complaints in my first week of operating an exit node.
Thanks, Kees
On 19 Oct 2014, at 13:31, Roger Dingledine arma@mit.edu wrote:
On Sun, Oct 19, 2014 at 01:24:31PM +0200, Kees Goossens wrote:
However, the only thing I do with my VPS is run tor. I don???t run a web site, and don???t have apache or whatever installed. I didn???t investigate much further, but my hypothesis is that when publishing the tor-exit notice on port 80 either tor internally uses a web server or enables a web server that???s present in the system. Either way, that webserver was hacked through a PHP hack.
It is much more likely that this was a false positive. That is, whoever sent you the mail was using a wrong-in-your-case mechanism for detecting whether you're infected with "stealrat". They probably just make a list of all the computers that connect to them and send certain traffic. And if your computer connected to them and sent that traffic, onto their list you go.
The Internet is full of people telling other people that they're infected and ought to clean up their computer. Sometimes they're right, sometimes they're wrong. Usually, when it comes to Tor relays they're wrong, because it never occurred to them that you might be proxying the traffic from somebody else.
Hope that helps, --Roger
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Kees Goossens schreef op 19/10/14 13:24:
Part 1: Abuse over HTTP.
Within one week of being an exit, my provider forwarded the following abuse notification to me (XXXX is the abused Russian website, ZZZZ is me): ==== Greetings,
XXXX abuse team like to inform you, that we have had mass bruteforce attempts to the Joomla / WordPress control panel on the our shared-hosting server XXXX from your network, from IP address ZZZZ
During the last 30 minutes we recorded 333 attempts like this:
XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-“ XXXX - [14/Oct/2014:14:17:54 +0400] "POST /administrator/index.php HTTP/1.1" 499 0 "-" "-" ====
Lesson (for me at least): since HTTP was used, even a very reduced exit policy is does not make one immune to abuse problems. At this point I reverted back to being a non-exit relay, as I have no interest in having to deal with this.
Hi Kees,
Sounds familiar. This same company (valuehost.ru?) sends me about 20 abuse reports a day. At first I replied with explanations of what Tor is, explaining why it's hard to do anything against this kind of abuse. Later I started sending the same replies but with a note "Please reply if you have read this message." - no replies. Their message mentions a contact address so I started cc'ing that address - still no reply. After replying for two months and never getting any replies, I stopped replying.
IANAL but you can probably just ignore those.
Abuse reports are very common but there's usually not much you can do other than write a message back explaining why there's not much you can do. Make sure your server provider knows that you run an exit relay!
Tom
++ 19/10/14 13:53 +0200 - Tom van der Woerdt:
Sounds familiar. This same company (valuehost.ru?) sends me about 20 abuse reports a day. At first I replied with explanations of what Tor is, explaining why it's hard to do anything against this kind of abuse. Later I
[...]
IANAL but you can probably just ignore those.
I have had exactly the same experience with valuehost.ru. At this moment I'm ignoring any automated notification I receive from them.
Hi, Tom and Rejo. Same with me. Half of the abuse complaints I get are from Valuehost Ru. Because I run on a cheap VPS I don't get a reassigned IP. Therefore I always fear that my provider might lose patience and shut down my server. That's why I decided to block Valuehost's range 217.112.34.0/24 completely.
I also wrote to Valuehost Ru and asked them politely to consider that their own customers might like to use tor and to reconsider their policy for abuse complaints. No answer yet. I think they have an automated abuse complaint system and don't care much for replies.
Cheers,
M.
Manuel Gebauer schreef op 19/10/14 15:29:
Hi, Tom and Rejo. Same with me. Half of the abuse complaints I get are from Valuehost Ru. Because I run on a cheap VPS I don't get a reassigned IP. Therefore I always fear that my provider might lose patience and shut down my server. That's why I decided to block Valuehost's range 217.112.34.0/24 completely.
I also wrote to Valuehost Ru and asked them politely to consider that their own customers might like to use tor and to reconsider their policy for abuse complaints. No answer yet. I think they have an automated abuse complaint system and don't care much for replies.
Cheers,
M.
So I tried getting in contact with them again in an attempt to reduce the amount of abuse mails they send us. This time they replied :
-------------------------
Hello,
We make abuse notices not only for TOR exit node operators, we make it to their uplinks too. If we will stop to do it, it will lead for:
- TOR exit node operators will cease to think to solve this serious problem (with all due respect to noble purposes of TOR, like censorship resistance for Chinese dissidents etc., we see that a large part of of TOR traffic is malicious)
- TOR exit node uplinks will not notified about malicious activity in their networks
Also, if we'll except over 1000 IP's of Tor exit nodes from the security system, it will be spent too many resources. So we suggest to ignore abuse messages if you don't care about the safety of Internet.
-------------------------
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ask your upstream to filter their reports if you can, I can testify I have received in excess of 300 complaints from them and ironically, they ignored all of my responses to them for the first 200 or so I responded to.
Ultimately (if you'll excuse my language), they are acting like a bunch of tossers and so I am not wasting my time on them when it could be spent productively elsewhere (ie liaising with police and branching out my contacts to talk about Tor).
One important thing to remember here is that they only append current Tor IP's to their abuse list. 5 of my exits have recently changed IP address and in the several days following, they are still sending abuse complaints to them when Tor isn't even running.
- -T
On 24/10/2014 08:16, Tom van der Woerdt wrote:
Manuel Gebauer schreef op 19/10/14 15:29:
Hi, Tom and Rejo. Same with me. Half of the abuse complaints I get are from Valuehost Ru. Because I run on a cheap VPS I don't get a reassigned IP. Therefore I always fear that my provider might lose patience and shut down my server. That's why I decided to block Valuehost's range 217.112.34.0/24 completely.
I also wrote to Valuehost Ru and asked them politely to consider that their own customers might like to use tor and to reconsider their policy for abuse complaints. No answer yet. I think they have an automated abuse complaint system and don't care much for replies.
Cheers,
M.
So I tried getting in contact with them again in an attempt to reduce the amount of abuse mails they send us. This time they replied :
Hello,
We make abuse notices not only for TOR exit node operators, we make it to their uplinks too. If we will stop to do it, it will lead for:
- TOR exit node operators will cease to think to solve this
serious problem (with all due respect to noble purposes of TOR, like censorship resistance for Chinese dissidents etc., we see that a large part of of TOR traffic is malicious)
- TOR exit node uplinks will not notified about malicious activity
in their networks
Also, if we'll except over 1000 IP's of Tor exit nodes from the security system, it will be spent too many resources. So we suggest to ignore abuse messages if you don't care about the safety of Internet.
Tom
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Freitag, 24. Oktober 2014, 09:16:49 Tom van der Woerdt wrote:
Manuel Gebauer schreef op 19/10/14 15:29:
Hi, Tom and Rejo. Same with me. Half of the abuse complaints I get are from Valuehost Ru. Because I run on a cheap VPS I don't get a reassigned IP. Therefore I always fear that my provider might lose patience and shut down my server. That's why I decided to block Valuehost's range 217.112.34.0/24 completely.
I also wrote to Valuehost Ru and asked them politely to consider that their own customers might like to use tor and to reconsider their policy for abuse complaints. No answer yet. I think they have an automated abuse complaint system and don't care much for replies.
Cheers,
M.
So I tried getting in contact with them again in an attempt to reduce the amount of abuse mails they send us. This time they replied :
Hello,
We make abuse notices not only for TOR exit node operators, we make it to their uplinks too. If we will stop to do it, it will lead for:
- TOR exit node operators will cease to think to solve this serious
problem (with all due respect to noble purposes of TOR, like censorship resistance for Chinese dissidents etc., we see that a large part of of TOR traffic is malicious)
- TOR exit node uplinks will not notified about malicious activity in
their networks
Also, if we'll except over 1000 IP's of Tor exit nodes from the security system, it will be spent too many resources. So we suggest to ignore abuse messages if you don't care about the safety of Internet.
Tom
Sounds quite "nice" to me :)
On Sun, Oct 19, 2014 at 01:53:40PM +0200, Tom van der Woerdt wrote:
Kees Goossens schreef op 19/10/14 13:24:
Part 1: Abuse over HTTP.
Within one week of being an exit, my provider forwarded the following abuse notification to me (XXXX is the abused Russian website, ZZZZ is me): ==== Greetings,
XXXX abuse team like to inform you, that we have had mass bruteforce attempts to the Joomla / WordPress control panel on the our shared-hosting server XXXX from your network, from IP address ZZZZ
During the last 30 minutes we recorded 333 attempts like this:
XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-“ XXXX - [14/Oct/2014:14:17:54 +0400] "POST /administrator/index.php HTTP/1.1" 499 0 "-" "-" ====
Lesson (for me at least): since HTTP was used, even a very reduced exit policy is does not make one immune to abuse problems. At this point I reverted back to being a non-exit relay, as I have no interest in having to deal with this.
Hi Kees,
Sounds familiar. This same company (valuehost.ru?) sends me about 20 abuse reports a day. At first I replied with explanations of what Tor is, explaining why it's hard to do anything against this kind of abuse. Later I started sending the same replies but with a note "Please reply if you have read this message." - no replies. Their message mentions a contact address so I started cc'ing that address - still no reply. After replying for two months and never getting any replies, I stopped replying.
IANAL but you can probably just ignore those.
Abuse reports are very common but there's usually not much you can do other than write a message back explaining why there's not much you can do. Make sure your server provider knows that you run an exit relay!
Tom
Same here, I've blacklisted their /24 in my torrc. The complaints stopped.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
++ 19/10/14 13:48 +0000 - obx:
Same here, I've blacklisted their /24 in my torrc. The complaints stopped.
That is not a sound approach: i) Tor clients will see unexpected connection errors as some destinations are unreachable where they should and ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node.
Rejo Zenger wrote:
++ 19/10/14 13:48 +0000 - obx:
Same here, I've blacklisted their /24 in my torrc. The complaints stopped.
That is not a sound approach: i) Tor clients will see unexpected connection errors as some destinations are unreachable where they should
In torrc? Really? Surely not, given that the policy is published in the exit descriptor. (I can't speak to the legalities of (ii).)
---> Drake Wilson
++ 19/10/14 08:56 -0500 - Drake Wilson:
In torrc? Really? Surely not, given that the policy is published in the exit descriptor. (I can't speak to the legalities of (ii).)
Ah, yes. I was confused with denying access to IP-space using a firewall. That is not published in the exit descriptor.
That is not a sound approach:
I think it is.
i) Tor clients will see unexpected connection errors as some destinations are unreachable where they should
Not nice, but better then to lose the complete exit node. Big nodes with their own reassigned IP should of course do otherwise and just move the valuehost abuse spam to /dev/null.
ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node.
Example? In Germany you might (or might not) be responsible for traffic you relay. But not relaying part of the traffic doesn't change a thing, legally.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
That is not a sound approach:
I think it is.
ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node.
Example? In Germany you might (or might not) be responsible for traffic you relay. But not relaying part of the traffic doesn't change a thing, legally.
i remember reading somewhere [1] that if you run a server that carries mail and you don't choose where it goes or who it comes from, the server is protected from some DMCA complaints by the DMCA "safe harbor" terms (us code title 17 Chapter 5 § 512).
this might only apply in the US and it may not be entirely correct, but it does lay out that if you censor where the traffic goes to or comes from, you surrender some rights.
mikael ball
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yes there are safe harbour provisions.
When it comes to civil issues, for example DMCA (Digital Millennium Copyright Act) issues, it is worth considering DMCA title 11 Online Copyright Infringement Liability Limitation Act (OCILLA USA Law) as the spirit of this piece of legislation is reflected in treaties with countries such as the UK and EU too. It refers to a "safe harbor" for online service providers (OSP's) liability provided they meet specific requirements. An exit node operator, assuming UK law was to abide by its treaty obligations would not be liable for holding (or transmitting unknowingly) infringing material but the statue makes clear that it must not be for financial gain. Under EU law (since in this respect US treaty law is overruled by national laws) in order for the copyright holder to successfully prosecute a criminal case or recover damages in a civil case, there must be proof of knowledge of the infringement and that the infringement was intended for commercial gain which is not the case for most exit operators.
Although not directly applicable, most EU laws have common traits and developments. UK law itself is surprisingly under developed in the area of computer copyright and the Copyright, Design and Patents Act of 1988 as amended is interesting in its antiquated terminology but the law itself is quite clear on what has to be proved in a prosecution case, so simple threats of action do not mean they have a case you must answer.
(some excepts above from a mail I sent ORG earlier this month)
- -T
On 19/10/2014 21:24, mikael ball wrote:
That is not a sound approach:
I think it is.
ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node.
Example? In Germany you might (or might not) be responsible for traffic you relay. But not relaying part of the traffic doesn't change a thing, legally.
i remember reading somewhere [1] that if you run a server that carries mail and you don't choose where it goes or who it comes from, the server is protected from some DMCA complaints by the DMCA "safe harbor" terms (us code title 17 Chapter 5 § 512).
this might only apply in the US and it may not be entirely correct, but it does lay out that if you censor where the traffic goes to or comes from, you surrender some rights.
mikael ball
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thomas,
That sounded so reasonable and persuasive that would it be a good idea to have a formal opinion written to give to server companies early on?
They might still be looking at the time it takes to deal with notices or police queries but they must accept that the risks of allowing Tor are miniscule. Perhaps the way around the remaining deterrence is a Tor response 'centre' for them to painlessly redirect irritations to.
Robert
Yes there are safe harbour provisions.
Already working on it (see https://trac.torproject.org/projects/tor/ticket/13421)
Will involve a lot of outreach and will need to consider lots of jurisdictions but it can be done with a few volunteers over the next few weeks I feel. I may also be proposing on trac a @torproject.org email for such things so if ISPs did want to do a little fact checking they can have an easy point of contact and also allows a central place to reach out to the ISPs.
I feel a central email for such things would garner more respect than the fracture groups assigned using their own personal emails.
-T
On 19/10/2014 23:21, I wrote:
Thomas,
That sounded so reasonable and persuasive that would it be a good idea to have a formal opinion written to give to server companies early on?
They might still be looking at the time it takes to deal with notices or police queries but they must accept that the risks of allowing Tor are miniscule. Perhaps the way around the remaining deterrence is a Tor response 'centre' for them to painlessly redirect irritations to.
Robert
Yes there are safe harbour provisions.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thomas,
Excellent fellow!
I agree that a little more appearance of coherence would do well for us but one great strength of such ideas as Tor is the absence of formal structure and that should be retained. The idea is available to be put into practice by anyone by themselves without permission. I was thinking of a point of contact for help and information only. The qualified statement of Tor operators's legal position should stand on its own.
Robert
-----Original Message----- From: thomaswhite@riseup.net Sent: Mon, 20 Oct 2014 00:19:40 +0100 To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] exit node experience: abuse over HTTP, stealrat infection
Already working on it (see https://trac.torproject.org/projects/tor/ticket/13421)
Will involve a lot of outreach and will need to consider lots of jurisdictions but it can be done with a few volunteers over the next few weeks I feel. I may also be proposing on trac a @torproject.org email for such things so if ISPs did want to do a little fact checking they can have an easy point of contact and also allows a central place to reach out to the ISPs.
I feel a central email for such things would garner more respect than the fracture groups assigned using their own personal emails.
-T
On 19/10/2014 23:21, I wrote:
Thomas,
That sounded so reasonable and persuasive that would it be a good idea to have a formal opinion written to give to server companies early on?
They might still be looking at the time it takes to deal with notices or police queries but they must accept that the risks of allowing Tor are miniscule. Perhaps the way around the remaining deterrence is a Tor response 'centre' for them to painlessly redirect irritations to.
Robert
Yes there are safe harbour provisions.
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
that meant
Being part of Tor the ideal is available to anyone just by downloading and running it.
Robert (you can't imagine how much I envy Roger Dingledine's clarity of expression)
++ 19/10/14 16:13 +0200 - Manuel Gebauer:
ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node.
Example? In Germany you might (or might not) be responsible for traffic you relay. But not relaying part of the traffic doesn't change a thing, legally.
First: I was discussing a situation where the policy doesn't get published in the descriptor. For example, one is iptables to deny access to some IP-space. This is of course different from configuring this rejection policy in the Tor configuration file.
As for the responsinilty: I was referring to the e-Commerce directive in the EU. Article 12 says:
"Where an [...] service is provided that consists of the transmission in a communication network of information [...], Member States shall ensure that the service provider is not liable for the information transmitted, on condition that the provider [...] does not select or modify the information contained in the transmission."
I would says that if an operator rejects traffic using iptables, he does do selection of information contained in the transmission. Of course, this is different when configuring the rejection in the Tor configuration that gets published.
As far as I know, there is no case law, so results may differ.
Thanks, Rejo (and others) for elucidating the point. I now get your line of thought.
I learned that the qualification "not select or modify" acually IS present in German law. § 8 TMG says, that the service provider is not responsible in so far as he did not "chose or modify" the transmitted information.
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility. I'd rather pessimistically guess that most courts would judge tor operators in analogy to people operating private open wireless access points ...
++ 21/10/14 01:58 +0200 - Manuel Gebauer:
I learned that the qualification "not select or modify" acually IS present in German law. § 8 TMG says, that the service provider is not responsible in so far as he did not "chose or modify" the transmitted information.
As the e-Commerce directive is a directive (duh!) and not a regulation, this European rules need to be transposed to national laws in each every member state. The Dutch also have their own version.
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but
[...]
That's right. Like I said: there is no case law, but it would be a most interesting case.
Manuel Gebauer manuel@myops.de wrote:
I learned that the qualification "not select or modify" acually IS present in German law. § 8 TMG says, that the service provider is not responsible in so far as he did not "chose or modify" the transmitted information.
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility.
Citation needed.
As far as precedence is concerned, I believe that all the Tor-related raids in Germany (that I became aware of) ended with the state attorney closing the investigation (against the Tor operator) after finally realising that the offending traffic came through Tor.
Fabian
I learned that the qualification "not select or modify" acually IS present in German law. § 8 TMG says, that the service provider is not responsible in so far as he did not "chose or modify" the transmitted information.
[..]
As far as precedence is concerned, I believe that all the Tor-related raids in Germany (that I became aware of) ended with the state attorney closing the investigation (against the Tor operator) after finally realising that the offending traffic came through Tor.
[..]
Is the TMG law even used/relevant in Tor cases here in Germany? I don't have quotes or sources but if I remember correctly this specific law was never part of the closure.
Renke
Hi Fabian,
Quoting Fabian Keil (2014-10-21 12:55:21)
Manuel Gebauer manuel@myops.de wrote:
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility.
Citation needed.
"Für ein schlecht gesichertes WLAN besteht Störerhaftung." BGH, Urteil v. 12.05.2010, Az. I ZR 121/08, Link: http://tlmd.in/u/1057
I cant't of course cite missing precedence concerning tor, because it is missing.
As far as precedence is concerned, I believe that all the Tor-related raids in Germany (that I became aware of) ended with the state attorney closing the investigation (against the Tor operator) after finally realising that the offending traffic came through Tor.
Citation needed. :)
On 10/21/2014 10:29 PM, Manuel Gebauer wrote:
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility.
Citation needed.
"Für ein schlecht gesichertes WLAN besteht Störerhaftung." BGH, Urteil v. 12.05.2010, Az. I ZR 121/08, Link: http://tlmd.in/u/1057
Don't confuse Internet ACCESS Providers and Internet Service Providers. Legally, they're looked at quite different. And a "wifi with bad security" does not even mean you can't offer a completely open wifi. Any layman with a bit of sense could have known that to argue that the wifi was misconfigured "by mistake" is a bad excuse.
To come back to the topic, I believe it is perfectly fine to announce _in advance_ that your relay does not want to see/relay particular traffic. Then, it is not a question of interfering with traffic, since you don't see that kind of traffic at all. It's different if you stop dropping packets on purpose.
++ 21/10/14 22:29 +0200 - Manuel Gebauer:
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility.
Citation needed.
"Für ein schlecht gesichertes WLAN besteht Störerhaftung." BGH, Urteil v. 12.05.2010, Az. I ZR 121/08, Link:
A "schlecht gesichertes WLAN" is, of course, something else than a deliberately opened router. The intentions of the owner a different, for a starter. Anyway, I am not sure whether this is worth a discussion or debate on this list.
On 10/19/2014 03:48 PM, obx wrote:
Same here, I've blacklisted their /24 in my torrc. The complaints stopped.
Did the same after I got those complaints.
B/c my provider do open for every complaint a ticket I do not have another chance than doing this: reject 217.112.0.0/16:*
On 10/19/2014 01:24 PM, Kees Goossens wrote:
Lesson (for me at least): since HTTP was used, even a very reduced exit policy is does not make one immune to abuse problems. At this point I reverted back to being a non-exit relay, as I have no interest in having to deal with this.
Well, no need to give up - I made similar experiences with the reduced exit policy. Even then my provider's inbox was hammered with DMCA mails. But what worked (for me) is a further reduced policy containing ports below 1024 + few above. Said that this works for me till now:
# un-comment the next line to disallow exits # #ExitPolicy reject *:*
# abuse mails # ExitPolicy reject 217.112.0.0/16:* # AbuseID:11F39E:22 7th October 2014
# allowed exits # ExitPolicy accept *:43 # whois ExitPolicy accept *:53 # dns ExitPolicy accept *:80 # http ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # pop3 ExitPolicy accept *:143 # imap ExitPolicy accept *:194 # irc ExitPolicy accept *:220 # imap3 ExitPolicy accept *:389 # ldap ExitPolicy accept *:443 # http ssl ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:543-544 # kerberos ExitPolicy accept *:531 # irc/aim ExitPolicy accept *:563 # nntp ssl ExitPolicy accept *:636 # ldap ssl ExitPolicy accept *:749 # kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept *:993 # imap ssl ExitPolicy accept *:994 # irc ssl ExitPolicy accept *:995 # pop3 ssl ExitPolicy accept *:6660-6669 # irc ExitPolicy accept *:6679 # irc ssl ExitPolicy accept *:6697 # irc ssl ExitPolicy accept *:11371 # OpenPGP hkp
# reject everyting else # ExitPolicy reject *:*
tor-relays@lists.torproject.org