tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

Re: [tor-relays] Store key files in RAM
by Tony Xue 27 Aug '13

27 Aug '13

Thanks for the instructions. So what if I set up an L2TP VPN connection from my server to my computer at home which stores the keys and I download the file directly into the RAM folder? The purpose is to avoid storing the file or let the file passing through the local normal storage system on my vserver which could be extremely insecure in this situation. So will any of these techniques you have described or I stated above let my data passing through the local ROM storage system of the vserver? > Date: Tue, 27 Aug 2013 00:14:36 -0400 > From: tor(a)t-3.net > To: <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] Store key files in RAM > Message-ID: <521c27ac.570.f998d700.49849df(a)t-3.net> > Content-Type: text/plain; charset="us-ascii"; Format="flowed" > > IMO cut and paste in the situation you're describing is not the > perfect way. Better way would be: > > Have a secure linux machine running an sshd at your home (or another > physically-controlled location?). > Close off iptables and ip6tables for inbound sshd except for your > vserver's IP > (hint: "ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_4096_key -b 4096" > (don't put a password when it asks)) > and edit sshd_config to point it to the new key. Also in the config, > force your local sshd > server to insist upon only using these 2 ciphers ("Ciphers > aes256-ctr,aes256-cbc"). > Restart the local sshd (maybe "service sshd restart") and verify that > you can NOT connect > from the vserver to the home box using a different cipher (ssh -l > someuser -c aes128-ctr your.home.ip.here). > A test ssh connection without the "-c aes128-ctr" should work, the one > with it should fail. > > You would do transfers of important files to and from the vserver via > an 'sftp' session which you start > from your vserver, and you are connecting into your home machine (sftp > someuser(a)your.home.ip.here). > Don't make the connection in the reverse direction, you can push and > pull files with the one. And don't > let anyone steal your ssh_host_rsa_4096_key off the home box. (could > even shred/delete/regenerate it > now and then). In general, turn off the home sshd when you aren't > using it. > > The above setup should be pretty good in terms of the network transfer > if the data hasn't already been > compromised, of course. The certainty that it hasn't been is not > necessarily guaranteed if it's already > been thrown through a network card in a less-solid way, such as the > contents having been viewed > via 'cat', 'nano', etc. via a connection in the 'wrong' direction. > > If you are deleting files from your vserver's hard drive after copying > them out for backup, try doing > "shred" on the file first, and then "rm". It may help do the deletion > better, depending upon how your vserver > hosting is set up. > > > > > > On Monday 26/08/2013 at 10:53 pm, Tony Xue wrote: > > > > > > > > > > > > > > Hi, > > > > I have been discovering simple and secure way of protecting the Tor > > key files recently, in order to achieve the safety of the keys on VPS. > > > > So I created a folder on Linux called /tor and it is stored in the RAM > > file system. I put my key file into that folder and link it back to > > the data directory folder of Tor. I also backed up the key files in > > case my server need to be restarted and the RAM would be cleaned up. I > > left the key in RAM for some undesired failures, errors or > > configuration which need to restart the Tor software. > > > > If the server gets down, I would probably do the simple cut and paste > > in the SSH client to restore my key files. Or in a higher level way if > > cut&paste is not safe enough. > > > > I am not sure whether this is a good way to protect my key files on a > > VPS. Does anyone have any comment on that or a better way? > > > > > > Tony > > _______________________________________________ > > 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] Store key files in RAM
by tor＠t-3.net 27 Aug '13

27 Aug '13

IMO cut and paste in the situation you're describing is not the perfect way. Better way would be: Have a secure linux machine running an sshd at your home (or another physically-controlled location?). Close off iptables and ip6tables for inbound sshd except for your vserver's IP (hint: "ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_4096_key -b 4096" (don't put a password when it asks)) and edit sshd_config to point it to the new key. Also in the config, force your local sshd server to insist upon only using these 2 ciphers ("Ciphers aes256-ctr,aes256-cbc"). Restart the local sshd (maybe "service sshd restart") and verify that you can NOT connect from the vserver to the home box using a different cipher (ssh -l someuser -c aes128-ctr your.home.ip.here). A test ssh connection without the "-c aes128-ctr" should work, the one with it should fail. You would do transfers of important files to and from the vserver via an 'sftp' session which you start from your vserver, and you are connecting into your home machine (sftp someuser(a)your.home.ip.here). Don't make the connection in the reverse direction, you can push and pull files with the one. And don't let anyone steal your ssh_host_rsa_4096_key off the home box. (could even shred/delete/regenerate it now and then). In general, turn off the home sshd when you aren't using it. The above setup should be pretty good in terms of the network transfer if the data hasn't already been compromised, of course. The certainty that it hasn't been is not necessarily guaranteed if it's already been thrown through a network card in a less-solid way, such as the contents having been viewed via 'cat', 'nano', etc. via a connection in the 'wrong' direction. If you are deleting files from your vserver's hard drive after copying them out for backup, try doing "shred" on the file first, and then "rm". It may help do the deletion better, depending upon how your vserver hosting is set up. On Monday 26/08/2013 at 10:53 pm, Tony Xue wrote: > > > > > > > Hi, > > I have been discovering simple and secure way of protecting the Tor > key files recently, in order to achieve the safety of the keys on VPS. > > So I created a folder on Linux called /tor and it is stored in the RAM > file system. I put my key file into that folder and link it back to > the data directory folder of Tor. I also backed up the key files in > case my server need to be restarted and the RAM would be cleaned up. I > left the key in RAM for some undesired failures, errors or > configuration which need to restart the Tor software. > > If the server gets down, I would probably do the simple cut and paste > in the SSH client to restore my key files. Or in a higher level way if > cut&paste is not safe enough. > > I am not sure whether this is a good way to protect my key files on a > VPS. Does anyone have any comment on that or a better way? > > > Tony > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

1 0

Store key files in RAM
by Tony Xue 27 Aug '13

27 Aug '13

Hi, I have been discovering simple and secure way of protecting the Tor key files recently, in order to achieve the safety of the keys on VPS. So I created a folder on Linux called /tor and it is stored in the RAM file system. I put my key file into that folder and link it back to the data directory folder of Tor. I also backed up the key files in case my server need to be restarted and the RAM would be cleaned up. I left the key in RAM for some undesired failures, errors or configuration which need to restart the Tor software. If the server gets down, I would probably do the simple cut and paste in the SSH client to restore my key files. Or in a higher level way if cut&paste is not safe enough. I am not sure whether this is a good way to protect my key files on a VPS. Does anyone have any comment on that or a better way? Tony

1 0

What if my favorite online store website blacklists all Tor Relay IP addresses?
by David Carlson 25 Aug '13

25 Aug '13

It seems that at least two 'normal' online store websites that I visit from time to time have apparently decided to block my IP address which I am also using for a non-exit Tor relay. I have had extended discussions with one of them and they considered unblocking my IP address to be a risk greater than the lost income (US $160/year revenue) was worth. They suggested switching to a different IP address, which was like pulling hens' teeth from my ISP. To do that, I had to have a technician visit my house and install a new modem because they do not have a person who understands tech talk available for ordinary users, and I couldn't get sufficiently elevated in their support hierarchy. The supposedly dynamic IP address that I get from them hardly ever changes, probably because I am buying U-verse television service from them. Now, after a couple of months, the "new" IP address is also blocked. My question is this. What if it becomes common practice for commercial entities such as online stores to block all IP addresses that they find on lists of Tor relays such as <https://www.dan.me.uk/tornodes> or the official Tor metrics data? That list is updated every half hour, includes all nodes, and is not limited to exit nodes. It currently lists 4438 nodes. That is a manageable size for a blacklist, but it could represent tens or hundreds of thousands of clients. Wouldn't this eventually either cripple the Tor network or generally discourage Tor clients that can no longer buy products online from store XYZ through the Tor network? David C

2 2

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(a)\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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays