- tor-relays - lists.torproject.org

Bridges included in Tor Browser -- should they regen keys because of Heartbleed?
by David Fifield 24 Apr '14

24 Apr '14

I wondered whether operators of bridges that are included in the browser bundle should generate new identity keys after upgrading their OpenSSL. The argument for generating new keys is that old keys may have been compromised by Heartbleed. The argument against is that a new fingerprint will prevent existing browser bundle users from using the default bridges, because the fingerprint is built into the browser: https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/Bu… What I heard from some developers is that it would be good to set up new bridges with new keys (could be on the same IP address), and give the new information to the browser devs so they can put it in the bundles. Leave the old ones running for a while until usage drops off. A question is how to actually do this, running two copies of tor on the same IP. Offhand I would say that using a separate DataDirectory will be enough, but I don't know for sure. David Fifield

1 0

Grouping cloud relays running within same provider
by mr.curtis＠urssmail.org 23 Apr '14

23 Apr '14

Many people are running Tor relays on virtual servers "in the cloud", using VPS providers like Amazon EC2, Rackspace, Linode, etc. Most major VPS providers offer virtual servers in multiple geographical locations, but they are still controlled by one entity, which of course ultimately have total access to any storage (RAM and disk) of any customer VPS, easily compromising any crypto key material. I don't think it is necessarily that bad to trust VPS providers (and they often are a great way to get excellent bandwidth cheaply), but I feel it would be important to somehow make sure Tor users don't end up having circuits that all go through relays running on e.g. EC2. Same way you're supposed to group your own relays with MyFamily. Is there any way currently to do this, or are there already some safeguards in place?

5 5

Strange behaviour on Atlas output after Key rotation
by Geri 22 Apr '14

22 Apr '14

Good evening all! I just have a question regarding my relay's status on Atlas. Approx. 5 days ago i have rotated all my keys (deleted /keys dir) after Roger's advice for doing so for best security. Since then i am obersing a strange behaviour. From time to time i am checking my relay's status at the Atlas webpage which i have done after the key rotation. But now all my relays are listed twice - other than that also the old relays with the old fingersprints are still listed as "running". Is anybody aware of that strange situation? It seems that on the other Tor Status page (torstatus.rueckgr.at) the new relays are listed correctly. thanks for any advice! Cheers, Geri

2 1

Relay not gettings flags, changing IP
by Niels Hesse 22 Apr '14

22 Apr '14

I updated OpenSSL, removed my keys and restarted the Tor service on my Debian relay. Now I have been running it for 3 days and I still haven't gotten any flags and the relay is not visible in Atlas. Arm keeps saying: "[NOTICE] Our IP Address has changed from 141.101.117.220 to 141.101.116.220; rebuilding descriptor (source: METHOD=RESOLVED HOSTNAME= tor-relay.onlineprivatliv.dk)." Here's a screenshot: http://puu.sh/8hBlM/71bbcb5aff.png I am not sure what is going on here. Do you have any idea? Thanks in advance.

2 1

Announcing the removal of Tor v0.2.2.x relays
by Nusenu 21 Apr '14

21 Apr '14

Hi, as Roger mentioned in a side note [1], tor relays running Tor v0.2.2.x have been removed from the consensus (#11149) [2]. Even if relay operators with ContactInfo were contacted directly I think this information would be worthwhile to be mentioned on tpo's twitter feed and blog. This might increase the likelihood that people still running ancient tor versions get to know about it. (even if people running such old tor versions are unlikely subscribers of either news feed ;) Question arisen from looking at the relays by version graph: If you look at that graph you see that on 2014-04-08 the number of relays (in the consensus) running 0.2.2.x were about zero, and now (2014-04-21) we are back at about 170 v0.2.2.x relays. https://metrics.torproject.org/network.html#versions Why is that? Has the decision postponed/revisited due to the concurrent reduction of relays (heartbleed)? One (fast) v0.2.2.x relay as an example: https://atlas.torproject.org/#details/F499B62325DA32EEAA6451ABF0764E096C8CC… [1] https://lists.torproject.org/pipermail/tor-relays/2014-April/004362.html [2] https://trac.torproject.org/projects/tor/ticket/11149 [3] https://twitter.com/torproject

2 2

No Bridges Being Returned by Onionoo
by Matthew Dobbins 21 Apr '14

21 Apr '14

Does anyone know why no bridges are being returned by the Onionoo Service? The summary page (https://onionoo.torproject.org/summary) lists normal relays, but returns an empty bridge list. Also, a detailed bridge query (https://onionoo.torproject.org/details?type=bridge) also returns an empty list. Cheers, mjd

2 1

Sudden drop in number of active relays
by Jesse Victors 21 Apr '14

21 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey everyone, I just checked in on https://metrics.torproject.org/network.html and noticed that there's been sudden drops in the number of relays which seems to have caused all other graphs to tank as well. It's too late for this drop to be caused by Heartbleed fixes, so what could explain this? Were these relays banned by the network because they were vulnerable to Heartbleed? Does anyone know what the deal is here? Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCgBmBQJTVFMhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAM/kH/0UrCcJxEAhnAL669KuycKZD gopUNwG/sdC0khwXeQKomqYkE4BZCGgvjkDV8geoqvuSv51HJ6aq42UfaNzlCRqP phFgCZNPdAPQ+8ka4WFmhOuMjZh2V1Ylahzl/NmSXcVyaAhN3SsbhBrk6uk0goCm nHJIYdUayl3sHdPQgdaGGjI+YXqQY1Uv/UIQxXgVPTZuYlf+PuM+lMGIun55Qzvg FHjjwMlY/MUIbka9DupVkmF7q5FaDDeWOpC96JpD1o8MxKoZWDCnFPiAMWRiFNFp WL5Hc5U9pDcg524rxTewJKHv19t6HiNanQMe6o5dsvaqLyaI43X4WrZSNb/TfSQ= =9ZeT -----END PGP SIGNATURE-----

2 1

Re: [tor-relays] Relay down, "rejected", help
by kbesig 20 Apr '14

20 Apr '14

Relay's up and running using arm , both running as <user>. A big thank you to all who responded with suggestions all of which lead to a successful conclusion!

1 0

VPS suspended for many SSH connections
by I 19 Apr '14

19 Apr '14

2 1

(no subject)
by John Katakowski 19 Apr '14

19 Apr '14

Hello Hey since the open ssl was found you folks have been pounding my e-mail box I understand ,anyway can't authenticate my password to unsubscribe for a bit could you send it to my e-mail I have updated my yahoo e-mail password like they said. Sincerely John P. Katakowski.

1 0

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

19 Apr '14

I'm researching more on Raspberry and I see its way cheaper to run a relay this way. Won't cost me more the 100ε for a relay that will be self-sustaining. Considering there won't be any monthly expenses (except the internet) the initial investment can be recovered, 24/7 relay and no electricity cost, perfect! Chris Whittleston <csw34(a)cam.ac.uk> wrote: >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

4 4

"What fraction of the tor network by consensus weight are the openssl-vulnerable relays?"
by Kostas Jakeliunas 19 Apr '14

19 Apr '14

Making a separate thread so as not to pollute the challenger[1] one. Roger: you wanted to know (times are UTC if anyone cares), [22:08:35] [...] we now have a list of 1000 fingerprints, and we could > pretend those are in the challenge and use our graphing/etc plans on them > [22:08:45] they happen to be the relays vulnerable to our openssl bug > [22:11:43] "what fraction of the tor network by consensus weight are they?" > [22:11:49] "over time" Given them[2], the challenger (with minimal changes to fix downloader and to make Onionoo not falter)[4] will spit out the following results: - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-bandwidth.… - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-weights.js… - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-clients.js… oh, this one's empty. Why is it empty? Didn't look into it.] - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-uptime.json The 'combined-weights.json' is probably the one you might be after. But that's all I did for now. You also said that these aren't all the vulnerable relays that there are out there. You linked to a more complete list[3], but it has some typos, etc. I haven't done anything with it, maybe someone will take over, or I will do something later on. [1]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004214.html [2]: http://ravinesmp.com/volatile/challenger-stuff/vuln_fingerprints.txt [3]: http://freehaven.net/~arma/vulnerable-keys-2014-04-08b [4]: commits: - https://github.com/wfn/challenger/commit/38d88bcb1136f97881f81152d3d883c4e9… - https://github.com/wfn/challenger/commit/39c800643c040474402fc62d2a2db75c25… - https://github.com/wfn/challenger/commit/7425ef6fc00dedf3b2b7f2649e832fb4c9… -- kostas / wfn 0x0e5dce45 @ pgp.mit.edu

2 4

False warnings about inaccurate clock
by Stephan 19 Apr '14

19 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 19 Apr '14

19 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

Rejecting 380 vulnerable guard/exit keys
by Roger Dingledine 16 Apr '14

16 Apr '14

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

3 2

NHS UK blocking Tor?
by Chris Whittleston 16 Apr '14

16 Apr '14

Can someone else running a relay from their home connection confirm that they get an 'Access denied' error from http://www.nhs.uk? I've checked with someone using the same ISP in the flat above me and they seem able to access the site just fine, as can I via mobile internet so I'm down to suspecting that they are blocking all Tor relay IPs. This is the exact error I get: Access DeniedYou don't have permission to access "http://www.nhs.uk/" on this server. Reference #18.1f7f1002.1397514736.1fe2170c The reference seems to change each time I visit. If this does turn out to be them blocking Tor - advice on how to approach contacting them to resolve this would be appreciated. Thanks, Chris -- *Dr Chris Whittleston 栗主* Department of Chemistry University of Cambridge Lensfield Road, Cambridge, CB2 1EW Email: csw34(a)cam.ac.uk Tel: +44 (0)1223 336423

10 12

Consensus weights in light of recent insecurities
by Tora Tora Tora 15 Apr '14

15 Apr '14

I have two relays running, both with patched up SSL, latest alpha build and with new keys. Both are stable and guards, yet since the last restart several days ago one transferred: 40GB - https://atlas.torproject.org/#details/D0B1FAD2AE3C5CA526D8329D20FA55BF2BFDA… and the other 2GB - https://atlas.torproject.org/#details/3597D85E08CC511923A4E74F7F54E209E01E0… ; consensus stuck at 20 Given the situation with the recent insecurities, the latter relay sure seems under utilized. I realize that my relays are considered "small" by some standards, but somehow I was made to believe that in Tor is all about mixing things up. A paid-for bandwidth is a terrible thing to waste. :-)

1 0