- tor-relays - lists.torproject.org

help with relay and bridges
by That Guy 25 Aug '13

25 Aug '13

Hello all, been feeling helpless and have decided to at the least get a few relay's and bridges up and running and hopefuly learn enough in the process to help/teach others to do the same. Although for many it is a simple task, for many many more who would like to help it is no easy task and there is lots of uncertanty and questions if one does managage to get a relay up when they are not sure what they are doing. I understand these are elementary issues and that is why as a non-programmer of Security expert I would like to help where and when I can and with a little help from some or even one of you I hope that I can help others while taking some strain off the real minds. Many others like me exist and want to help. I am asking for someone to help me help others. Thank you grep(a)gmx.us -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.10 (GNU/Linux) mQENBFFn+3IBCAD0cqkxl7t+5Kychbzqaf/Wn8z3B5UCQYZk77I1sZj5sZCNhoCw bne6Q2L6SAk/K81C6ih0X1quTiCX65XmyEzjADX61CMMqwot4DZpt0Iahsp3JQbV zGryYn4fLjOO1r3pPg100luD2C37oNfOZmUhvHgtyLMTpCGBD3O8LF7p7/POLraH uYcFx0oXN5+P2xrp0MxJazxgRpKNW+00Q5t3vyzejF9z8zaw/yOrcip/5Bz8kYwh +dTjxudmV9R/bKhyRrtLaIfdM4UyvAIgGAL224kRBT+YfNouKEWRqA55HSTdKFnt sqlbV4bJ9vzZwFKiyG/r2L0eJtAaYuJLHBRrABEBAAG0GWsgPHJpZ2h0Y29hc3Q3 N0BodXNoLmNvbT6JAT4EEwECACgFAlFn+3ICGyMFCQlmAYAGCwkIBwMCBhUIAgkK CwQWAgMBAh4BAheAAAoJEL/qyBxVCbTig6sIAKIo00P0XH5a/JrBEkiqU4cE9z2F GAGBs3xKO1gFbkyM6AG/8bqSlKmUqYcuZ64kQFXDidXATtyhJCK8gH/AdRv1jEIh FmZZDK2Y94lkdxiN4MVvjTOM+Lmze+C6hM7UZY+sq2ZeVfkA5kbqgPCMB5XJu0Ff xuUBFoicXDy4eegAQEP7VGep/Uxc3q40SJWeF08TNx5GliA8TNAR8hPs4C41oicF qoXiAyG9JKJlBSS02H6zHQGK/S5ma5xYPjh+GCLiRA+UjuHQa+fBoTPVTR0w63h1 iHZA44SZYffi6NfKEvmGz0WwsvxmyM78B4oKtqNseCtAGc2mEusfVrJkY8e5AQ0E UWf7cgEIAMSh0dg9JY8VDPyRSzJCoghYrjAbbY67i7JdxTtqUvR4CV7jg5Oy1OWi fTAgwMFL/seVihozUYA+0justddC5wDJK6YvULDBh43dCrZyUMLMjtHodtORAcXM uQm67MWYX1E5HH+x0nVIbP1O7GjjWzu7EkGqnqpBr+DI/tfVbfDKL6xjRoE3rO7h Tl9i7sc7QIcRiK3ZP6S2Agr8W5nCQxNXSFSh1chMdxAedkRNEbzyU3wnU+aUw4VU FJ1FNNiCXs1X7miAUrGnDdqN3C+cg4QIaE9UIjawIkSRlCPxUkelY5ceTiN1+vLz /EJc4LnaWd8jBw8Myx5F0Egi7qD7adkAEQEAAYkBJQQYAQIADwUCUWf7cgIbDAUJ CWYBgAAKCRC/6sgcVQm04gYuCADXra9mbW+vNRWV0toEfKXRzsZ9nL4Vwp3Dys6I Hn8T1wq7DyS9N/8gan6lms8AyvNyp3vC6WZdYPnVk70YCKn1pEztyyL0YzN8WUqZ 8hBoDDKDmOS65DerGj5Fppbg1J5HEQfV1onkMKnT5KKW590Mr0EpTda28N2WUS8Q gwk7cqJ8HC033LEd16mA4FS3aZmRM5QfwkdvKb+hc29+TvrmuLIQ4yJuFQUVyoTt lfq1iY6N3PBOnBSeCSz4Ky3buxiilU9g158r7KKu0FqDMr1bhlRUR9aydSzyKSwd sQS78U81FmwMXXfLJc2TWSEgtqKQJJHbYq2jj6C8qtrs2hSg =tYo4 -----END PGP PUBLIC KEY BLOCK-----

2 1

Increase of number of new relays and exit nodes
by Jon 22 Aug '13

22 Aug '13

I am wondering with the increase of number of new relays and exit nodes how this might be affecting the other ( non- new ) relays and exits? I have noticed over the past several months that the amount my exit relay was being used has drastically dropped as the new relays and new exits have come online. Is this normal to see my usage drop noticeably? Is this going to be a continuing trend as new relays and exits join with what we already have, that some relays / exits will see a lower usage from their nodes? Jon

2 3

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