- tor-relays - lists.torproject.org

Help setting up an exit relay on CentOS linux
by Chuck Bevitt 28 Apr '14

28 Apr '14

Hello all, I've run an exit node from my home in the past using my consumer ISP service (Time Warner) and Windows 8, I'm pretty much of a Windows guy (I make my living building business applications with Microsoft tools) but now I have an opportunity to run an exit node on a hosted server running CentOS linux. I've loaded CentOS at home to test it out and the problem I'm having is that I can't get the Vidalia control to run. The browser bundle works OK - I can open FireFox and make a Tor … [View More]

3 2

Bridge Operators - Heartbleed, Heartwarming, and Increased Help
by Matthew Finkel 26 Apr '14

26 Apr '14

Hi All, Below is an email we sent last week to almost all of the bridge operators who provided contact information for their bridge(s). For those operators we missed and for those we couldn't contact, this hopefully provides some useful information. All the best, Matt ----------------------------------------------------------------------- Hi Tor Bridge Relay Operator! Unfortunately this email must begin with bad news, but it gets better. Due to the recent Heartbleed OpenSSL vulnerability … [View More]that was disclosed earlier this week, we are reaching out to you to ask that you install an updated version of OpenSSL. The vulnerability has the potential to decrease the security of your bridge as well as the anonymity of any user connecting to your bridge. As a result of this, we also ask that you generate a new identity key due to the possibility that your current one was leaked. The process to upgrade your version of OpenSSL depends greatly on your operating system. Please ensure you are using a version that was released within the past four days, see the Heartbleed website[0] for more details on the vulnerability and for which versions are affected. Please do this before you regenerate your identity key. When this is done, you will need to restart Tor. At this point you can ask us to retest your bridge to confirm that it is not vulnerable anymore. Next, to regenerate your identity key simply stop Tor and delete the current key. This is done by opening Tor's Data directory and removing the contents in the keys/ directory. Tor's Data directory is located at /var/lib/tor, by default. Let us know if you have trouble locating it. When this is complete, start Tor and it will automatically create a new identity for you. See the recent blog post for many more details: https://blog.torproject.org/blog/openssl-bug-cve-2014-0160 Now that the bad news was said, we want to take this opportunity to thank you, from the bottom of our hearts, for volunteering to run a bridge relay. We know we do not say it often, but it is really appreciated! Please let us know if you have any question, concerns, or suggestions, especially related to how we communicate with you and how bridge relay operators can be more involved. Lastly, if you are not already running the obfsproxy pluggable transport[1] (i.e. obfs3) on your bridge, please follow the Debian instructions[2] (for a Debian-based system) on the website and install it. Your bridge is a great contribution to the Tor network, however as censorship on the internet increases around the world users are forced to use a pluggable transport. Tor does not understand how to communicate with them by default, though. Therefore we are asking that all bridge operators install obfsproxy and help as many users as possible. In addition, also consider subscribing to the tor-relays mailing list[3], if you are not already; we will be posting instructions on how to maximize the contribution of your bridge on that list every now and then. [0] http://heartbleed.com [1] https://www.torproject.org/docs/pluggable-transports.html.en [2] https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en#i… [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Again, thank you for running a bridge relay and sorry for the bad news. Let us know if you have any questions or if you have any suggestions. All the best, Matt The Tor Project [View Less]

8 10

Relay reading more than it writes??
by Rupert Roe 26 Apr '14

26 Apr '14

Hi All, I recently started running these two relays on raspberry Pis in the UK: http://torstatus.blutmagie.de/router_detail.php?FP=515a9887a426c1dc2bb4b9b1… http://torstatus.blutmagie.de/router_detail.php?FP=e3e6a7de02caa12ac5712884… Both of my relays seem to consistently read more from the network than they write, and I can't figure out why. Are my relays dropping loads of packets? If so is that harming the speed or reliability of the network? Why are my relays doing this when other ones … [View More]

1 0

Please need urgent help with the DNS resolver of a fast exit relay
by s7r＠sky-ip.org 25 Apr '14

25 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, The servers from my ISP are not stable or good enough to handle the traffic for this Tor exit router. I get this in the log very often: Apr 24 15:14:07.000 [notice] Circuit handshake stats since last time: 91633/91636 TAP, 15962/15962 NTor. Apr 24 17:40:45.000 [warn] eventdns: All nameservers have failed Apr 24 17:40:45.000 [notice] eventdns: Nameserver <ip>:53 is back up Both nameservers fail and come back after 1 second, or less. … [View More]

2 2

Exit node rejection of special IPv4 blocks
by Zack Weinberg 24 Apr '14

24 Apr '14

I'd like a sanity check on this list of special-purpose IPv4 blocks which I'm currently forbidding in the CMU exit node's policy. I'm most uncertain about denying access to multicast (224.0.0.0/4) and 6to4 router anycast (192.88.99.0/24) -- I *think* there are no scenarios where someone would actually need to get at either of those via Tor, but I could be wrong. # Reserved IPv4 addresses, sorted by RFC and then numerically reject 255.255.255.255/32:* # RFC 0919: "limited broadcast" reject … [View More]

3 2

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

23 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 … [View More]

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 … [View More]

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 … [View More]

2 1

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

21 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 … [View More]

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 … [View More]

2 2