[tor-relays] Bridge Operators - Heartbleed, Heartwarming, and Increased Help
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#instructions [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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge Operators - Heartbleed, Heartwarming, and Increased Help
Hi, Thanks for the mail, even though I wasn't notified personally (yes, my bridge has a contact email). I can say that after the issue with OpenSSL occurred, I immediately installed the update provided by my distro, stopped Tor and removed all key and let it generate new ones. My bridge is an obfuscated one. Do I have to do anything else? I mean, since obfsproxy isn't linking to OpenSSL as it's written in Python, it should be safe, no? Or maybe Python itself links to OpenSSL but since I updated OpenSSL and restarted everything that was using its libs, I should be safe? Thanks On Wed, Apr 23, 2014 at 8:32 AM, Matthew Finkel matthew.fin...@gmail.com wrote: 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#instructions [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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Yours truly ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Grouping cloud relays running within same provider
On 22/04/14 20:42, grarpamp wrote: On Fri, Apr 18, 2014 at 4:21 PM, Paul Syverson paul.syver...@nrl.navy.mil wrote: Of those 15,000 paths, 163 (or ≈ 1.1%) contained an entry and exit node that resided in the same AS despite having an IP address from different /16 subnets. Out of those 163 paths, all but one also had a distinct /8 network address. There are two questions new operators ask: - What provider allows Tor [exit] nodes so that I can place my new node there? (This is a very common question and leads directly to duplication.) - Where are there no relays right now so that I can try putting one there? (This question is so rarely asked that I cannot recall seeing it.) Even though 1.1% is small it (AS/cidr) does not cover some relevant crossfields such as legal jurisdiction, I still think a project to research current relays would be useful (cidr block, AS, [upstream] hosting provider, physical/govt location, relay operator and location, funding source, etc). Then new operators could query an xor report of fields with - input their prospective new relay - get a top ten list of where we are already too heavy, do not host there - use our data to suggest new placements, ie: we have no relays in these countries, in these AS by size, etc... It would make some sense to have onionooo plugin to carry this extended db, particular since hoster and some other fields would require human researched/maintained input. Coming late to this discussion, so I may be missing some context. First of all, did people following this thread see Compass? https://compass.torproject.org/ Note that we have a GSoC student this year, Christian, who's going to integrate Compass functionality into Globe. I'm sure he wouldn't mind input on that. https://globe.torproject.org/ Regarding the extended db that is mentioned above, if there's yet another data source that Onionoo should include, let's talk about that. I wouldn't want to be the human that does the research or maintain input, as you say. But if somebody else does that and if it's useful data, I can write the glue code to integrate those the new data into Onionoo. For reference, here's the relevant part of Onionoo's protocol specification: https://onionoo.torproject.org/#details All the best, Karsten ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge Operators - Heartbleed, Heartwarming, and Increased Help
Hi Matt Enjoy running a bridge ,anyway I uninstalled my old bridge bundle and tor then got the latest release and installed it. Hey could anyone there please e-mail my authenticated password for Tor ,mail I tried the one I wrote down but it keeps kicking me out anyway my e-mail is kattam...@sbcglobal.net and I am running win 7 pro on my computer that also runs my bridge. Would really appreciate it! Sincerely John P. Katakowski. From: Matthew Finkel matthew.fin...@gmail.com To: tor-relays@lists.torproject.org Sent: Wednesday, April 23, 2014 2:32 AM Subject: [tor-relays] Bridge Operators - Heartbleed, Heartwarming, and Increased Help 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#instructions [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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit node rejection of special IPv4 blocks
On Wed, Apr 23, 2014 at 6:26 PM, Roger Dingledine a...@mit.edu wrote: On Wed, Apr 23, 2014 at 03:12:36PM -0400, Zack Weinberg wrote: 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 Best practice is to only block addresses and destinations that you know you don't want to reach. When you block addresses where somebody tells you there should be nothing there, you're narrowing out the future. If the RFC changes tomorrow and you don't notice, suddenly you're blocking connections to a piece of Africa or whoever gets that IP space. Yes, a lot of BGP people did/do that, blocking not just the thou shalt not route stuff, but also just plain unallocated stuff, leading to partial blackouts and weird routing for ages after allocation till everyone updated their silly filters. Search bogons. And if indeed nobody is using it, why block it? Everything is pretty well collated and described here... https://www.iana.org/numbers 6to4 appears global. Multicast won't work over Tor. Yet that huge swath of space would seem ripe for better management/assignment someday. Nanog would have that thread. For shalt not... it probably doesn't matter if you block the whole non-global special purpose lot. A couple reasons should be obvious: - To protect yourself and nearby lan/wan systems from remote access via selective use of you as the exit towards those addresses. Obvious example is rfc1918 to gratuitously reconfigure your modem/router for you. - To stop building and wasting circuits for users who dump/leak packets with those destinations into Tor, such packet dests would not be forwarded/accepted by your ISP's routers anyways. It would not be difficult for some relays to run a report on what is seen trying to exit them. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
