tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

False warnings about inaccurate clock
by Stephan 18 Apr '14

18 Apr '14

Hi all, I got two strange warnings within three days that I've never found in my logs before: > Apr 15 21:58:08.000 [warn] Our clock is 1 minutes, 52 seconds behind > the time published in the consensus network status document (2014-04-15 > 20:00:00 UTC). Tor needs an accurate clock to work correctly. Please > check your time and date settings! > Apr 18 15:58:03.000 [warn] Our clock is 1 minutes, 57 seconds behind > the time published in the consensus network status document (2014-04-18 > 14:00:00 UTC). Tor needs an accurate clock to work correctly. Please > check your time and date settings! My "problem" with these warnings is: my server's time is correct. I'm running an NTP demon and verified the time manually - there is not even one second deviation, much less nearly two minutes. Has anyone else experienced such warnings these last days? Is it really my server or could it be an error with the consensus network status document? -Stephan

3 2

Re: [tor-relays] A few questions about my setting up my first Tor relay.
by Nastase G. Eduard 18 Apr '14

18 Apr '14

Well, this really convinced me on using Raspberry as a relay. Very nice guide. Due to the very low power consumption I'm thinking on setting relays that are battery and solar powered (I'll build some grapheme supercapacitators) and using an anonymous internet connection (3G/4G via a mobile router, very easy to obtain). Could be something nice. Richard Budd <rotorbudd(a)gmail.com> wrote: >_______________________________________________ >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] Init.d script for two simultaneous Tor instances
by Jesse Victors 18 Apr '14

18 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I prefer "ps aux | grep tor" and then you can seem them running side by side. You can also seem them on htop, which I prefer over top. My init.d script sets a different log file to each instance, allowing you to monitor the logs of each independently. If you are clever though, you could do something like alias torlogmon='watch -n 10 "cat /var/log/tor/notices.log | tail -8 && echo \"***************\" && cat /var/log/tor2/notices.log | tail -8"' and watch the logs of both at the same time. If you want to use arm you will have to set arm up for each instance. I've been moving away from arm in favor of other tools, one of which is "speedometer", a nifty package that allows you to monitor bandwidth usage remotely. If Tor is the only thing on your machine, you get basically the same thing as the arm graph. alias speedometer="speedometer -l -m 1048576 -rx eth0 -c -tx eth0" Where 1048576 is the maximum bytes/sec value that will be shown in the y-axis on the linear graph. Modify depending on your utilization. I prefer working with powers of 2 with this. The man page is useful of course. Jesse V. On 04/18/2014 03:19 AM, tor-relays-request(a)lists.torproject.org wrote: > Jesse, > > What's the test that there are two instances running? > top? Are they visible in arm? > > Robert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCgBmBQJTUWqTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA2cYH/RLgurJnbLXXFrfbg9bnxr5E pZZl7j/UBCa9hCmvMBKRdGBSglzivNU/5XQ5gmdSpjzgPop6g7BYd2FPrQRBP3TF tOsmYf+hrPHwZlG9OVyAhhxx1fBwRyQnEcuOp5B87XXh14LAd1xPBFUR5lx1qLYm JRpKdu3d3izk0lGVbsU3tMWceu9lmTogoHtaSSkSLawZmzje4EDLcTACnVJjGxPA FGruIXgr3VLrGnlX0f+XngDGbN3TmrdnSTa6WKFn5r4SSEL/Pl1u2AO7Y/z15fyQ FoloQVYUrO0Vhckc+Qy2tuaQFkT2ol0vfSr08lCmuy3+udKlYRfRKTyPcoyHr/8= =SyIv -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] Init.d script for two simultaneous Tor instances
by Jesse Victors 18 Apr '14

18 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Yes, it's better to have faster relays. However, if you are setting up a relay or exit on a gigabit connection it may take some time before you see significant utilization of the pipe. By running two Tor instances at once you can increase the contribution of the Tor network without sacrificing the speed of either relay. Monitoring and good judgment is key here, I wouldn't run multiple relays on a slow computer or one with a slow Internet connection. Watch the logs and just make sure everything is running well, as always. Jesse V. On 04/17/2014 11:43 PM, tor-relays-request(a)lists.torproject.org wrote: > Jesse, > > Thank you for that. > I think I can implement it now but I couldn't have set-up second Tor instances without help. > > The question to my mind is at what point is it better to use a fast connection for two Tor instances? > Isn't it always better to have faster relays rather than more relays? > > Robert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCgBmBQJTUWhJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAPOIH/16fENaDiAAtBm5AHyf3uJ3X PgeJWgoBQE+35YpGne0Hlun/7ycI9jRuRu/z2vI9aRvnLuaNcaD7rIYGkzVQtBBE n/N4KxpByg5E7Wv4s0TmpnT3DQqjYpEFScGd9TvoWdwA9iTJ1sXrqQ7ByjQhuS/O bUhPhck9YFrW7QwJ5OckYe16wuuPf4+mBH1mCq40nLRPWx+pCmgY53LFYzePl9dp QwQCPH664Wa+/yrtJfoSfiZvPwWWDPL/vFJIYHkSoT1p0V1y6P2M7YD2ArM3LRyQ H7hy7nnFyVs/omRo1yBwplIkx/FivrCh26hZlYXB7xVi64cUV+SqKIBnkwcehTU= =gzt4 -----END PGP SIGNATURE-----

1 0

A few questions about my setting up my first Tor relay.
by Robert Smith 18 Apr '14

18 Apr '14

Judging by the level of your computer skills implied by the emails, those involved in Tor have better things to do than help a guy like me. I think it is important to the entire world that the internet links us together, and Tor may be the most crucial part of that. I have 3 machines as possible candidates for a Tor relay: A) A decent PC (around 6 years old) with Vista installed. It's been unused for 2 years. I am willing to do a clean re-install of Vista or even Linux (with help) to run it as a Tor relay, night and day. B) A MacBook Pro (4gb ram, Intel, Snow Leopard). Again, I am willing to wipe it, and do a clean install of the OS and use it for a Tor relay, night and day. C) My personal laptop an Asus G74S (12gb ram, i7 quad core 2.2ghz, Win7 Home Premium 64bit), which I "sleep" most nights. Modem: DSL from "Telus" (in Victoria, BC, Canada) with 4 ports (I use 1 cable port to my personal computer, 1 wireless port for my iPad or Android cell phone). Questions: 1) If I run a Tor relay with that modem, are there any security risks to the other devices? I am no technical guru. 2) If I run a Tor relay on either (or both the Vista PC and MacBook) of the computers mentioned above, will it be mostly a "set it and forget it" maintenance? I cannot devote much time (and definitely don't have much expertise). 3) Will I compromise the anonimity of Tor users due to my lack of technical skills while running a Tor relay? I don't want to do more damage than good. 4) Can I throttle down the bandwidth on my Tor relay(s) when I need it for my own personal machine? I don't want to disrupt the Tor net. 5) Can you suggest the best way to use my machine(s) to make a reliable, maintenance free and secure Tor relay, requiring the least amount of time? I am guessing it's the MacBook cabled to the DSL, running only Tor relay software, and running only a normal relay. 6) At this point is it worth my while, to attempt a Tor bridge or exit relay or am I even capable of doing it properly? I have little experience or expertise in networking and not much time. Thanks for spending your valuable time reading my questions. I hope to make it pay off, in a long term Tor relay. Rob Smith

7 6

Init.d script for two simultaneous Tor instances
by Jesse Victors 18 Apr '14

18 Apr '14

In case anyone is interested in running two Tor instances (regular, bridge, relay, exit) on one machine, I've successfully made an init.d script to do just that. From searches on Google it looks like others have asked about this in the past, so I'm sharing this for them. Tor only allows two Tor instances per IP. When the TBB came with Vidalia it was much easier to casually run a couple of relays per IP, but with the service it's a bit more tricky. Nevertheless it is possible: Instructions are here: https://gist.github.com/Jesse-V/11007048 Tor should be stopped and be sure to make a backup of /etc/init.d/tor before doing this in case things go south. Be sure to set up the folders and separate torrc file before replacing the /etc/init.d/tor script. The commands will be the same as before, so "service tor start" launches both. The script is a fork of the one that's packaged with Tor 0.2.4.21. Use your own judgment with this, but I'm just posting this for anyone interested. Jesse V.

5 5

Re: [tor-relays] Recommended reject lines for relays affected by Heartbleed
by tor＠t-3.net 18 Apr '14

18 Apr '14

Perl script attached which I made to take this !reject formatted list of bleeding tor nodes and reformat it into a mega-long ExcludeNodes line and put it at the end of my exit node's torrc. My tor daemon did not bomb or complain upon seeing the line. Hopefully that is the right way to use that !rejects list for relay operators who want to do the best thing?

4 3

Recommended reject lines for relays affected by Heartbleed
by Andrea Shepard 18 Apr '14

18 Apr '14

A list of 1777 proposed reject lines of fingerprints which have ever turned up as potentially exposed by Heartbleed in my scans is available at the URL below. This was generated with the following query: (select distinct hb.probe_identity_digest as identity_digest from heartbleed_probe_results hb where hb.probe_has_heartbleed and hb.probe_tor_checked_identity) union (select distinct hb.expected_identity_digest as identity_digest from heartbleed_probe_results hb where hb.probe_has_heartbleed and not hb.probe_tor_checked_identity) order by identity_digest; That is, it includes all probe results for which a Tor handshake was actually completed with the identity digest in question *and* a response to the Heartbleed probe was seen (1729 digests) or for identity digests we expected to see for that IP/port pair for which the handshake did not succeed but a Heartbleed response was seen (additional 48 digests). The target list is all IP/port pairs which have ever appeared in a consensus or vote during the time I've been scanning, so some of these may not be in the current consensus or have ever appeared, or they may no longer be vulnerable but not have changed keys properly. There are a bit over 900 vulnerable relays in the latest consensus. http://charon.persephoneslair.org/~andrea/private/hb-fingerprints-201404170… -- Andrea Shepard <andrea(a)torproject.org> PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5

11 17

Fwd: Tracking the bleeding relays
by Sina Rabbani 17 Apr '14

17 Apr '14

Hi, I have an additional scan on all the relays in the current consensus: https://encrypted.redteam.net/bleeding_relays/ You may also be interested in the one that tracks Exit and Guards also: https://encrypted.redteam.net/bleeding_edges/ All the best, SiNA -- "be the change we wish to see in the world." Gandhi

1 0

Rejecting 380 vulnerable guard/exit keys
by Sebastian Urbach 16 Apr '14

16 Apr '14

Hi Roger, That sounds good to me and from what i see there should be at least enough guard capacity to go through with it. Exit's are a whole other matter but honestly if those 12% still running around with the bleedingheart than kick 'em. Hi folks, I'm attaching the list of relay identity fingerprints that I'm rejecting on moria1 as of yesterday. I got the list from Sina's scanner: https://encrypted.redteam.net/bleeding_edges/ I thought for a while about taking away their Valid flag rather than rejecting them outright, but this way they'll get notices in their logs. I also thought for a while about trying to keep my list of fingerprints up-to-date (i.e. removing the !reject line once they've upgraded their openssl), but on the other hand, if they were still vulnerable as of yesterday, I really don't want this identity key on the Tor network even after they've upgraded their openssl. If the other directory authority operators follow suit, we'll lose about 12% of the exit capacity and 12% of the guard capacity. I/we should add to this list as we discover other relays that come online with vulnerable openssl versions. Also these are just the relays with Guard and/or Exit flags, so we should add the other 1000+ at some point soon. --Roger

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays