- tor-relays - lists.torproject.org

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

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

NSA knew about Heartbleed
by Jesse Victors 13 Apr '14

13 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Saw this article: http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-b… "The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said. The NSA said in response to a Bloomberg News article that it wasn?t aware of Heartbleed until the vulnerability was made public by a private security report. The agency?s reported decision to keep the bug secret in pursuit of national security interests threatens to renew the rancorous debate over the role of the government?s top computer experts." Thanks NSA, glad you've got our backs there. If you run a relay and you have been on one of the affected versions of OpenSSL, I would urge you to STRONGLY CONSIDER your relay compromised. Delete your keys per the recommendations and let Tor generate new ones. It's better to cripple the network temporarily while we come back from this, rather than preserving the uptime with possibly compromised keys. Security matters here. Please follow the best practice recommendations. If you run a web server, rekey your SSL certificates. Basically, if you were affected, consider encryption to have been bypassed and passwords and other sensitive information compromised. We cannot afford to take chances here. If the NSA knew it, you can also bet that someone else with a good static analyzer discovered it as well, I'll let you imagine one. Good luck out there everyone, we really need to revoke our keys if we were affected. Seriously, guys. It's worth it. On a lighter note, https://xkcd.com/1354/ Stay safe. Live long and prosper. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCgBmBQJTSImHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA0nIIAKj1lOXRGcwMFd39CxjnymSN FVzrPUa/JomCJHqW/A0xSFdxbVAZIvio6C1phuWHmiiDKhsBuBGwLNzXQMGFltaw BnaTO1lLCvvSbEdmXPg12hR3YqR1d5D7Xnb0iTlSfrjZ7gGDEsXoJG3pU/V/RCFo IOEqxfZtVcI3DdrImlwcR6gPw6ip9JlTo49w8ncy6/K4cHED2liCQ13JvWjaQzSl uB06eWNsNo1IhPCKkZ7gFzharhN/4kAQrytC+ZcTmIrXdPrsd1lUaVICHWK9AEon sciDu5lI77srXWwt77YVAKw6Jrls41N3USgvKBSrxZhfBVQlCPOmoXtTHdwbhks= =pmBQ -----END PGP SIGNATURE-----

10 13

Relays vulnerable to OpenSSL bug: Please upgrade
by Moritz Bartl 13 Apr '14

13 Apr '14

https://blog.torproject.org/blog/openssl-bug-cve-2014-0160 A new OpenSSL vulnerability on 1.0.1 through 1.0.1f is out today, which can be used to reveal memory to a connected client or server. If you're using an older OpenSSL version, you're safe. Note that this bug affects way more programs than just Tor — expect everybody who runs an https webserver to be scrambling today. If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle. Here are our first thoughts on what Tor components are affected: Clients: Tor Browser shouldn't be affected, since it uses libnss rather than openssl. But Tor clients could possibly be induced to send sensitive information like "what sites you visited in this session" to your entry guards. If you're using TBB we'll have new bundles out shortly; if you're using your operating system's Tor package you should get a new OpenSSL package and then be sure to manually restart your Tor. Relays and bridges: Tor relays and bridges could maybe be made to leak their medium-term onion keys (rotated once a week), or their long-term relay identity keys. An attacker who has your relay identity key can publish a new relay descriptor indicating that you're at a new location (not a particularly useful attack). An attacker who has your relay identity key, has your onion key, and can intercept traffic flows to your IP address can impersonate your relay (but remember that Tor's multi-hop design means that attacking just one relay in the client's path is not very useful). In any case, best practice would be to update your OpenSSL package, discard all the files in keys/ in your DataDirectory, and restart your Tor to generate new keys. Hidden services: Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Like the last big OpenSSL bug, this shouldn't allow an attacker to identify the location of the hidden service, but an attacker who knows the hidden service identity key can impersonate the hidden service. Best practice would be to move to a new hidden-service address at your convenience. Directory authorities: In addition to the keys listed in the "relays and bridges" section above, Tor directory authorities might leak their medium-term authority signing keys. Once you've updated your OpenSSL package, you should generate a new signing key. Long-term directory authority identity keys are offline so should not be affected (whew). More tricky is that clients have your relay identity key hard-coded, so please don't rotate that yet. We'll see how this unfolds and try to think of a good solution there. Tails is still tracking Debian oldstable, so it should not be affected by this bug. Orbot looks vulnerable; we'll try to publish more details here soon. It looks like most of the webservers in the https://www.torproject.org/ rotation need upgrades too, and maybe we'll need to throw away our torproject SSL web cert and get a new one — hopefully we'll deal with all that soon. -- Moritz Bartl https://www.torservers.net/

20 29

Should I Worry @ INTRODUCE1 Warnings
by Tami Kennedy 12 Apr '14

12 Apr '14

Hello, non-exit relay (Tor 0.2.4.21) started seeing these log Warning entries. Concern or normal? Apr 05 06:02:40.810 Warning Rejecting INTRODUCE1 on non-OR or non-edge circuit 2147503731 Apr 05 06:49:47.107 Warning Rejecting INTRODUCE1 on non-OR or non-edge circuit 2147493910 -Tami

4 3

Re: [tor-relays] NSA knew about Heartbleed
by Eric Giannini 12 Apr '14

12 Apr '14

This is an excellent email. ------------------------------ On Fri, Apr 11, 2014 5:32 PM PDT Jesse Victors wrote: > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA512 > > >Saw this article: >http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-b… > >"The U.S. National Security Agency knew for at least two years about a >flaw in the way that many websites send sensitive information, now >dubbed the Heartbleed bug, and regularly used it to gather critical >intelligence, two people familiar with the matter said. The NSA said in >response to a Bloomberg News article that it wasn?t aware of Heartbleed >until the vulnerability was made public by a private security report. >The agency?s reported decision to keep the bug secret in pursuit of >national security interests threatens to renew the rancorous debate over >the role of the government?s top computer experts." > >Thanks NSA, glad you've got our backs there. > >If you run a relay and you have been on one of the affected versions of >OpenSSL, I would urge you to STRONGLY CONSIDER your relay compromised. >Delete your keys per the recommendations and let Tor generate new ones. >It's better to cripple the network temporarily while we come back from >this, rather than preserving the uptime with possibly compromised keys. >Security matters here. Please follow the best practice recommendations. >If you run a web server, rekey your SSL certificates. Basically, if you >were affected, consider encryption to have been bypassed and passwords >and other sensitive information compromised. We cannot afford to take >chances here. If the NSA knew it, you can also bet that someone else >with a good static analyzer discovered it as well, I'll let you imagine one. > >Good luck out there everyone, we really need to revoke our keys if we >were affected. Seriously, guys. It's worth it. > >On a lighter note, https://xkcd.com/1354/ > >Stay safe. Live long and prosper. >Jesse V. > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.14 (GNU/Linux) >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iQF8BAEBCgBmBQJTSImHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w >ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB >RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA0nIIAKj1lOXRGcwMFd39CxjnymSN >FVzrPUa/JomCJHqW/A0xSFdxbVAZIvio6C1phuWHmiiDKhsBuBGwLNzXQMGFltaw >BnaTO1lLCvvSbEdmXPg12hR3YqR1d5D7Xnb0iTlSfrjZ7gGDEsXoJG3pU/V/RCFo >IOEqxfZtVcI3DdrImlwcR6gPw6ip9JlTo49w8ncy6/K4cHED2liCQ13JvWjaQzSl >uB06eWNsNo1IhPCKkZ7gFzharhN/4kAQrytC+ZcTmIrXdPrsd1lUaVICHWK9AEon >sciDu5lI77srXWwt77YVAKw6Jrls41N3USgvKBSrxZhfBVQlCPOmoXtTHdwbhks= >=pmBQ >-----END PGP SIGNATURE----- > >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Long-term effect of Heartbleed on Tor
by Tom van der Woerdt 10 Apr '14

10 Apr '14

What's the long-term effect of Heartbleed on Tor? * Should we consider every key that was created before Tuesday a bad key and lower their consensus weight? * Should authorities scan for bad OpenSSL versions and force their weight down to 20? A lot of relays will continue running bad OpenSSL versions which seriously hurts the security of Tor. A month from now the NSA/CGHQ/CIVD/etc may know the private keys of a large chunk of these relays and possibly be able to decode a big chunk of traffic... Tom

6 7

Re: [tor-relays] Strange Problem Browsing Blocked Websites‏
by sssheep 10 Apr '14

10 Apr '14

On Thu, 10 Apr 2014 04:26:27 +0000 (UTC) Enrique Fynn <enriquefynn(a)gmail.com> wrote: > On 10 April 2014 01:01, Tor Relays at brwyatt.net <tor(a)brwyatt.net> > wrote: > > > > If I remember correctly, Firefox has a bug where it won't do DNS > > lookups over a SOCKS proxy. It will, however do DNS lookups through > > an HTTP proxy that supports it, such as Polipo. If you configure > > Polipo to act as an HTTP proxy that forwards to the Tor SOCKS > > proxy, and add Polipo to your Firefox config as an HTTP proxy (you > > can leave Tor's SOCKS proxy entry), this may resolve the issue your > > are seeing, assuming DNS blocking/filtering in your country. > > > > Bryan > > That's not a bug, it's firefox default behavior. To change this: > 1- Go to about:config > 2- Set network.proxy.socks_remote_dns to true > This is set already in TBB which you should be using. It exists for a reason, use it instead of attempting to create your own solution.

1 0

Strange Problem Browsing Blocked Websites‏
by Ferdi GULER 10 Apr '14

10 Apr '14

Hello All, Today I have installed tor on my raspberry pi and also set it up as a relay. I can monitor tor traffic using arm so it means it is working. My SocksPort configuration is 9050, 192.168.1.187:9050 where 192.168.1.187 is internal ip of my raspberry pi.In order to anonymize my browsing traffic on my main windows PC, I configured Firefox to use my raspberry pi as proxy on port 9050. When I visit the page https://check.torproject.org/, it says my configuration is successful and I see different ip address. From that point I assume everything should work properly but if I try to browse web sites that are blocked in my country such as youtube it just does not connect. However if I use VPN I can see those blocked web sites. So could anyone please tell me what is wrong with my configuration? I'm realy confused... Thanks in advance!

4 4

Atlas Entry
by Tor Relay 09 Apr '14

09 Apr '14

My several attempts to update to TBB 3.5.4 (XP)unsuccessfully made Tor exit upon starting, so I fell back to 3.5.3. Atlas shows that my efforts hadn't gone unnoticed; OnionTorte now appears four times w/ my IP address. 0D50D43BAA728D6E0C4EB181AB79E5C1D7036D08 is the correct one but it somehow has my bandwidth as 489 KB when it should be 921.6 KB, reflecting my RelayBandwidthRate. Does anybody have a way of clearing the ghost entries and setting Atlas straight on my bandwidth? Thanks, P -- Dirt kicked to the curb goes into the gutter. Professionals kicked to the curb go into retail.

2 1

Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
by tor＠t-3.net 09 Apr '14

09 Apr '14

On 04/09/2014 04:39 AM, Roger Dingledine wrote:> On Tue, Apr 08, 2014 at 07:31:43PM -0600, Jesse Victors wrote: >> I'd recommend that every relay operator delete their keys as well, > > Not every. Those on OpenSSL 0.9.8, e.g. because they're using Debian > oldstable, were never vulnerable to this bug. I imagine there are some > FreeBSD or the like people out there in a similar boat. And Centos > people, etc. > > --Roger > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > The most up-to-date CentOS was supposedly vulnerable? Same as RedHat. But I don't know how to test for the vulnerability itself so I don't really know. Redhat's emailed warning to update OpenSSL went out yesterday as "Security Advisory - RHSA-2014:0376-1". CentOS' updated OpenSSL was available right away as well, and the CentOS 6.5 boxes pulled it right down in an update. I did have some slightly older CentOS 5 boxes which had a version of SSL that was reportedly not vulnerable. Page heartbleed.com said: How about operating systems? Some operating system distributions that have shipped with potentially vulnerable OpenSSL version: Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4 Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11 CentOS 6.5, OpenSSL 1.0.1e-15 Fedora 18, OpenSSL 1.0.1e-4 OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012) FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013 NetBSD 5.0.2 (OpenSSL 1.0.1e) OpenSUSE 12.2 (OpenSSL 1.0.1c) Operating system distribution with versions that are not vulnerable: Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14 SUSE Linux Enterprise Server FreeBSD 8.4 - OpenSSL 0.9.8y 5 Feb 2013 FreeBSD 9.2 - OpenSSL 0.9.8y 5 Feb 2013 FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)

2 1

any action required for AWS cloud relays?
by lee colleton 09 Apr '14

09 Apr '14

I have relay(s) running in AWS. Will they auto-update? Do I need to take any action?

3 3

Clarification regardind business as usual
by Sebastian Urbach 09 Apr '14

09 Apr '14

Hi, I want to clarify my mail from earlier today regarding the recovery of the network / relays. I wrote that i expect business as usual within 2-3 days for the vast majority of the relays. That does not mean that everything is the way it was before. When the content of the /keys directory is gone you have basically a new relay and therefore the process of getting flags starts from scratch. Roger posted an excellent article regarding the life cycle of relays: https://blog.torproject.org/blog/lifecycle-of-a-new-relay -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman

1 0

TTTT
by Sebastian Urbach 09 Apr '14

09 Apr '14

Dear list members, There are also some good News in this in this sad OpenSSL days. The TTTT data collection server is back as well as the Scoreboard. Everybody who has some stored data (or new Volunteers), feel free to remove the parking brakes and start submitting ;-) New Scoreboard URL though: http://hatswitch.ece.illinois.edu/tor-traceroutes/relay_scoreboard.html Project: http://web.engr.illinois.edu/~das17/tor-traceroute_v1.html -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman

1 0