- tor-relays - lists.torproject.org

Fwd: [tor-talk] Fwd: Ops request: Deploy OpenVPN terminators
by grarpamp 15 May '14

15 May '14

to list, not me. ---------- Forwarded message ---------- From: Mirimir <mirimir(a)riseup.net> Date: Wed, May 14, 2014 at 11:58 PM Subject: Re: [tor-talk] Fwd: [tor-relays] Ops request: Deploy OpenVPN terminators On 05/14/2014 09:07 PM, grarpamp wrote: >> On Tue, May 13, 2014 at 5:48 PM, Jeroen Massar <jeroen(a)massar.ch> wrote: <SNIP> >> <user - ovpn - torcli> -- <exit torrelay or_ip - localhost - ovpn_ip> -- world > >> That "ovpn" part on the left is easily detected by any party in the >> middle doing > > No. Understand the diagram. It is not detectable by anyone > between torcli and torrelay, because that is just normal > tor. > >> Note that you are running IP over TCP over Tor (which is over TCP). > > Of course. Unless of course, as suggested before, some operators > choose the method of binding/routing their exit over an ip different > from their OR_IP, then it would just be native tor and native TCP. > >> The performance of that will be very bad. Tor network is already >> overloaded enough as it is. > > No it won't, I've tested it, it works just fine. The only issue is the > exit ip may change. So the exit operator is expected to block > access to ovpn_ip from anything other than their associated or_ip, > and the user is expected to config their client to use only the > associated exit per whatever 'world' usage session they have in > mind. It's not supposed to be point-click easy, only possible. That's a very cool idea :) Using $5/mo VPS, there could be a large pool of exit IPs for each Tor exit. <SNIP> ----------

1 0

Thinking about deploying a new node
by Lance Hathaway 15 May '14

15 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So, every now and then, somebody asks what the best use of a node would be--bridge, relay, or exit. And yes, this is one of those requests. This would be a VPS from VPS Nodes. I checked the list of good and bad ISPs, and they don't seem to be listed. So I asked them directly how they felt about Tor, and this was the response: "While we don't specifically disallow Tor by name, it does come under the ToS as it is commonly used to launch large scale DDOS and SPAM campaigns and is therefore not allowed on our network for that reason. rDNS is provided as standard, you need to have a valid FQDN A record associated with the IP address that is assigned to your container. As far as SWIP, I would have to pass the request on to management as they are the only ones with that access." Seems pretty clear to me that they're not in favor of having an exit on their network. (I brought up the reduced exit policy and asked specifically about SWIP so that I could handle most of whatever abuse complaints come in, but they wouldn't provide anything further than this response.) That leaves bridge or standard relay. My question is, given 3TB of monthly bandwidth and a 100Mbps (shared) uplink, would it be better to run as an entry/middle node, or as an obfs3/scramblesuit bridge? (If there are other suggestions for trying to talk VPS Nodes into allowing an exit node, I'm all ears--though it may be better left with somebody with more experience talking to ISPs.) Thanks in advance, -Lance -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBCgAGBQJTdCUCAAoJEECmBqfoBgXnV2EQAKcP+K+b698oExGXuI3C5FLh YOGU6z1XQy6C/ERkcNxqTfSbqF/5Izm1ey+1qzr41keVUQ1CKkPgGWbgz/plnCbu ZJf3riJrYucg27RHCSioz3ZBt8NV7d8msRrJAVsUoZy90MyghxYTXH6faGBrLNdw tUnhT9IhSp2C46/JBlPa02FM3Aa4JXggnuhxmUNzpCsNun12D+U3AXefStOjo2GC a9CnXFxxmvHURm7CRlXm7VDMyXZYtWWvBny3ndXhAwdp1EXJ67cjcxdml7PNRYqD 6OOWbfc70i6f8f5YhFFvcsLBlxBaTFTLBWz3J7SQPbVk6W8x8Av3rSvfky7wGyW7 qdbB1UI2FvsIVVCzr8e5bZxjxxUIABMm3Dpg5P+d0y7m7Gts9QhfLtgDMDZHwTYO bbsaDjJO7hUlFFd029PPW6PkH1dSD6pIjkE78ZAX57+5ZBk6JeMhOl8uWeqvbkbz KlOJJ34w0dVLCYiSF+q/BT2tlRMYVjUnQpbWHoxIZNcqBF4bzHdh0O5p/Fg0LSwD GFMOeRpMIDe6oJhU9xo/rdEVjIUGA9rRCBalT2N9fD3XhMQRGm4z/4e41A+YOE61 00BqybYG3Cof87QGqvZEv7zg8w0iU1n2LT52MvpfnQC15QoDvq8GA8C4wAoNpdQv Te15KnmiIweVAXjZBzZ1 =PeIP -----END PGP SIGNATURE-----

2 1

Any Tor/Linux coaches in Sydney?
by I 14 May '14

14 May '14

5 6

How to handle an abuse report
by Ch'Gans 14 May '14

14 May '14

Hi all, Since 3 weeks, I'm running a TOR exit node [1] on a server I rent from Hetzner (A German hosting company), after reading about using Hetzner to run a TOR node, I decided to go for the "restricted" mode to avoid any stupid copywrong issue (That is, I allowed only a limited set of ports, which sadly excludes p2p). Everything went well so far, until today. Someone, let's call this person/group "A", reported an abuse to Hetzner. A TOR User, "B", is spamming chat/forums with vociferous insults and disrespectful messages, I got a copy of few of them and the insults from B are as bad as the ideas defended by A, but I'm not here to judge anyone... From A's timezone, it happened from the 9th of May, 8:20PM to the 10th of May, 2:30 AM. Given the nature of the TOR network, I assumed that it is very unlikely that stupid-B will use my server's IP to insult stupid-A any time soon... or is it? Now, I have to report to Hetzner, I will tell them that I'm running a TOR exit node in "restricted" mode, but how can I defend myself, I am not sure that my "restricted node" and "given the nature of the TOR network" arguments will convinced them the Hetzner dudes. Could anyone gives advice, feedback or stories on how to deal with this situation? Best regards, Chris [1] https://atlas.torproject.org/#details/18B6EBAF10814335242ECA5705A04AAD29774… -- QtCreator/qmakeparser.cpp:42 ////////// Parser /////////// #define fL1S(s) QString::fromLatin1(s) namespace { // MSVC2010 doesn't seem to know the semantics of "static" ...

6 9

Linux CVE-2014-0196
by zwiebel＠quantentunnel.de 13 May '14

13 May '14

Hi I received a notice from a server provider to immediatly update/upgrade/reboot if I would use Debian. It's the CVE-2014-0196 issue. I did and it came up with Wheezy 3.2.57-3+deb7u1 which should be fine. How relevant is this issue? Felix ==========---------- - - - - - - - - - - ----------========== -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (MingW32) mQENBFL/5VoBCAC8l2gGmuy2hZf866dDkwzOvMkyJlfnFZU6T5LWe4uPIx0a8R1U cmj/Vut2yUCaJgvFpdOVA3mmXC58zoDeiW7Um6q6otD6BR2hXdgyBTAgqkQ0BsYx epb4UXBz/u3TJmv655fBnXeDgCB8L5BIkcsmX6EoBNUs6a3TPMhX3UXOtEKLXJeZ 2QtoDxwXqHNSmW7jLq+qkpriVDqxDTFv+muZRE+Zn/6PZpEASvpSdVdT/1giEMUL QQFIP6cBPY2GYIaNCO1dYRj9ebM7ewWjCiOiOw6/eylxan8vfFntgaPU3J7W2wJp RiRtUIjT+TDycVyNk7gy4wV2Rj8+58+Krk1tABEBAAG0IEZlbGl4IDx6d2llYmVs QHF1YW50ZW50dW5uZWwuZGU+iQE5BBMBAgAjBQJS/+VaAhsPBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4AACgkQC2jb92rYqyMGxQf/d9oJf0qpgXZaUmcqujQ3DVsc uvYOnK2MJCpDIvvZYdQTcnG2jz8/na1ZyfAGeKhYZ18ypONwSQYthC17L5GHQ2H3 Pg/H0GARtx4aJR5TtIKnhPR8yYdlikCuTBb5QSFJUUtEz91SqDW7EXNbMC4RRSEd BWWirADCJWitoR3JCC13r+CF6TCFDluClAht/t56f7prBzARVYWmlbgYD2yx4Uzs FOl0vvhW2o9dpVaLZ6mSHAyNzefCFcNumRUxqa+V6nY94dd8BV8xH0lOd1xaMtZW HuxIU9Sbh13OlJyBAvVffVBL+4sEOpc8XB6Yl/pmyjEjUSvC7lP3T+Ix9Mnk/A== =kfXw -----END PGP PUBLIC KEY BLOCK-----

2 2

Tor bridges on borrowed ports
by kzhm＠mailtor.net 08 May '14

08 May '14

Hello, assuming I have a friend, Bob. He has two IP addresses and wants to contribute to the tor network. He doesn't want to operate an exit, relay or bridge himself, though. I offer him to operate the bridges on my hardware and he's magically forwarding the required ports from his machines IPs to my machine so I do the relaying part of the bridging game. Bridge users benefit from the additional IP addresses that have to be blacklisted. I'm looking for a way to implement this. I could only think of *) inetd + nc *) dark iptables nat magic *) some sort of ip-over-ip tunnels which would all be kind of hacky, require installation of addition software and would probably have sideeffects on tors bridge stats. Can I announce an address that isn't directly mine? Can I use my address for outbound traffic to the next relay or do I need to use the "bridge address" for that? Is there a flaw in there? Is somebody already doing that? I'm putting this up for discussion. If I can get this working for Bob I could probably get access to some subnets from Charlie and Dave.. Waiting for input. Truly yours, Alice.

2 3

About running an Exit node
by Pika ohc 08 May '14

08 May '14

Hi there, I was considering to run an Exit node with my own pc, however, i have some questions about exit node. 1. How can I know if there is a client specifying me as an exit node and the traffic is sent from the client to me directly(where my exit node is the first node and also the last node for the client.)? 2. If i found some clients trying to do something bad by using the method mentiond in 1., how can I stop him? Is iptables or anything else can help me to block such clients? Hope there's someone can answer me. Thank you!

6 6

Mac OSX 10.6, re-installed, TBB downloaded, installed?, terminal window....what now?
by Robert Smith 08 May '14

08 May '14

I am NOT a Unix user. Decades ago, I was very skilled on an Amiga computer (I heard Amiga DOS was basically Linux). I have almost no experience on Macs. I hate them. My first attempt at installing Vidalia gave me a message saying: "You can't run Tor Browser with FireFox running". All programs that appeared in the "startup list" were unchecked (FireFox was not among them). Then after a cold boot, I got the same message. So I wiped the F##@$ Mac and re-installed only the OS (Snow Leopard) then updated it to the latest, 10.6 17. Then I download TBB again. Again I got just a terminal window. I tried to download and install the GUI version so I could get a simple bridge or relay running, but it looks the the terminal window is all I am going to get. If someone could post a link where I could download and install software for running a Tor relay or bridge, I'd appreciate it. Most computer users of my age are not nearly as experienced as I am. All lot younger than me, and they may not have the resources or interest to run a Tor relay. If it's hard to run relay or bridge on the most dumbed down OS (Macs seem very stable, but frustrating in anything I have attempted), who is going to be running relays? The 0.1% of the people out there. Mostly Linux experts and no one else. I'd run in on one of my PC's for now, but life is not allowing me the time, to make that an option at this time. Thanks for any advice.

2 1

Re: [tor-relays] Trying Trusted Tor Traceroutes
by starlight.2014q2＠binnacle.cx 08 May '14

08 May '14

At 22:35 5/7/2014 -0500, Anupam Das wrote: >Those are not our machines and moreover, we have not received any measurement (i.e., traceroute data) from those IPs. One more thing our traceroutes use UDP packets, not TCP packets. Thank you for your reply. I blocked the IPs.

1 0

Re: [tor-relays] Trying Trusted Tor Traceroutes
by starlight.2014q2＠binnacle.cx 08 May '14

08 May '14

forgot log entries

2 1

Re: [tor-relays] Trying Trusted Tor Traceroutes
by starlight.2014q2＠binnacle.cx 07 May '14

07 May '14

>Dear list members, > >Just a quick update regarding the TTTT >project. There are multiple GB's of data to >analyse and it is still being worked on. We are >also working on the public script(s) as well. > >Sebastian Urbach Have been seeing some dubious traffic warnings the last few days on the firewall from 50.116.9.77, 74.207.228.161 and 109.74.204.217. Are these IPs performing traceroutes for your project and can you vouch for them? If so will it improve your results if the ICMP TTL-expired packets are permitted? You should avoid the duplicate TCP SYNs if you don't want to annoy people. Maybe explain exactly (and tersely) how this works. If they're not yours they go on the black-hole ACL never to be seen again.

1 0

(no subject)
by I 07 May '14

07 May '14

4 4

SSH scans from Tor exit
by I 02 May '14

02 May '14

12 21

Relay down, "rejected", help
by kbesig 30 Apr '14

30 Apr '14

My relay became one of the "rejected" since the heartbleed vulnerability surfaced so I reformatted my XP relay and did a fresh Ubuntu 14.04 LTS install. Built vidalia-0.2.21 from source using: deb http://deb.torproject.org/torproject.org trusty main deb-src http://deb.torproject.org/torproject.org trusty main apt-get install build-essential fakeroot devscripts qt4-dev-tools qt4-designer libqt4-dev g++ cmake apt-get build-dep vidalia mkdir ~/debian-packages; cd ~/debian-packages apt-get source vidalia cd vidalia-* debuild -rfakeroot -uc -us cd .. sudo dpkg -i vidalia_*.deb Edited /etc/tor/torrc allowing connection ports. I'm unable to open vidalia with these error messages: 1. As non-admin: /usr/bin/vidalia (process:540): GConf-WARNING **: Client failed to connect to the D-BUS daemon: An AppArmor policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus) (<unknown>:540): GLib-GIO-ERROR **: No GSettings schemas are installed on the system Trace/breakpoint trap (core dumped) 2. As root: /usr/bin/vidalia No protocol specified vidalia: cannot connect to X server :0 3. As root: /usr/bin/X11/vidalia No protocol specified vidalia: cannot connect to X server :0 I've seen similar errors searching for a fix, but none that seemed "resolved". Any suggestions would be appreciated as I'd like to get back up and running ASAP Thanks ------------------------------------------------------------------------

15 23

MaxAdvertiseBandwith
by jchase 30 Apr '14

30 Apr '14

Hi, I have a non-exit relay running Tor 0.2.25 on a Pi. Consensus weight 37. exit-policy: reject *:* Now Iḿ back from vacation and my relay has 1600 incoming conncts and arm warns me that my bandwidth is too small to support so many incomers. Would I kindly restrict my reject policy or limit my MaxAdvertiseBandwidth. Which I believe is no longer supported(?). Can anyone help me cut down on the traffic and the notices? J. Chase

4 3

can the old compromised keys be invalidated, "named" be recovered
by starlight.2014q2＠binnacle.cx 29 Apr '14

29 Apr '14

I just read that the relay can't get its old name back for six months now that the keys have been changed due to Heartbleed. Does any way exist to invalidate the old keys and transfer the name to the new relay? I realize that naming a relay is strictly an exercise in vanity, but hey, who is entirely immune?

2 1

Compiling tor-0.2.5.3-alpha on Raspberry Pi
by Lance Hathaway 29 Apr '14

29 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Apologies if this would be better addressed in a different list... I know there are a couple of people here who are working on making the Raspberry Pi a good option for running Tor--and the work is appreciated! Gordon Morehouse has built binary pickages for the Pi, but I wanted to try compiling it myself (for good practice, mostly). I followed the directions for compiling from source on a Debian-based system, but the compile fails with the following: config/parse_bridge_line: FAIL ../src/test/test_config.c:373: a.b.c.d was supposed to fail, but it didn't. FAIL ../src/test/test_config.c:374: assert(!bridge_line) [parse_bridge_line FAILED] ...some log lines skipped for brevity... 1/201 TESTS FAILED. (1 skipped) make[1]: *** [test] Error 1 make[1]: Leaving directory `/home/pi/debian-packages/tor-0.2.5.3-alpha/build' dh_auto_test: make -j1 test returned exit code 2 make: *** [build] Error 29 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc failed I confess, I haven't the slightest clue what to do with this. Have I overlooked something stupid? I don't want to open a "bug" unless it's an honest-to-goodness bug (developers have better things to do with their time than chase down "bugs" which are actually "user errors"), but I don't have the knowledge to say whether this is a bug or not... Any thoughts? -Lance -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBCgAGBQJTWW95AAoJEECmBqfoBgXnbVcQALl69M5KuGTfpUH/nsl6hxCu RwB+u5kothwRIPoJblHdEa7m00sWJxUc8HlHfczgjIYkC1gob+vgIDiMR6skAc2t RdSaCYuKWTh6RVTXUAb4UNd3GdvTu/QW/5NsUYDFlTT4QIxg7W2OEOirC4x9bNei gspV+TyOBdJbrTWmVoBFh8YPbpVeY1R5rwARjv7BOhkDCAle3N4vh+S3LvUNr3hk bUimllKSK7fht7bFyesiCrPB1wUxEazAwD7iIDCj6XmVRM57Wu9TV48RO+LLWEB5 qdKuTvN4MyqFbCiuBQXWU5Ps+IEOwoLSVzkQDvtdXhA1WvQmt8gVavXlRlZ+vWIi bEnJFxLMTqcwmC7RRk5blKr73/fBllaEumTpV4TfO3wRDwCKvtKLum9Z6wyV6g8n iY1WoJIThAiN6UM/nohKiecwM/L5e0gwEbkIxYLiCDGwzR3/QAvU84dv4a3EvWcy ptVZgcSQ3B4g55FOlTSJTasBG/rkCIm0Kdi6D7qXAUdm+ylSn/9eMcealSBwk38F Cfm/5P0bMAaKyGugY9VvoMPku8rsQgcimuUY8jH+8WgUxlUcZoL0fYSZ9hiVZ+m4 zW+MiA8Ct2MSzx5GNDDjdBYs7TqOE/MywkSIoxzgy/h0fhAaC3Vm5+NpkI8Z7MUD /1MdDUHCawEZk8KHt7ev =GIPd -----END PGP SIGNATURE-----

3 3

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 connection. As far as I know I've downloaded the correct files for CentOS linux and I have the Vidalia start icon. However nothing happened when I try to open the Vidalia icon. Since I'm not familiar with linux, I don't know where to start looking. I had assumed that I would just open Vidalia and set up my exit relay the same way I did on Windows 8. I greatly appreciate help with this especially from someone who's configured a relay on CentOS. Thanks, Chuck Bevitt

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 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

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 seem to have a perfect read / write balance?? If anyone has any ideas why this is happening or how I could troubleshoot the issue I'd be really grateful! Thanks, Rupert

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. I don't know what impact will this have on the exit node. Is it any problem at all? I have decided also to setup my own DNS resolver and not use the ones from ISP, so I have installed named. What I need help is, for your someone to tell me exactly how do i have to edit named.conf in order to: 1. Enable DNSSEC, for the clients who want to use it. Not make it a requirement, just enable it and prefer it over normal DNS if and when possible. 2. Be able to resolve all TLDs as described here: https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver#DNSResolverSe… Now I can clearly understand the message from that post but there is no instruction anywhere about how to do it, those links for Alt Roots are broken. Is this a requirement? Who needs to resolve silly TLDs not supported by IANA / ICANN anyway? 3. Cache the records for as long as possible - my relay is already using a lot of traffic so I have to spare as much as I can. Please provide me with a good named.conf and description of settings so I can properly configure a good DNS resolver for my relay. Thank you in advance! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBCAAGBQJTWTnUAAoJEIN/pSyBJlsRtN8IAJK8ndrb6IdW+PRpynTu5gzH /6ID3k3uO+EX1jKDSrSMzUlfaOZT0UIVXX/KKxqJSa4YQH4MMGcWfCYXkv+bdFC0 s3ABvAWOeklX5KxUwGWaEJJND+Zu4nstIcVTFpjKpbiFJ7mdzjlDVSCsZFXYBVoV tOY7amgAoQCxNsG0aBKUKeArRSJ03jcicD/92PkL8ro2IB6FItusp5Qywcp12Nhq mXEJdD8l/5jSS1epaaZJ6LzDFyyZsVKsxK8EkBxkYtblkk8WxUnkz4gXrP88cnMC rHb8gqLBvHqjLUn1fKtmJbxJ/J1qEa+2PyoJpzkh4hQxXSZ52TskWKSi0eR7j5E= =675a -----END PGP SIGNATURE-----

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 224.0.0.0/4:* # RFC 1112: multicast reject 240.0.0.0/4:* # RFC 1112: future addressing modes reject 0.0.0.0/8:* # RFC 1122: "This host" source address reject 127.0.0.0/8:* # RFC 1122: Loopback reject 10.0.0.0/8:* # RFC 1918: private use reject 172.16.0.0/12:* # " " " reject 192.168.0.0/16:* # " " " reject 198.18.0.0/15:* # RFC 2544: test environments reject 192.88.99.0/24:* # RFC 3068: 6to4 relay anycast (???) reject 169.254.0.0/16:* # RFC 3927: link-local reject 192.0.2.0/24:* # RFC 5737: documentation reject 198.51.100.0/24:* # " " " reject 203.0.113.0/24:* # " " " reject 100.64.0.0/10:* # RFC 6598: "shared space"/"carrier grade NAT" reject 192.0.0.0/24:* # RFC 6890: future special purposes TIA, zw

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

20 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 18 Apr '14

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

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

14 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