- tor-relays - lists.torproject.org

Re: [tor-relays] [tor-talk] obfsproxy failure: obfs3
by lee colleton 22 Aug '13

22 Aug '13

here's that email again in plain text (previously held for moderation due to message size) On Thu, Aug 22, 2013 at 3:13 AM, lee colleton <lee(a)colleton.net> wrote: > > here's both "netstat - tulpen" and "netstat -tulpen" > > lee@tor-bootstrap:~$ netstat - tulpen > Active Internet connections (w/o servers) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 256 tor-bootstrap.c.tor:ssh li388-156.members:39392 ESTABLISHED > tcp 0 0 tor-bootstrap.c.t:45903 grn-it.gnuradionet:9001 ESTABLISHED > tcp 0 0 tor-bootstrap.c.t:48994 torproxy02.teamcym:9001 ESTABLISHED > tcp 0 0 tor-bootstrap.c.t:46128 xray275.server4you:9001 TIME_WAIT > tcp 0 0 tor-bootstrap.c.t:47652 metadata.google.in:http TIME_WAIT > tcp 0 0 tor-bootstrap.c.t:47654 metadata.google.in:http ESTABLISHED > tcp 0 48 tor-bootstrap.c.tor:ssh li388-156.members:34711 ESTABLISHED > tcp 0 0 tor-bootstrap.c.t:41250 metadata.google.in:http ESTABLISHED > tcp 0 0 tor-bootstrap.c.t:56064 static.68.158.9.5.:9001 ESTABLISHED > Active UNIX domain sockets (w/o servers) > Proto RefCnt Flags Type State I-Node Path > unix 2 [ ] DGRAM 283 @google-simple-watchdog > unix 8 [ ] DGRAM 2235 /dev/log > unix 3 [ ] STREAM CONNECTED 1765015 > unix 3 [ ] STREAM CONNECTED 1765014 > unix 2 [ ] DGRAM 1765013 > unix 3 [ ] STREAM CONNECTED 1735417 > unix 3 [ ] STREAM CONNECTED 1735416 > unix 3 [ ] STREAM CONNECTED 17047 /var/run/tor/control > unix 3 [ ] STREAM CONNECTED 17046 > unix 2 [ ] DGRAM 17019 > unix 2 [ ] DGRAM 17016 > unix 3 [ ] STREAM CONNECTED 16926 > unix 3 [ ] STREAM CONNECTED 16925 > unix 3 [ ] STREAM CONNECTED 6135 > unix 3 [ ] STREAM CONNECTED 6134 > unix 2 [ ] DGRAM 6133 > unix 2 [ ] DGRAM 2658 > unix 2 [ ] DGRAM 2541 > unix 2 [ ] DGRAM 2479 > unix 3 [ ] DGRAM 553 > unix 3 [ ] DGRAM 552 > lee@tor-bootstrap:~$ netstat -tulpen > (No info could be read for "-p": geteuid()=1000 but you should be root.) > Active Internet connections (only servers) > Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name > tcp 0 0 0.0.0.0:40872 0.0.0.0:* LISTEN 103 16963 - > tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 0 16931 - > tcp 0 0 0.0.0.0:52176 0.0.0.0:* LISTEN 103 16970 - > tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 2727 - > tcp6 0 0 :::22 :::* LISTEN 0 2729 - > udp 0 0 0.0.0.0:68 0.0.0.0:* 0 2108 - > udp 0 0 0.0.0.0:55889 0.0.0.0:* 0 2086 - > udp 0 0 10.240.245.45:123 0.0.0.0:* 0 2674 - > udp 0 0 127.0.0.1:123 0.0.0.0:* 0 2673 - > udp 0 0 0.0.0.0:123 0.0.0.0:* 0 2666 - > udp6 0 0 :::123 :::* 0 2667 - > udp6 0 0 :::55026 :::* 0 2087 - > lee@tor-bootstrap:~$ > > > > On Thu, Aug 22, 2013 at 3:02 AM, Admin <webmaster(a)afo-tm.org> wrote: >> >> Looks like nothing does listen on port 443 can you post the output of "netstat - tulpen"? >> >> Am 22.08.2013 00:42 schrieb "lee colleton" <lee(a)colleton.net>: >>> >>> I'm still having trouble connecting to my obfsproxy bridge; Any pointers would be appreciated. External scanning indicates that the correct ports are open except for port 443 but it's definitely open on the firewall. >>> >>> lee@li388-156:~$ nmap -p 22,443,9001,40872,52176 173.255.119.202 >>> >>> Starting Nmap 5.21 ( http://nmap.org ) at 2013-08-21 16:44 EDT >>> Nmap scan report for 202.119.255.173.bc.googleusercontent.com (173.255.119.202) >>> Host is up (0.16s latency). >>> PORT STATE SERVICE >>> 22/tcp open ssh >>> 443/tcp closed https >>> 9001/tcp open tor-orport >>> 40872/tcp open unknown >>> 52176/tcp open unknown >>> >>> lee@li388-156:~$ openssl s_client -showcerts -connect 173.255.119.202:443 >>> connect: Connection refused >>> connect:errno=111 >>> >>> maybe this? https://trac.torproject.org/projects/tor/ticket/5104 >>> >>> Confirming that 443 is accessible: >>> >>> lee@tor-bootstrap:~$ sudo python -m SimpleHTTPServer 443 >>> >>> Serving HTTP on 0.0.0.0 port 443 ... >>> 106.187.45.156 - - [21/Aug/2013 22:39:16] code 400, message Bad request syntax ('\x16\x03\x01\x00\xdc\x01\x00\x00\xd8\x03\x02R\x15A\x94\xc5\xfc\xc1(\x04O\xe0\xee@\x92d\x17.\xd9N\xa1Q\xb3$_\xa6H\xc6adp\xa11\x00\x00f\xc0\x14\xc0') >>> 106.187.45.156 - - [21/Aug/2013 22:39:16] " � � R A��( O��@�d .�N�Q�$_�H�adp�1f� �" 400 - >>> >>> lee@li388-156:~$ openssl s_client -showcerts -connect 173.255.119.202:443 >>> CONNECTED(00000003) >>> 140181545842336:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:749: >>> --- >>> no peer certificate available >>> --- >>> No client certificate CA names sent >>> --- >>> SSL handshake has read 7 bytes and written 225 bytes >>> --- >>> New, (NONE), Cipher is (NONE) >>> Secure Renegotiation IS NOT supported >>> Compression: NONE >>> Expansion: NONE >>> --- >>> >>> >>> >>> >>> On Thu, Aug 15, 2013 at 10:14 AM, lee colleton <lee(a)colleton.net> wrote: >>>> >>>> -tor-relay >>>> +tor-relays >>>> >>>> >>>> On Thu, Aug 15, 2013 at 10:13 AM, lee colleton <lee(a)colleton.net> wrote: >>>>> >>>>> All of the ports respond on the external IP except for 443 but I can connect via SSL on 9001. I don't understand how ORListenAddress is supposed to work: my bridge times out on 443 but when I comment out the ORListenAddress line it doesn't connect via obfsproxy at all. >>>>> >>>>> Please advise. >>>>> >>>>> >>>>> On Thu, Aug 15, 2013 at 1:47 AM, lee colleton <lee(a)colleton.net> wrote: >>>>>> >>>>>> With the ORListenAddress line uncommented, a slightly different failure results: >>>>>> >>>>>> Orbot is starting… >>>>>> Orbot is starting… >>>>>> got tor proc id: 28490 >>>>>> Tor process id=28490 >>>>>> >>>>>> Connecting to control port: 9051 >>>>>> SUCCESS connected to control port >>>>>> SUCCESS authenticated to control port >>>>>> Starting Tor client… complete. >>>>>> adding control port event handler >>>>>> SUCCESS added control port event handler >>>>>> Starting privoxy process >>>>>> /data/data/org.torproject.android/app_bin/privoxy /data/data/org.torproject.android/app_bin/privoxy.config & >>>>>> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. I've sent 0 kB and received 0 kB. >>>>>> Privoxy is running on port:8118 >>>>>> Privoxy process id=28508 >>>>>> >>>>>> Network connectivity is good. Waking Tor up... >>>>>> Circuit (1) LAUNCHED: >>>>>> NOTICE: Bootstrapped 5%: Connecting to directory server. >>>>>> orConnStatus (173.255.119.202:443): LAUNCHED >>>>>> NOTICE: Bootstrapped 10%: Finishing handshake with directory server. >>>>>> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY >>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit) >>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> >>>>>> On Aug 15, 2013 1:41 AM, "lee colleton" <lee(a)colleton.net> wrote: >>>>>>> >>>>>>> When I attempt to connect to this bridge, I see a failure in handshaking: >>>>>>> >>>>>>> Orbot is starting… >>>>>>> Orbot is starting… >>>>>>> got tor proc id: 27365 >>>>>>> Tor process id=27365 >>>>>>> Connecting to control port: 9051 >>>>>>> SUCCESS connected to control port >>>>>>> SUCCESS authenticated to control port >>>>>>> Starting Tor client… complete. >>>>>>> adding control port event handler >>>>>>> SUCCESS added control port event handler >>>>>>> Starting privoxy process >>>>>>> /data/data/org.torproject.android/app_bin/privoxy /data/data/org.torproject.android/app_bin/privoxy.config & >>>>>>> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. I've sent 0 kB and received 0 kB. >>>>>>> Privoxy is running on port:8118 >>>>>>> Privoxy process id=27393 >>>>>>> Network connectivity is good. Waking Tor up... >>>>>>> Circuit (1) LAUNCHED: >>>>>>> NOTICE: Bootstrapped 5%: Connecting to directory server. >>>>>>> orConnStatus (173.255.119.202:443): LAUNCHED >>>>>>> NOTICE: Bootstrapped 10%: Finishing handshake with directory server. >>>>>>> NOTICE: We weren't able to find support for all of the TLS ciphersuites that we wanted to advertise. This won't hurt security, but it might make your Tor (if run as a client) more easy for censors to block. >>>>>>> NOTICE: To correct this, use a more recent OpenSSL, built without disabling any secure ciphers or features. >>>>>>> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY >>>>>>> orConnStatus (173.255.119.202:443): FAILED >>>>>>> WARN: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 1; recommendation warn) >>>>>>> WARN: 1 connections have failed: >>>>>>> WARN: 1 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE >>>>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>>> >>>>>>> On Aug 15, 2013 12:31 AM, "lee colleton" <lee(a)colleton.net> wrote: >>>>>>>> >>>>>>>> When I comment out the ORListenAddress line things look OK. >>>>>>>> >>>>>>>> # Listen on a port other than the one advertised in ORPort (that is, >>>>>>>> # advertise 443 but bind to 9001). >>>>>>>> #ORListenAddress 0.0.0.0:9001 >>>>>>>> >>>>>>>> Aug 15 06:52:50.000 [notice] Tor 0.2.4.16-rc (git-dcf6b6d7dda9ffbd) opening log file. >>>>>>>> Aug 15 06:52:50.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. >>>>>>>> Aug 15 06:52:50.000 [notice] Your Tor server's identity key fingerprint is 'gcedemo 08C752E8E86EB5916574A8625030B0EC204EABB8' >>>>>>>> Aug 15 06:52:50.000 [notice] Configured hibernation. This interval began at 2013-08-15 00:00:00; the scheduled wake-up time was 2013-08-15 00:00:00; we expect to exhaust our quota for this interval around 2013-08-16 00:00:00; the next interval begins at 2013-08-16 00:00:00 (all times local) >>>>>>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. >>>>>>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. >>>>>>>> Aug 15 06:52:50.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. >>>>>>>> Aug 15 06:52:51.000 [notice] We now have enough directory information to build circuits. >>>>>>>> Aug 15 06:52:51.000 [notice] Bootstrapped 80%: Connecting to the Tor network. >>>>>>>> Aug 15 06:52:52.000 [notice] Bootstrapped 85%: Finishing handshake with first hop. >>>>>>>> Aug 15 06:52:53.000 [notice] Guessed our IP address as 173.255.119.202 (source: 38.229.70.33). >>>>>>>> Aug 15 06:52:53.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. >>>>>>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs3' at '0.0.0.0:40872' >>>>>>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:52176' >>>>>>>> Aug 15 06:52:55.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. >>>>>>>> Aug 15 06:52:55.000 [notice] Bootstrapped 100%: Done. >>>>>>>> Aug 15 06:52:55.000 [notice] Now checking whether ORPort 173.255.119.202:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) >>>>>>>> Aug 15 06:53:04.000 [notice] New control connection opened. >>>>>>>> Aug 15 07:10:11.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 14, 2013 at 9:53 PM, lee colleton <lee(a)colleton.net> wrote: >>>>>>>>> >>>>>>>>> Yes, I've opened the ports in the Google Compute Engine (see below). I'll follow up on their forum to make sure I've altered the firewall properly. >>>>>>>>> >>>>>>>>> --lee >>>>>>>>> >>>>>>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" --project="colleton.net:tor-cloud" listfirewalls >>>>>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>>>>>> | name | description | network | source-ips | source-tags | target-tags | >>>>>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>>>>>> | default-allow-internal | Internal traffic from default allowed | default | 10.0.0.0/8 | | | >>>>>>>>> | default-ssh | SSH allowed from anywhere | default | 0.0.0.0/0 | | | >>>>>>>>> | tor-obfsproxy | | default | 0.0.0.0/0 | | obfsproxy | >>>>>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>>>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" --project="colleton.net:tor-cloud" getfirewall tor-obfsproxy >>>>>>>>> +---------------+-------------------------------+ >>>>>>>>> | property | value | >>>>>>>>> +---------------+-------------------------------+ >>>>>>>>> | name | tor-obfsproxy | >>>>>>>>> | description | | >>>>>>>>> | creation-time | 2013-08-07T18:37:35.986-07:00 | >>>>>>>>> | network | default | >>>>>>>>> | source-ips | 0.0.0.0/0 | >>>>>>>>> | source-tags | | >>>>>>>>> | target-tags | obfsproxy | >>>>>>>>> | allowed | tcp: 443, 9001, 40872, 52176 | >>>>>>>>> +---------------+-------------------------------+ >>>>>>>>> lee@li388-156:~$ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 14, 2013 at 9:19 PM, Roger Dingledine <arma(a)mit.edu> wrote: >>>>>>>>>> >>>>>>>>>> On Wed, Aug 14, 2013 at 09:08:03AM -0700, lee colleton wrote: >>>>>>>>>> > There's a more serious issue in that my server doesn't appear to be >>>>>>>>>> > reachable. I've opened tcp:443,9001 along with the two specifiedobfsproxy >>>>>>>>>> > ports >>>>>>>>>> > >>>>>>>>>> > Aug 14 15:26:58.000 [notice] Bootstrapped 100%: Done. >>>>>>>>>> > Aug 14 15:26:58.000 [notice] Now checking whether ORPort >>>>>>>>>> > 173.255.119.202:443 is reachable... (this may take up to 20 minutes -- >>>>>>>>>> > look for log messages indicating success) >>>>>>>>>> > Aug 14 15:28:00.000 [notice] New control connection opened. >>>>>>>>>> > Aug 14 15:46:56.000 [warn] Your server (173.255.119.202:443) has not >>>>>>>>>> > managed to confirm that its ORPort is reachable. Please check your >>>>>>>>>> > firewalls, ports, address, /etc/hosts file, etc. >>>>>>>>>> >>>>>>>>>> Well, that's because it's unreachable. (I just tried.) >>>>>>>>>> >>>>>>>>>> Can you try following the suggestion in the log message? >>>>>>>>>> >>>>>>>>>> --Roger >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> tor-talk mailing list - tor-talk(a)lists.torproject.org >>>>>>>>>> To unsusbscribe or change other settings go to >>>>>>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >

1 0

Config Tor Exit Node
by var 22 Aug '13

22 Aug '13

Hi guys, we moved from a Win to Linux with our tor exit node. The win was running fine no problems since we are running the the exit node on a Debian wheezy we got in trouble. The exit node is installed and configured with the how to on the official Tor website. The exit node is directly plugged in to the gateway. Its an DIR-655 <http://support.dlink.com.tw/> which just have to run our internet traffic + the tor exit node. Here is the torrc file: > http://pastebin.com/QsZ3UJPA Problem is that when the node is running i lose my internet on every other PC around. Connection is still there but it take years to resolve the names....so i figured it must be an DNS problem. I hope you can help us. Thanks in advance VarVarna

3 2

TOR Exit Node trouble
by var 22 Aug '13

22 Aug '13

The exit node got an internal IP address...but bounds normally on the outside address. 192.168.0.5 192.168.01 88.77.66.33 Exit node -----------> Router------------> Internet But if i do a look up on different Tor service site the find the Exit node and give it the external IP address.

2 1

Re: [tor-relays] Key files encryption methods.
by tor＠t-3.net 22 Aug '13

22 Aug '13

I have something to add to this. I'm a new relay operator, but not new to server hosting in general. People should be aware that some providers of vservers run their internal operations by using a large-capacity storage box for the disk storage, and separate hardware hosts which run the cpu/memory/operationals of the vservers. The disk storage is accessed by a private network and would tend to be reached by the servers through a manageable switch. At least on Linux platform, the protocol I have seen the hosts talk to the disk box with is NFS. The core of NFS is unencrypted. In a server farm environment where one is keeping the traffic all on a private switch like that on private IP space, the operator would not tend to tunnel those host NFS connections over SSH. An operator is looking for speed and throughput in that environment, and SSH tunneling would decrease both. It is assumed that passing the traffic through the private switch isn't a meaningful security concern. What that means to tor server operators is that if you're using a vserver where the internals are set up this way, the unencrypted contents of your disk are likely being exposed to a managed switch. That switch could potentially be used to examine or redirect traffic. This is a real concern, not a theoretical one. Security procedures on the key handling should take into account this sort of situation, where it may exist. (In my case I get to choose which way I want the vserver - and with that, I'll be taking my new tor server offline for a little while for a re-implementation :/ ). On Wednesday 21/08/2013 at 7:24 am, Moritz Bartl wrote: > On 21.08.2013 11:56, Tony Xue wrote: >> >> Is that those key files are only loaded when the Tor start and reload? >> So could it be possible to decrypt the file before the start-up and >> encrypt them again after the Tor start-up process is complete? > > The files are required only on startup of the relay, so you can keep > them stored wherever (offsite, in an encrypted container, ...), and > remove them from the live system after you start Tor. > > https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity > > -- > Moritz Bartl > https://www.torservers.net/ > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] [tor-talk] obfsproxy failure: obfs3
by lee colleton 22 Aug '13

22 Aug '13

-tor-relay +tor-relays On Thu, Aug 15, 2013 at 10:13 AM, lee colleton <lee(a)colleton.net> wrote: > All of the ports respond on the external IP except for 443 but I can > connect via SSL on 9001. I don't understand how ORListenAddress is > supposed to work: my bridge times out on 443 but when I comment out the ORListenAddress > line it doesn't connect via obfsproxy at all. > > Please advise. > > > On Thu, Aug 15, 2013 at 1:47 AM, lee colleton <lee(a)colleton.net> wrote: > >> With the ORListenAddress line uncommented, a slightly different failure >> results: >> >> Orbot is starting… >> Orbot is starting… >> got tor proc id: 28490 >> Tor process id=28490 >> >> Connecting to control port: 9051 >> SUCCESS connected to control port >> SUCCESS authenticated to control port >> Starting Tor client… complete. >> adding control port event handler >> SUCCESS added control port event handler >> Starting privoxy process >> /data/data/org.torproject.android/app_bin/privoxy >> /data/data/org.torproject.android/app_bin/privoxy.config & >> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. I've >> sent 0 kB and received 0 kB. >> Privoxy is running on port:8118 >> Privoxy process id=28508 >> >> Network connectivity is good. Waking Tor up... >> Circuit (1) LAUNCHED: >> NOTICE: Bootstrapped 5%: Connecting to directory server. >> orConnStatus (173.255.119.202:443): LAUNCHED >> NOTICE: Bootstrapped 10%: Finishing handshake with directory server. >> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY >> NOTICE: Your application (using socks4a to port 443) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 80) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 443) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 80) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 443) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 80) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 443) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Tried for 120 seconds to get a connection to [scrubbed]:443. >> Giving up. (waiting for circuit) >> NOTICE: Your application (using socks4a to port 443) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> >> On Aug 15, 2013 1:41 AM, "lee colleton" <lee(a)colleton.net> wrote: >> >>> When I attempt to connect to this bridge, I see a failure in handshaking: >>> >>> Orbot is starting… >>> Orbot is starting… >>> got tor proc id: 27365 >>> Tor process id=27365 >>> Connecting to control port: 9051 >>> SUCCESS connected to control port >>> SUCCESS authenticated to control port >>> Starting Tor client… complete. >>> adding control port event handler >>> SUCCESS added control port event handler >>> Starting privoxy process >>> /data/data/org.torproject.android/app_bin/privoxy >>> /data/data/org.torproject.android/app_bin/privoxy.config & >>> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. >>> I've sent 0 kB and received 0 kB. >>> Privoxy is running on port:8118 >>> Privoxy process id=27393 >>> Network connectivity is good. Waking Tor up... >>> Circuit (1) LAUNCHED: >>> NOTICE: Bootstrapped 5%: Connecting to directory server. >>> orConnStatus (173.255.119.202:443): LAUNCHED >>> NOTICE: Bootstrapped 10%: Finishing handshake with directory server. >>> NOTICE: We weren't able to find support for all of the TLS ciphersuites >>> that we wanted to advertise. This won't hurt security, but it might make >>> your Tor (if run as a client) more easy for censors to block. >>> NOTICE: To correct this, use a more recent OpenSSL, built without >>> disabling any secure ciphers or features. >>> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY >>> orConnStatus (173.255.119.202:443): FAILED >>> WARN: Problem bootstrapping. Stuck at 10%: Finishing handshake with >>> directory server. (DONE; DONE; count 1; recommendation warn) >>> WARN: 1 connections have failed: >>> WARN: 1 connections died in state handshaking (TLS) with SSL state >>> SSLv2/v3 read server hello A in HANDSHAKE >>> NOTICE: Your application (using socks4a to port 80) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Your application (using socks4a to port 443) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Your application (using socks4a to port 80) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> On Aug 15, 2013 12:31 AM, "lee colleton" <lee(a)colleton.net> wrote: >>> >>>> When I comment out the ORListenAddress line things look OK. >>>> >>>> # Listen on a port other than the one advertised in ORPort (that is, >>>> # advertise 443 but bind to 9001). >>>> #ORListenAddress 0.0.0.0:9001 >>>> >>>> Aug 15 06:52:50.000 [notice] Tor 0.2.4.16-rc (git-dcf6b6d7dda9ffbd) opening log file. >>>> Aug 15 06:52:50.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. >>>> Aug 15 06:52:50.000 [notice] Your Tor server's identity key fingerprint is 'gcedemo 08C752E8E86EB5916574A8625030B0EC204EABB8' >>>> Aug 15 06:52:50.000 [notice] Configured hibernation. This interval began at 2013-08-15 00:00:00; the scheduled wake-up time was 2013-08-15 00:00:00; we expect to exhaust our quota for this interval around 2013-08-16 00:00:00; the next interval begins at 2013-08-16 00:00:00 (all times local) >>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. >>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. >>>> Aug 15 06:52:50.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. >>>> Aug 15 06:52:51.000 [notice] We now have enough directory information to build circuits. >>>> Aug 15 06:52:51.000 [notice] Bootstrapped 80%: Connecting to the Tor network. >>>> Aug 15 06:52:52.000 [notice] Bootstrapped 85%: Finishing handshake with first hop. >>>> Aug 15 06:52:53.000 [notice] Guessed our IP address as 173.255.119.202 (source: 38.229.70.33). >>>> Aug 15 06:52:53.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. >>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs3' at '0.0.0.0:40872' >>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:52176' >>>> Aug 15 06:52:55.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. >>>> Aug 15 06:52:55.000 [notice] Bootstrapped 100%: Done. >>>> Aug 15 06:52:55.000 [notice] Now checking whether ORPort 173.255.119.202:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) >>>> Aug 15 06:53:04.000 [notice] New control connection opened. >>>> Aug 15 07:10:11.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. >>>> >>>> >>>> >>>> On Wed, Aug 14, 2013 at 9:53 PM, lee colleton <lee(a)colleton.net> wrote: >>>> >>>>> Yes, I've opened the ports in the Google Compute Engine (see below). >>>>> I'll follow up on their forum to make sure I've altered the firewall >>>>> properly. >>>>> >>>>> --lee >>>>> >>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" --project="colleton.net:tor-cloud" listfirewalls >>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>> | name | description | network | source-ips | source-tags | target-tags | >>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>> | default-allow-internal | Internal traffic from default allowed | default | 10.0.0.0/8 | | | >>>>> | default-ssh | SSH allowed from anywhere | default | 0.0.0.0/0 | | | >>>>> | tor-obfsproxy | | default | 0.0.0.0/0 | | obfsproxy | >>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" --project="colleton.net:tor-cloud" getfirewall tor-obfsproxy >>>>> +---------------+-------------------------------+ >>>>> | property | value | >>>>> +---------------+-------------------------------+ >>>>> | name | tor-obfsproxy | >>>>> | description | | >>>>> | creation-time | 2013-08-07T18:37:35.986-07:00 | >>>>> | network | default | >>>>> | source-ips | 0.0.0.0/0 | >>>>> | source-tags | | >>>>> | target-tags | obfsproxy | >>>>> | allowed | tcp: 443, 9001, 40872, 52176 | >>>>> +---------------+-------------------------------+ >>>>> lee@li388-156:~$ >>>>> >>>>> >>>>> >>>>> On Wed, Aug 14, 2013 at 9:19 PM, Roger Dingledine <arma(a)mit.edu>wrote: >>>>> >>>>>> On Wed, Aug 14, 2013 at 09:08:03AM -0700, lee colleton wrote: >>>>>> > There's a more serious issue in that my server doesn't appear to be >>>>>> > reachable. I've opened tcp:443,9001 along with the two >>>>>> specifiedobfsproxy >>>>>> > ports >>>>>> > >>>>>> > Aug 14 15:26:58.000 [notice] Bootstrapped 100%: Done. >>>>>> > Aug 14 15:26:58.000 [notice] Now checking whether ORPort >>>>>> > 173.255.119.202:443 is reachable... (this may take up to 20 >>>>>> minutes -- >>>>>> > look for log messages indicating success) >>>>>> > Aug 14 15:28:00.000 [notice] New control connection opened. >>>>>> > Aug 14 15:46:56.000 [warn] Your server (173.255.119.202:443) has >>>>>> not >>>>>> > managed to confirm that its ORPort is reachable. Please check your >>>>>> > firewalls, ports, address, /etc/hosts file, etc. >>>>>> >>>>>> Well, that's because it's unreachable. (I just tried.) >>>>>> >>>>>> Can you try following the suggestion in the log message? >>>>>> >>>>>> --Roger >>>>>> >>>>>> -- >>>>>> tor-talk mailing list - tor-talk(a)lists.torproject.org >>>>>> To unsusbscribe or change other settings go to >>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >>>>>> >>>>> >>>>> >>>> >

1 1

Experience with obfuscated bridge on Raspberry Pi Raspian
by z0rc 21 Aug '13

21 Aug '13

Hi, As lately there were many discussions on getting Tor from the experimental repository running on Raspian, I thought I would share my experiences here. First, I tried to install Tor following [1] and [2] and ran into the same compatibility issues as most of you. But then I just downloaded the soft-float version of Raspian "wheezy" from [3]. And I could install Tor and obsproxy from the experimental repository without any issues (i.e. without any compiling or complex configurations). I ran the obfuscated bridge for a week and it relayed a few 100 MB without any problems. The bridge is connected to a standard home cable connection in Switzerland (router runs pfSense). Of course the load was not too high due to only running an obfuscated bridge. After the week I decided to shut the bridge down because I heard from people being contacted by the police even though only running a non-exit relay. As I share a flat with some friends, I absolutely cannot afford being raided or similar. If anyone can give me some advice on running non-exit relays at home in Switzerland, I might consider running the bridge again. Hope this helps. Cheers, Damian [1] https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en#i… [2] https://www.torproject.org/docs/debian.html.en#development [3] http://www.raspberrypi.org/downloads

4 5

Key files encryption methods.
by Tony Xue 21 Aug '13

21 Aug '13

Hi, As shown on the Tor website, the most important file of Tor is the key files. So is there any efficient way to encrypt those files in order to prevent anyone else, i.e. Hosting provider, getting and reading them? Is that those key files are only loaded when the Tor start and reload? So could it be possible to decrypt the file before the start-up and encrypt them again after the Tor start-up process is complete? Cheers, Tony

2 1

Upgrading an obfsbridge to the latest alpha on git master, on raspberry pi
by Kostas Jakeliunas 21 Aug '13

21 Aug '13

A few days ago, George posted an invitation for obfsproxy operators to upgrade their Tor software to the latest version on the master branch in the Tor git repo. [1] I'm running a low traffic obfsbridge on a raspberry pi, the whole thing is rather experimental in its nature already, so decided to try just that. Presumably everyone for whom this might be relevant already knows these things much better than myself, but since they might be applicable to all/some Debian users (raspberrypi + raspbian/debian users for sure), i'm outlining a couple of snags that can maybe be avoided. Previously I ran 0.2.4.15-rc compiled from deb-src (http://deb.torproject.org/torproject.orgexperimental-wheezy main); I think it'd have been the same if a precompiled package had been used. I'd still like to be able to manage Tor via init scripts with as little change as possible, etc. TL;DR: - after make && make install, do a whereis tor; in all likelihood, your new version will be at /usr/local/bin/tor, old one at /usr/sbin/tor etc.; /etc/init.d/tor will be using /usr/sbin/tor, so need to change the DAEMON key there - torrc-defaults will have different values in different distro packages. cd /usr/local/etc/tor; if there's no torrc there: sudo ln -s /etc/tor/torrc (presumably that's where you kept your torrc before; ~/.torrc should work in any case) $ git clone https://git.torproject.org/tor.git && cd tor $ ./autogen.sh if it complains about no aclocal (et al.): $ sudo apt-get install automake && ./autogen.sh $ ./configure $ make $ sudo make install # or, just use it like that (Tor binary is in src/or/) If you're using service tor {start,stop,reload,etc}: $ /usr/sbin/tor --version; /usr/local/bin/tor --version $ grep DAEMON= /etc/init.d/tor The latter will likely point to /usr/sbin/tor, which might be outdated (check above). If that's the case, change that line in init.d/tor to point to the new Tor executable /usr/local/bin/tor - that's where it *should* be; if you don't like that, change BINDIR = /usr/local/bin in Tor's Makefile and make install again. The Debian Tor packages seem to like to assume torrc will be placed in /etc/tor/torrc. If that's where your torrc resides, make a symlink to it from /usr/local/etc/tor, which is where the new Tor executable will look for it. This is probably an insanely ugly way of dealing with these snags, but if anyone is reserved to upgrade because of things like that, maybe this'll help someone.. Kostas. [1]: https://lists.torproject.org/pipermail/tor-relays/2013-August/002477.html

2 2

Re: [tor-relays] Experience with obfuscated bridge on Raspberry Pi Raspian
by TonyXue 20 Aug '13

20 Aug '13

>China's internet censorship / 'firewall' thing seems to have been trying to enumerate bridges for a while now. Yes, it does. I guess it's actually detecting bridges from users. The bridges become 'one-off', you can only use those bridges one time(at least in a period of time) and the second time you try to connect through the same bridges, it won't work. From: tony.x(a)outlook.com To: tor-relays(a)lists.torproject.org Subject: RE: [tor-relays] Experience with obfuscated bridge on Raspberry Pi Raspian Date: Tue, 20 Aug 2013 18:42:41 +0800 >China's internet censorship / 'firewall' thing seems to have been trying to enumerate bridges for a while now. Yes, it does. I guess it's actually detecting bridges from users. The bridges become 'one-off', you can only use those bridges one time(at least in a period of time) and the second time you try to connect through the same bridges, it won't work. From: kostas(a)jakeliunas.com Date: Tue, 20 Aug 2013 13:01:35 +0300 To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Experience with obfuscated bridge on Raspberry Pi Raspian Thanks for sharing your experience! > After the week I decided to shut the bridge down because I heard from people being contacted by the police even though only running a non-exit relay. Do you remember where you did hear this? Was it in writing, are you by chance maybe able to link to it? It would be interesting to know more. All non-bridge relays (exit or non-exit) can be enumerated by anyone (that's by design); this is not the case with bridges. However I suppose the extent to which any potential efforts to do just that may be happening does very much depend on the jurisdiction where that bridge is being run; China's internet censorship / 'firewall' thing seems to have been trying to enumerate bridges for a while now. [1] In any case, as far as I'm concerned, it would be *really* interesting to hear of any incidents between the police and non-exit relay operators. [1]: https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors On Tue, Aug 20, 2013 at 2:00 AM, z0rc <damian.goeldi(a)gmail.com> wrote: Hi, As lately there were many discussions on getting Tor from the experimental repository running on Raspian, I thought I would share my experiences here. First, I tried to install Tor following [1] and [2] and ran into the same compatibility issues as most of you. But then I just downloaded the soft-float version of Raspian "wheezy" from [3]. And I could install Tor and obsproxy from the experimental repository without any issues (i.e. without any compiling or complex configurations). I ran the obfuscated bridge for a week and it relayed a few 100 MB without any problems. The bridge is connected to a standard home cable connection in Switzerland (router runs pfSense). Of course the load was not too high due to only running an obfuscated bridge. After the week I decided to shut the bridge down because I heard from people being contacted by the police even though only running a non-exit relay. As I share a flat with some friends, I absolutely cannot afford being raided or similar. If anyone can give me some advice on running non-exit relays at home in Switzerland, I might consider running the bridge again. Hope this helps. Cheers, Damian [1] https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en#i… [2] https://www.torproject.org/docs/debian.html.en#development [3] http://www.raspberrypi.org/downloads _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Re: [tor-relays] Raspberry Pi Relay Node Performance and future Plans on Documentation and more
by tor_bridge＠mail.md 18 Aug '13

18 Aug '13

Hello all, > For any Raspberry Pi Tor node operators breathlessly following this > thread :P I succeeded in building 0.2.4.16-rc on the Pi. We will see > how it performs now vs the circuit creation storms. me too on the pi with kernel 3.6.11, using this source: https://www.torproject.org/dist/tor-0.2.4.16-rc.tar.gz it took 32 minutes to configure and compile (make && make install). > This is not a simple Debian-type binary package install, as the > packages present in the Tor Project experimental repos are built for > *Debian* wheezy - that is, ARMv7 - and not *Raspbian* which was built > to support the ARMv6 CPU on the Pi. I'm wondering, is there any other method for running a tor bridge/relay on the raspberry pi, other than downloading the source and compiling it yourself? Is it possible for the Tor project to make an extra option on the page https://www.torproject.org/download/download-unix.html.en with instructions for people to run a bridge/relay on the Pi? I think it will help people not to spend time on installing the experimental wheezy package for the ARMv7 architecture. Tor_Bridge

8 16

Exit node move from Win to LInux
by var 18 Aug '13

18 Aug '13

Hello everybody after some trouble with our Linux Exit Node, we hope that you can point the finger at the problem. We changed from a Windows Server 2003 + Vidalia Exit Node to a Linux System. With the Windows Server everything went fine no problems. Since we got the Linux server there are a lot of problems. When the relay starts our Internet goes down. Its more like some DNS problem but i cant point the finger on it. The connection is still there but he need a lot of time to resolve the names. Is this a overkill for our router? Any suggestions? Need more info? Cheers guys&girls VarVarna

5 4

Running a relay and a bridge relay in the same time?
by TonyXue 18 Aug '13

18 Aug '13

Is that possible to configure the server to run a relay and a bridge relay in the same time? The comments in the torrc said that BridgeRelay 1 will make the server into a bridge relay. Does that mean the server will only be a bridge relay and not a relay anymore?

2 1

Re: [tor-relays] tor-relays Digest, Vol 31, Issue 23
by tw9eef 18 Aug '13

18 Aug '13

windows 2013/8/13 <tor-relays-request(a)lists.torproject.org> > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: Planningon running bridge with bw limitation - config > help (Kostas Jakeliunas) > 2. Re: Raspberry Pi Relay Node Performance and future Plans on > Documentation and more (tor_bridge(a)mail.md) > 3. Re: Raspberry Pi Relay Node Performance and future Plans on > Documentation and more (Roman Mamedov) > 4. Is it safe to run an exit node from a VPS provider? > (Sindhudweep Sarkar) > 5. Re: Raspberry Pi Relay Node Performance and future Plans on > Documentation and more (Kostas Jakeliunas) > 6. Re: Is it safe to run an exit node from a VPS provider? > (Moritz Bartl) > 7. Re: Is it safe to run an exit node from a VPS provider? > (Steve Snyder) > 8. Question about TOR bandwidth management (tor(a)t-3.net) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 13 Aug 2013 15:20:25 +0300 > From: Kostas Jakeliunas <kostas(a)jakeliunas.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Planningon running bridge with bw limitation > - config help > Message-ID: > <CAN0KoyhUfWa+W_T=x= > bcqZ+oerrnS-V0D0hPedu2mG2ywR-c9A(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Tue, Aug 13, 2013 at 2:39 PM, Moritz Bartl <moritz(a)torservers.net> > wrote: > > > On 13.08.2013 08:02, Kali Tor wrote: > > > I am actually in double minds about using obsproxy. Is there a demand > > for it? > > > > Yes! Please do set up obfsproxy. > > > Since obfsproxy bridges are usually really low traffic, I think the > combination of an obfsproxy bridge and raspberrypi makes quite a bit of > sense (that's what I'm running in any case, no problems so far (I also had > to compile Tor for armv6 from source)) :) >

1 0

mismatch between sent and received
by Dave Lahr 16 Aug '13

16 Aug '13

Hello There appears to be a growing mismatch between the amount of data sent and received for my relay. Most recent Heartbeats (in GB): sent received 8.07 10.87 7.30 10.10 6.87 9.68 6.41 9.22 6.18 8.50 This seems like something I should be concerned about, my are there GB of data that are stopping at my relay? This is not an exit relay, it is running on a raspberry pi running raspbian (debian). Any thoughts? Thank you in advance, Dave

1 0

'service tor start' not using "/etc/tor/torrc"?
by TonyXue 15 Aug '13

15 Aug '13

Hi, Today when I was using htop to check my Tor server. I found that Tor was running as "/usr/sbin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --hush" which seems Tor is not using the configuration file "/etc/tor/torrc" but the default one instead. So what should I do to let Tor use /etc/tor/torrc? I tried to use "/usr/sbin/tor -f /etc/tor/torrc --hush" but it returned that 'debain-tor' is the owner of '/var/lib/tor' not the user I was using. Tony.

3 2

Re: [tor-relays] Raspberry Pi Relay Node Performance
by Harold Naparst 14 Aug '13

14 Aug '13

I updated my Raspberry Pi to 0.2.4.16-rc as Gordon Morehouse suggested. Almost immediately I can see a big difference. I now have 700 inbound connections, 4 outbound, and 14 circuits. Before it was about 150/15/50 or so. The download and upload rates are lower than before, but that might be because I have just restarted with the new version. Any thoughts?

2 1

Planningon running bridge with bw limitation - config help
by Kali Tor 14 Aug '13

14 Aug '13

Hi all, I am planning on running a bridge-relay but have a hard 1TB/month outgoing traffic limitation. Can someone help me with a torrc config that works for this setup? Regards, Kali

7 9

Is it safe to run an exit node from a VPS provider?
by Sindhudweep Sarkar 13 Aug '13

13 Aug '13

Hi, Over the past month I've been running a tor exit relay in a spare VPS machine that I am not using. It occurs to me know that this was probably a very poor idea, as I can't control the physical access to the machine or encrypt private key. In the good bad ISPs page<https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs>, I see that some cloud providers are listed (aws, etc). This implies that such a practice is okay, but If linode or a malicious party wanted to read the contents of /var/lib/tor/keys I don't think they'd have any difficulty whatsoever. How do folks secure their relay's keys on a vps environment? Or should I shutdown this relay and run a relay only when I am sure the keys are secured? -JB

5 4

Re: [tor-relays] Is it safe to run an exit node from a VPS provider?
by Sindhudweep Sarkar 13 Aug '13

13 Aug '13

Apologies if the reply goes to the wrong location in the thread. "... At least with Xen/KVM/VMware you're running on your own virtual disk..." Can't the virtual disk just be mounted by whoever has access? I don't think this is a large barrier to entry for anyone or a script looking for private keys. I could argue that pretty much every mac user has been getting software in the form of disk images, and these possibly non-technical users seem to have no issues.

5 4

Question about TOR bandwidth management
by tor＠t-3.net 13 Aug '13

13 Aug '13

Hello, Is it possible to configure a TOR node to have different bandwidth limits at different times of day and on different days of the week? Thank you.

1 0

Raspberry Pi Relay Node Performance and future Plans on Documentation and more
by Michael Berlin 13 Aug '13

13 Aug '13

Hi Gordon and Matthias, I've split your discussion from the original thread "Running exit-node in Germany" and created a new one. I fully agree with you that the Raspberry Pi is the perfect device to let others run a Tor Relay Node very easily. What follows is a long mail about my experiences and more thoughts about the Pi as relay. On Thu, Aug 1, 2013 at 5:29 PM, Gordon Morehouse <gordon(a)morehouse.me>wrote: > Matthias Redies: > > Ok that is good to know. Right know I will probably run it on 1-1.5 Mbps > > and later on 3-4 Mbps. What is the maximum your raspberry is capable to > > do? Please let me know if you publish your tutorial. > > I had it pushing about 1.5Mbps and crashing only about once a week > before I started having TCP connect floods and had to take it offline > until I could pay attention for a while. I'm still tuning it. It > crashed much, much more often before some basic tuning, though. > I'm running a relay node on a Raspberry Pi at my VDSL home connection for several weeks now (provider "Deutsche Telekom", connection is 50mbps down, 10 up) and I didn't run into such issues so far. There're already several howtos out there which describe how to setup a relay node on the Raspberry Pi. I used this German one as starting point: http://blog.weezerle.de/2013/01/11/raspberry-pi-als-tor-server/ My current configuration has only the following two non-default options: DisableDebuggerAttachment 0 AvoidDiskWrites 1 (Plus, I run it as relay only by disabling the socks proxy with "SocksPort 0".) Here's my node: https://atlas.torproject.org/#details/5AB2F49A1B79148E3A8F52808A00451DA0084… http://globe.rndm.de/#/relay/5AB2F49A1B79148E3A8F52808A00451DA00841B1 As you can see, it forwards on average between 2-4mbps (256-512 kB/sec) and there're peaks as high as 5.5mbps (~700 kB/s). The throughput varies depending on the day of week and time of day and therefore I believe the low average isn't the Raspberry's fault. I guess, if I set a higher advertised value, then I would see a more constant throughput closer to the peak value. Currently, it's set to 10mbps: RelayBandwidthRate 1024 KB RelayBandwidthBurst 1024 KB (Note that the Pi is definitely not able to forward 10mbps of Tor traffic, but it would be great to max it out 24/7.) The logged throughput is also consistent with what I saw with the console traffic monitor "nload" (suggested command line options for nicer units and less refreshes: nload -u K -U G -t 3000). I guess, I saw even higher peaks there. Monitoring everything with "arm" is also nice but far too CPU intensive. More information about my setup: - I have the B revision with 512 MB memory - running stock Raspbian - installed "tor" package 0.2.3.25-1 from the Raspbian repository - CPU is overclocked using "raspi-config" to 950 MHz Before I overclocked the Pi, I saw a similar average throughput. When you search for "rasp" at Tor Atlas or Globe (e.g. http://globe.rndm.de/#/search/query=rasp) , you can see that there're already more than 40 devices running. My node performs quite well compared to others and I would argue that it's in the top 5 among all Raspberry Pi nodes so far. To track down possible CPU problems, we should also compare the openssl benchmark results. The Raspberry Pi wiki has some reference values: http://elinux.org/RPi_Performance#Results_3 I've attached the summary output of "openssl speed" for my overclocked Pi (950 MHz) to this mail. As you can see, the numbers are higher than the reference one (I guess probably due to overclocking and different OpenSSL version). I've also attached the log of notices of the last 4 days (unfortunately no longer logs available). Within four days there was only one "Your computer is too slow to handle this many circuit creation requests!" warning and one "Failed to hand off onionskin.". In general I would say, I haven't seen any serious issues so far. > > And my plan is to publish my results to the entire list, because at $35, > Raspberry Pis can make *great* relays for slower home broadband, but > they need a little tender loving care first. :) > > I totally agree with you. Recently, there has been quite some buzz about the OnionPi howto (http://learn.adafruit.com/onion-pi/overview) but its main goal wasn't providing a long-running relay node. In my opinion, this should get addressed separately and made as simple as possible for novices. My guess is that many people want to contribute bandwidth, but they do not want to deal with Linux specifics (and definitely do not want to get into any trouble with the police). They need a plug-and-forget solution: attach the Pi to the router and leave it running in the closet for months. If it has to be restarted, Tor Weather can send them an email. What do you think about documenting the setup of the relay in the Tor wiki? https://trac.torproject.org/projects/tor/wiki I'm not very familiar with the Tor Project yet, but to me it looks like the wiki will be the best place. Other people can contribute as well and it will be visible enough. It would be good if there's an always up-to-date wiki page which could become the reference for new users. The idea of the Raspberry Pi as relay node could be even further expanded: - Matthias already mentioned that there should be a specific image for it. I agree! - New users would prefer a simple webinterface to configure the relay (basically a Vidalia as webinterface :-) - Such a webinterface should also show statistics e.g., "Your node has forwarded 1 TB in the last 4 weeks." This will show people that their contribution made a difference and it will make them happy and more confident about it. Eventually, they'll convince others to run a relay as well. I won't have the time to realize these ideas, but maybe others want to jump in. Further work and testing could be coordinated on this mailing list? I hope to have something up in a week or two, I need to watch it for a > while and continue to tweak, and maybe develop a solution for the TCP > storms that can bring down a lot of consumer routers, before publishing > for all. > I run a regular Linux PC as router which forwards all the traffic of the Pi. The machine has more than enough CPU power and therefore I haven't seen any issues there. Since the two months that I run the relay node on the Pi, my Linux PC router has frozen twice (which didn't happen before). But I'm not sure that it can be related to the forwarding of the relay node traffic. For a broader adaption it's definitely necessary to look into the behavior of the most popular routers e.g., the ones given out by the major providers. These things could be documented on the Tor Wiki as well. Best regards, Michael

4 12

No disk space for new files created by Tor
by TonyXue 12 Aug '13

12 Aug '13

Dear All, Today when I was checking my Tor notice log file as usual, I noticed that they've included the following warnings: Aug 11 06:23:15.000 [warn] Unable to store router descriptorAug 11 06:23:15.000 [warn] Error writing to "/var/lib/tor/cached-descriptors.new": No space left on device It seems that I've run out of space. But my VPS comes with 35GB disk space and it shouldn't be used up so fast. So how to deal with it?If I do run out of space,any advice for deleting the old files of Tor? Are there any files created by Tor are not useful anymore and can be deleted? Cheers,Tony

5 9

Recommendation on exit node in DE/NL
by Kali Tor 09 Aug '13

09 Aug '13

Hi all, Is there any recommendation for running Tor _exit_ node in NL/DE? The list at https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs see,s pretty old and outdated and contradictory at places. Thanks Kali

2 1

"NumCPUs 2" or 2 copies of Tor?
by Steve Snyder 08 Aug '13

08 Aug '13

Given plenty of RAM, a muti-core CPU and a single IP address, which is more efficient: a single instance of Tor configured with "NumCPUs 2" or 2 instances of Tor configured with "NumCPUs 1" and different port numbers? Thanks.

5 5

Tor Exit Node - DDOS
by Kris 08 Aug '13

08 Aug '13

I've been an end user of tor for a few years and finally as of last week purchased a virtualhost to run an exit relay. After a few days running smoothly, I received a forwarded abuse complaint from the hosting company from someone saying their are being DDOS'd by my IP. I'm prepared per the tor website regarding DMCA notifications, but haven't found much on how to deal with this situation. I have: * made it quite obvious that this is an exit node * reverse dns is tor-exit-node.nenticom.net * web server running on 8080/80 with the tor notification page * provide full real name and abuse(a)nenticom.net contact * notified the hosting company * applied the recommended exit policy per the "minimum harassment" post You can see most of this off Atlas (node: nenticom). https://atlas.torproject.org/#details/50D04704A5017C02CC63AFE4A66F05DF79ED8… Can anyone provide a recommendation of how to respond to this notice (provided below)? Given the headers the original complainer filed it looks like someone is running benchmark software over tor. Maybe after explaining that I'm a tor exit node to the provider I can offer to block exiting to the IP block belonging to the original complainer? Notice from Hosting Provider ---------------------------- Please review the following abuse complaint and provide us with a resolution: ****************************** Hello, Over the last three days we have experienced a massive amounts of incoming HTTP connections from an IP address under your control as part of a DDOS attack. Can you please investigate the server/computer associated with this IP address as it is more than likely compromised and is now part of a BotNet. For your reference, all requests to our server from the IP in question are listed in the Apache logs as: "GET / HTTP/1.0" 500 11680 "-" "ApacheBench/2.3" The attackers IP address that appears to belong to you or your network is '192.241.230.170'. Please resolve this as soon as possible. -- Kind regards, Benjamin Hodgetts Dedicated Hosting Server Administrator Namesco Ltd. Phone: +44 (0)1905 342347 Email: bhodgetts(a)names.co.uk DDI: +44 (0)1905 342384 Main Line: +44 (0)1905 342342 / 0845 363 3630 Main Fax: +44 (0)1905 342343 / 0845 363 3631 Support Email: supportmanager(a)names.co.uk Website: http://www.names.co.uk Namesco Limited (Registration No: 3913408) is incorporated in England and Wales with its registered office at Acton House, Perdiswell Park, Worcester, WR3 7GD. Information contained in this e-mail is intended for the use of the addressee only, and is confidential. If you have received this email in error please notify the sender immediately. Any dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While Namesco has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage, which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. ©2013 Namesco Limited. All rights reserved. ******************************

5 5

Dealing with VPS suspension
by Bernard Tyers - ei8fdb 07 Aug '13

07 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've been running an exit node on a VPS hosting for the past few months. I've had no issues until this morning. The VPS has been suspended due to a report of "massive amounts of incoming HTTP connections from an IP address under your control as part of a DDOS attack". Once I contacted the hosting company they were a bit more forthcoming with information. It took me some time explaining Tor, what it is etc...and why I couldn't really tell them where the traffic was coming from. I'm waiting to hear back from them, but I was wondering: is there a "standard"/informational e-mail template that I can use to communicate the important points to a hoster who has pulled an account? I've read some of the posts on how to run an exit node for minimal harrasment (I checked steps 2, 3, 4, 6, 7). It may be just a matter of education (I didn't do step 1). The hoster has no (public) AUP so I can't have been in violation of it. Ultimately it's their decision, but I'd like to think karma might be on my side if I play nice. Thanks, Bernard - -------------------------------------- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSAqZLAAoJENsz1IO7MIrrT/UH/1T6YTnowguuyFaSR743uFDp gtR7/xVEk0KWE3KuiYmhP8KvMyaYJBiIMq8rRboxr7TI0NfZA50shJ12hI1ITZ4X TSMApNU219B8bQNAfR6LH9H/sBqgYkba5ZtEkGt5O0oA43+08RhJL0s5fkHfznPR rQj1PpuHNR1LFOu2G8uJ3ljVXzHfEdAZwPfzol/f4QURj3dE9boinmzmFJOx+z9U Pz7UsAjFZbx4wPinAbUGFSn9As99pWvxYtUvI4It1RdvtfPb/bh46R5RT/s7/zve ayOgv+WvdwUYhxX242odoq+WksQlKm7eXrAtAw1GV7XcK0g1dZAQcixXc1hWbzU= =kpn9 -----END PGP SIGNATURE-----

2 2

Up and running!
by Cassey Jean Claude 07 Aug '13

07 Aug '13

Hi all - I have a semi-idle laptop that I decided to let Tor run on by 10mb down, 1.5mb up connection. Curious what is needed more: Bridge relays or non-exit relays? Not ready to be an exit-relay yet... one step at a time. Cassey

2 2

Re: [tor-relays] VPS Hardware Specification & Advice
by Tor Pids 06 Aug '13

06 Aug '13

Hi, i just saw this post on the web archive and felt I can contribute something here so I finally registered. Maybe this reply will not be correctly recognized to the thread, sorry. The VPS specs you posted should be more than enough - but the price is too expensive! I currently run about 20 Tor relays on cheap VPS all around the world: http://globe.rndm.de/#/search/query=torpids Basically I just care for the bandwidth/included traffic when choosing a VPS. 256MB RAM is enough, disk space doesn't matter at all. Tor doesn't scale that well with CPU cores so 1 core is ok. For only 1 or 2 of my VPS the CPU is the bottleneck (at about 20-30MBit/s), but most are fast enough. Most cheap VPS are based on the OpenVZ virtualization which limits you to their old kernel and sometimes they limit the number of tcp connections (see "cat /proc/user_beancounters"). KVM or Xen virtualisation is better because you have more control on the VM. Most VPS providers add up the incoming and outgoing bandwidth, meaning that you might be able to just send about 500GB with your 1TB plan. For example with a VPS from www.jiffybox.de for 15€ per month it is possible to push more than 1TB PER DAY(!) (and not per month as with the 18€ plan you mentioned). OVH just released a server for £2,99 per month with unlimited 100MBit/s as well: https://www.ovh.co.uk/dedicated_servers/kimsufi.xml Other typical offers are like 10TB for 10$ or 20MBit/s unlimited for 3€. Good places to find cheap VPS deals: http://www.lowendbox.com/ and http://lowendtalk.com/categories/offers http://www.wjunction.com/46-vps http://www.webhostingtalk.com/forumdisplay.php?f=104 Best, Torpids

3 3

VPS Hardware Specification & Advice
by torrelay＠mail.md 06 Aug '13

06 Aug '13

Greetings! My ISP British Telecom is rate limiting my Internet connection despite a big splashy advertising campaign earlier this year in which it claimed that it would no longer rate limit during so-called 'peak hours' or cap the bandwidth consumption when it reaches a ceiling that they decide is 'too much'. I've tried various bandwidth rates that are a sensible percentage of the total available bandwidth but anything above a very small amount (50-80KB/s) is being rate limited even though the total amount of bandwidth available is approximately 30.00 Mbps downstream & 6.12 Mbps upstream. Now even 50-80 KB/s is rate limited. Well, it's the school holidays started recently here & BT have just brought out a new streaming sports service which coincides with my bandwidth being rate becoming limited from about 2 weeks ago. I was able to run a consistently faster tor relay on British Telecom 7 years ago than I can today & I don't want to speak with a telephone operative in India who follows a script & will test my connection. I just take my business somewhere else -- rant finished! Consequently I've sourced a company, located in a Scandinavian country, offering a VPS with 1TB of data consumption per month for approximately 18 Euros (more than half the price of my shitty, crippled British Telecom Internet connection) so I'll try this. The cost of running the VPS is based on the hardware specification which brings me to my question. I plan to utilise the full 1TB of data each month & I'd like some idea if the specification (below) is sufficient for an entry/middleman tor relay using 1000GB bandwidth per month. The hardware specification I've chosen is: CPU Cores: 1 - exact details of CPU are not specified on the company's website, problem? RAM Memory: 1024 MiB Traffic: 1000GB Drive: 50GB Price: 18 Euros I'm completely new to VPS & am sure this will be a learning curve but no matter I will try to see if I can make it work even if performance of VPS might not be perfect. If anyone has written a guide to hosting a tor relay on a VPS, I'd welcome any links to further information or any other useful advice based on experience of others. Best regards, Edvard.

1 0

VPS
by Tom McLoughlin 04 Aug '13

04 Aug '13

I'm looking for a VPS to run a tor exit node on, any ideas? Regards, Tom McLoughlin

5 6

Running an obfuscated bridge at home still safe?
by z0rc 03 Aug '13

03 Aug '13

Hi, I've been running an obfuscated bridge on a Raspberry Pi at home (in Switzerland) for a week now. Until recently, I thought running a bridge at home was no problem at all. But yesterday Paul Staroch reported in [1] that he got notice from the German police (BKA) concerning his non-exit relay. So I'm a bit scared now. Is it still believed to be safe to run a non-exit relay or bridge at home? Or is this just one single incident? Any other experiences on this? Cheers, z0rc [1] https://lists.torproject.org/pipermail/tor-relays/2013-August/002365.html

1 0

Attacker IP database
by Bryan Carey 03 Aug '13

03 Aug '13

Is there any kind of compiled list of IPs that relay operators can refer to that are known bad IPs (sources of brute force SSH attempts, etc.)? Is there a reason to NOT block (drop) traffic from these IPs? Here are some that I have seen recently trying to brute force common user accounts and root password attempts: 198.50.197.98 220.161.148.178 223.4.217.47 199.187.125.250 175.99.95.252 62.64.83.38 125.209.110.234 37.235.53.172 Also, in general what are some good security practices to keep in mind while running a Tor relay? Thanks, Bryan

8 10

Relay or Obfuscated Bridge?
by Richard Budd 02 Aug '13

02 Aug '13

I have several Tor relays running on VPS providers around the world (the 7 bucks a month kind). Most have around 5 to 6 meg a second bandwidth available. Would it be more useful for the Tor system to change a few of them over to obfuscated bridges?

1 0

Tor bridge on Amazon not doing much
by Shawn A. Miller 02 Aug '13

02 Aug '13

I've been running a Tor bridge on the Amazon EC2 cloud computing platform (per instructions at https://cloud.torproject.org/) since July 27, and while the bridge is up and running according to the logs, there doesn't seem to be much traffic running through it, i.e., latest logs indicate Tor uptime is 2 days 12 hours with 2 circuits open; 6.6 MB sent and 45.75 MB received. Have I somehow managed to misconfigure the bridge or is this normal? Best, Shawn

6 7

Running exit-node in Germany
by Matthias Redies 02 Aug '13

02 Aug '13

Hello, I want to run an exit-node through mit home connection. Has anyone experience with running a Tor-Relay in Germany( Bavaria)? Are there known cases of police raids? Is there a list of lawyers which work with the torproject which should be called in case of a raid? Has anyone had sucsess with talking to the police prior to setting up the exit-node? If so, to which departmed did you talk to? Yours Matthias

11 18

Home broadband - worth running a relay?
by Nick 01 Aug '13

01 Aug '13

Hi there, I have a reasonable ADSL connection, and a little always-on server. The bandwidth is in the region of 2Mib/s down, something less up (maybe 256Kib/s). Is it useful for me to run a tor relay with this bandwidth? I'd like to run one which isn't an exit, at least for now. If not, am I correct in thinking that a bridge is an appropriate help? That's what I'm doing currently, but if a relay would be more useful I'd be very happy to do that. One other unrelated(ish) question: I'm in the UK, where the idea of censorship isn't resisted as strongly as it ought to be, and as a result my internet connection is subject to a smallish amount of censorship: whatever is on the secret IWF blacklist plus the pirate bay. Does this mean that running an exit node from a home connection here at some point in the future would not be helpful? Or only if all HTTP(S) was blocked (as the IWF blacklist is secret there's presumably no way to tell the tor network what is inaccessible from this node). Thanks in advance, Nick

12 23

Diagnosing "relay unresponsive" messages
by Gordon Morehouse 01 Aug '13

01 Aug '13

So, I've got my relay back up on a Raspberry Pi and I'm working on figuring out the optimizations I made to it, and continuing to tune it. Out of the box these machines have some difficulty even offering a couple Mbps, but they can be greatly improved. I will post all details when done. I see a fair amount of this, much less than after some tweaks, but it still happens: 20:27:36 [ARM_NOTICE] Relay resumed [1 duplicate hidden] 20:27:30 [ARM_NOTICE] Relay unresponsive (last heartbeat: Wed Jul 31 20:27:19 2013) 19:50:57 [ARM_NOTICE] Relay unresponsive (last heartbeat: Wed Jul 31 19:50:4 This often happens at the same time as 'arm' (the monitoring program) may stutter, fail to render a few frames, then 'catch up' or redraw the screen. I'm trying to figure out what's going on so I can prevent it. It doesn't always correlate with traffic - it happens more often when there's more traffic but can happen even with very little. Tor is taking about 10% RAM, there's plenty free, and load is under 1.0. Best, -Gordon M.

1 0

What to do about port scans?
by Steve Snyder 01 Aug '13

01 Aug '13

I wouldn't have thought that the Tor network was fast enough for port scanning, but apparently it is. I have recently seen a rash of SSH port scanning (or so my ISP reports). What can/should I do about this? I know I can limit the rate of connections using iptables. What's the consensus on this? Is this considered advisable, or a breach of expected exit node behavior? Do I have any options other than iptables to restrict the rate of port 22 connection attempts? Thanks.

3 3

Re: [tor-relays] Home broadband - worth running a relay?
by ROCKsolid69r＠gmail.com 31 Jul '13

31 Jul '13

1 0

Re: [tor-relays] Home broadband - worth running a relay?
by ROCKsolid69r＠gmail.com 31 Jul '13

31 Jul '13

1 0

VPN termination on relays
by grarpamp 31 Jul '13

31 Jul '13

> Mosh is great, but it still relies exclusively on UDP, right? > So no "over Tor"... Somewhat related to things that don't work via exits... So who wants to offer VPN termination as part of their exit service? User tunnels VPN to you, you give back a bound port, or a natted 10 address, somethings of that sort.

1 0

Fwd: Computer requirements for a modest (15-20Mbs) relay?
by Zack Weinberg 31 Jul '13

31 Jul '13

On Mon, Jul 29, 2013 at 12:35 PM, Andy Isaacson <adi(a)hexapodia.org> wrote: > Yes, there are cases of law enforcement seizing all computer gear from a > house with a exit node -- not just the exit node computer. Most > recently in Austria in a child porn investigation. [...] We did some operational planning for this risk, in conjunction with the university legal and IT departments, when we set up the CMU Tor exit. The machine is in a cube farm filled with other equipment that people need for their work; this is because we want to have immediate physical access to it in an emergency, and anywhere else we could put it would interfere with that. However, it has its own dedicated IP address, it runs absolutely no other services, it is clearly labeled both in DNS and on the physical box, and there's nothing else on the table it sits on. The hope is that this will be sufficient to persuade law enforcement to seize *only* that machine, if it comes to it. Of course, it helps as much or more to have the equipment under the aegis of an organization with lawyers already briefed and on tap, and that has trained all the staff to call legal *before doing anything else* when the police show up. Also, the greater operational threat is having the plug pulled by one's connectivity provider. I personally would not risk having an exit node in my house for that reason alone. zw

3 3

Sitevalley is no longer Tor-friendly
by Tom Ritter 30 Jul '13

30 Jul '13

Sending this out, as I suspect I am not the only person running a node on SiteValley, as they have pretty good bandwidth for pretty cheap. I had inquired in the beginning if they allowed Tor, and they said yes, but if we get too many abuse complaints we'll shut it down. So maybe 4 or 5 abuse complaints later they did indeed give me the ultimatum to shut it down or get shut down. So I made them give me a new IP address, and made it into a middle node. (The new IP was because I was thinking of making it a bridge.) Well this morning they told me TOR (their caps, not mine ;) is not allowed at all. I argued with them a little bit, and TLDR you might be able to get a partial refund. I'd much rather have had the bandwidth though. I'm not in a position to run high-maintence nodes, so this being a pretty fast, maintenance-once-every-three-months dedicated-to-Tor node - I was pretty happy with it. Our conversation: ----------------- Your VPS X.Y.Z.W has been suspended due to running tor anonymyzer which is forbidden according to our Acceptable Use Policy, paragraph 8 "Prohibited Activities" http://www.sitevalley.com/acceptable-use-policy/. In order to have your VPS unsuspended you need to agree to remove tor from it within 24 hours after the unsuspension. Failure to abide by this provision may result in termination of your account. We have to warn you that on receiving next abuse your VPS will be terminated without without prior notice. ----------------- If you refer to Contact Form ID #YXX-XXXXyou'll see that I confirmed with you before I purchased the VPS that allowing Tor was acceptable. I dealt with the 3 or 4 abuse complaints you sent me promptly, and in #FSA-XXXXI agreed to stop using the server as a Tor Exit Node, despite our previous conversation. The machine in question is running Tor in a non-Exit mode. Traffic from it does not appear to originate from the server, and it merely passes traffic within the Tor network. It cannot generate abuse complaints from third parties when running in this mode. Have you received an abuse complaint about this server? If so, can you forward it to me so I can investigate how it may have been created? ----------------- The node was found during system audit. May be you know that running tor (in any mode) is strictly forbidden by our Acceptable Use Policy because it can be used by third-parties for forwarding hidden illegal traffic. Unfortunately, we can start your VPS only in case you agree to remove tor. ----------------- I'll put aside the fact that your routers, DNS resolvers and every router of the internet also carries hidden illegal traffic, and that Tor is agnostic to that traffic as your routers are. I did NOT know that running Tor was not allowed because I ASKED you if I could, and you told me it was fine as long as it did not generate Abuse Complaints. Considering your AUP is so broad it can be made to cover anything you don't like, the only reasonable thing someone can do is ask if you'll allow something - which I did. I'd like a pro-rated refund of my remaining service, as you have misrepresented your services and your Acceptable Use Policy to me - if I had known you wouldn't allow me to use my bandwidth in a way that was not illegal in any jurisdiction, did not generate any abuse complaints or additional work for you, and that you would shut down my service after I confirmed what I was doing was okay with you - I would never have paid you in the first place. ----------------- Ticket YXX-XXXX dates from 26 Mar 2012. Our Terms of Service are subject to change and, according to our Terms of Service http://www.sitevalley.com/terms/ posting of such changed Terms and Conditions on the site constitutes notice of such changes to you (although we may choose additional types of notice). Our policy regarding TOR usage has been changed and as for now, running TOR applications on our servers is forbidden. We are very sorry that this provision prevents you from using our services in the manner you need to use it. All things considered, we can offer you two options: 1. We unsuspend your VPS, you remove TOR from it, let us know and we check it. or 2. We issue the partial refund and terminate your account with us. Please rest assured that we value you as our customer and would like to continue doing business with you. Also, please accept our apologies for any inconvenience this misunderstanding has been the reason of. ----------------- Thank you Dmitriy. Please issue the partial refund and terminate the account. ----------------- -tom

13 21

Computer requirements for a modest (15-20Mbs) relay?
by Nick 29 Jul '13

29 Jul '13

Hi, I'm probably going to move to a new ISP soon, and may well be able to get a fibre 20Mbps up connection, which is a nice thought. The question I have is whether my little ~1GHz home server box (a weird little x86 thing, I can dig out more specs if they're relevant) would be able to relay that level of traffic without issue? The TorExitGuidelines page on the wiki mentions that one "modern" CPU core should be able to push 100Mbps, but my server is probably 6/7 years old. It's a VIA board, which IIRC might have some hardware crypto acceleration or something - is that something that would be likely to help things if I can get it working? Thanks folks, Nick P.S. Are there any known cases of law enforcement seizing equipment or otherwise terrorising people for running home exit nodes? I would like to imagine that Tor is well known enough in such circles that such action would be rather unlikely nowadays. I know at least some remailer operators host stuff from their homes, but maybe that's lower risk.

2 1

Tor exit node flags explanation
by Bernard Tyers - ei8fdb 26 Jul '13

26 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have looked thru FAQs and docs but can't find an answer (no doubt its in front of me somewhere). Is there any explanation of what Tor node flags mean? Specifically the "Named" flag. It has recently been applied to my node. thanks, Bernard - -------------------------------------- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJR8nm1AAoJENsz1IO7MIrrxjQIAIRB/Y+a0fyQvcA/b/3+PuT8 spVgrS6Ts39w0xncwO1DCcCDzA1EmEaQy2I6VZ1YYIk+qrDXSkyP8Gl2ACWJ8SZi Wjmt9OeQZYE3thUfXlEX4K0iqiu1vc26dHxR0VAwqV9a4GAFJ6vmDiwNLqhjEjVA a/uQdNwx1kPfApHMIDRRmBFRWGJ5v//3XxN1nS7Ty5q2ngR7ws9xfRJ6awpRrYFN vRpHPG/BGQGbcCsBsecGu/nSJaN+2mfqb9fRaHIeDUBtn6xV465BxmhZwCzf2sL4 jYoMnLByJodfImhT53qPBlgs/7HNuMbFldeREI21QlWEVi4eaN9BLS2/fe+rLQA= =R/y8 -----END PGP SIGNATURE-----

2 1

Yet another underpowered relay?
by Logforme 23 Jul '13

23 Jul '13

I recently upgraded from an adsl line to a 100mbit fiber connection. Naturally I want to use most of this new bandwidth for my non-exit tor relay. However, I run into messages like these: Jul 22 17:40:26.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [665 similar message(s) suppressed in last 60 seconds] Jul 22 17:40:26.000 [warn] Failed to hand off onionskin. Closing. [1509 similar message(s) suppressed in last 21600 seconds] Relay fingerprint: BE71 DC9D A443 5855 FAE1 E369 7080 1A60 0D51 3684 Relevant torrc settings: BandwidthRate 10 MB BandwidthBurst 10 MB NumCPUs 2 I did some research and came up with the following things to try: Set "MaxAdvertisedBandwidth x MB" Set "MaxOnionsPending 250" Get a faster computer / Get a computer with AES-NI I tried setting "MaxAdvertisedBandwidth 9 MB" for a few days which didn't seem to do much difference. This is only a 1MB reduction from the 10MB i use as a hard limit. Too little? Must I wait longer for the change to get spread around? Setting "MaxOnionsPending 250" seem to have reduced the number of log messages, but not eliminated them. The computer is somewhat dated but not ancient: Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz, 4 cores with HT, 6GB mem. I feel it should be able to handle a 80 mbit bandwidth but have no hard data to support this. Looking at htop tor uses 2 cores. One core is constantly at around 90% (when all the 80 mbit bandwidth is used). The second core is hardly used. Since the relay can handle 80mbit (and higher) without messages I assume the problems only occur when the number of circuits get very high. Questions: What value should I set for MaxAdvertisedBandwidth? What other torrc settings could improve the situation? Am I wrong in thinking my cpu should be able to handle 80 mbit? Would upgrading to 0.2.4.15-rc-1 help? Weird sidenote: If I start iftop the first core drops to around 40-50%. Stop iftop and it jumps back to 90%. No change in traffic. What could that mean?

4 4

Re: [tor-relays] Exit relay operators: a call for packets on port 8118
by rotpoison throngnet 22 Jul '13

22 Jul '13

I believe you are exactly right, Javntea. Thank you for the insight. I opened up Privoxy for a few seconds on my node (below) and had similar results. I had no idea that pay for click advertisers would even accept referrals from Tor. It is pretty basic to filter identified exit relays and other anonymous proxies. So apparently the return of investment from this sort of clickfraud pays the leasing bills of thousands of servers? WoW, I have been schooled... - Kent 09:21:01.419951 IP 23.19.89.126.2318 > my.exit.node.8118: Flags [P.], seq 1:416, ack 1, win 65535, length 415 E.....@.u.u/..Y~B... ...^.]^M....P.......GET http://ad.media-servers.net/st?ad_type=iframe&ad_size=160x600&section=44321… Accept: */* Referer: http://giftcardsrus.net/index.php?option=com_content&view=article&id=1741:w… Accept-Language: en-us User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) Host: ad.media-servers.net Connection: Keep-Alive 09:21:01.419973 IP my.exit.node.8118 > 23.19.89.126.2318: Flags [.], ack 416, win 6432, length 0 E..(..@.@...B.....Y~.. .....^.^.P.. .k.. 09:21:01.420501 IP my.exit.node.8118 > 23.19.89.126.2318: Flags [P.], seq 1:256, ack 416, win 6432, length 255 E..'..@.@...B.....Y~.. .....^.^.P.. .j..HTTP/1.0 403 Request blocked by Privoxy Content-Type: image/png Content-Length: 102 Cache-Control: no-cache Date: Mon, 22 Jul 2013 09:21:01 GMT Last-Modified: Wed, 08 Jun 1955 12:00:00 GMT Expires: Sat, 17 Jun 2000 12:00:00 GMT Pragma: no-cache 09:21:01.430712 IP 173.208.16.93.1094 > my.exit.node.8118: Flags [.], ack 1, win 65535, length 0 E..(...........]B....F...._..x..P....~........ 09:21:01.431701 IP 173.208.16.93.1094 > my.exit.node.8118: Flags [P.], seq 1:511, ack 1, win 65535, length 510 E..&...........]B....F...._..x..P.......GET http://ad.globe7.com/st?ad_type=pop&ad_size=0x0&section=3910946&banned_pop_… Accept: */* Referer: http://twicemagic.com/index.php?option=com_content&view=category&layout=blo… Accept-Language: en-us User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; Media Center PC 6.0; InfoPath.3; MS-RTC LM 8; Zune 4.7) Host: ad.globe7.com Connection: Keep-Alive 09:21:01.431722 IP my.exit.node.8118 > 173.208.16.93.1094: Flags [.], ack 511, win 6432, length 0 E..(..@.@.b.B......]...F.x....a.P.. .... 09:21:01.432462 IP my.exit.node.8118 > 173.208.16.93.1094: Flags [P.], seq 1:256, ack 511, win 6432, length 255 E..'..@.@.a.B......]...F.x....a.P.. ....HTTP/1.0 403 Request blocked by Privoxy Content-Type: image/png Content-Length: 102 Cache-Control: no-cache Message: 3 Date: Mon, 22 Jul 2013 00:09:55 -0700 (PDT) From: Javantea <jvoss(a)altsci.com> To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Exit relay operators: a call for packets on port 8118 Message-ID: <20130722070955.1CF571380F1(a)mail.altsci.com> Content-Type: text/plain; charset="us-ascii" Hi Kent, I am getting 125 packets per second sustained incoming on port 8118 like you on my exit node. I noticed this last year but forgot about it because it was such low bandwidth. I count 2582 unique IPs in 20 minutes. I think you've found something significant. The obvious question is why since sending data in the clear is pretty worthless and it's going to come out of a tor exit node just like if they were using tor. I'm a security researcher and would be happy to help you learn more about these silly systems. You've already done most of the basic research though: who, what, and where. When I open port 8118 with netcat a few times I get this: GET http://ad.yieldmanager.com/st?ad_type=iframe&ad_size=300x250&section=421110… HTTP/1.0 Accept: */* Referer: http://www.lotsoffree.com/index.php?option=com_content&view=article&id=84:f… Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 Host: ad.yieldmanager.com Connection: Keep-Alive GET http://ib.adnxs.com/ttj?id=1284883 HTTP/1.0 Accept: */* Referer: http://www.psxobs.com/privacy-policy Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 Host: ib.adnxs.com Connection: Keep-Alive That looks like clickfraud to me. Perhaps someone wrote a quick script that downloads the list of tor exit nodes and sends clickfraud requests to 8118 and was too lazy to add tor. That would mean that the sites in the referrer are the attackers and the url on the first line is the ad service which is being defrauded. Of course there is the possibility of a joe job occuring, but we know that at least some of them are the bad actors. Whois on both referrers returns China. I'm surprised that the script doesn't remove servers from the list that have the port closed. It's a very inefficient script. Regards, Javantea

1 0

relay uptime
by l3thal 22 Jul '13

22 Jul '13

Hi, I recently edited my torrc and accidentally did restart instead of reload so my uptime was reset. Will this negatively impact the 60 days to get a tshirt? -- l3thal - SmashTheStack <http://smashthestack.org>

2 2

Checking my Tor bridge and adventage of dynamic ip addresses
by nobleeightfoldpath＠lavabit.com 20 Jul '13

20 Jul '13

Hi list members, Iam kinda new to Tor and decided to run a relay and found heavy traffic on my router. No prob, but after reading the documentation and some discussion boards I decided to make internet access possible for people living in censorship and run a bridge on Linux without Vidalia and other x related apps. I use "Arm" to check the Tor daemon activities. The bridge runs a few days and I see: flags: no, and there is nearly zero traffic, avg 1.4 Kbs, mostly 0. Arm displays connections and I see some IP addresses, 2 circuits. And often just - nothing. Obviously Tor is running, but Iam afraid that my config isn't useful... How can I check my bridge is really working? Another question comes up. I use a cable connection to my ISP and they don't change my IP address, until plugging off my modem and wait an hour... I think if my bridge IP address is some day on some black lists, it could be an adventage if my IP address changes, right? If so, what changing time is fine, every day? Regards

5 8

Bandwidth Spike
by Bryan Carey 19 Jul '13

19 Jul '13

I'm a fairly new Tor relay operator and noticed something peculiar with my bandwidth for the relay recently. It seems to have jumped WAY up and just plateaued at what I have the peak bandwidth limit set at. Is there any kind of explanation for this? Is this normal behavior? Could it indicate some kind of denial of service attack? Here's a screenshot I took of the bandwidth history: https://i.imgur.com/mRyKp9L.jpg (note that both R/W plateau at the same point in time) Perhaps this is normal behavior but I want to know if it's something that might be messed up with my configuration that I can correct. -Bryan

2 1