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#in... [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
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.finkel@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#in... [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
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 kattamann@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.finkel@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#in... [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
Let us know if/when obfsproxy runs on CentOS.
Even better, if/when it is back to being written in C, instead of version-specfic Python. That will increase obfsproxy use more than any heartfelt request.
On 04/23/2014 02:32 AM, Matthew Finkel wrote:
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.
On Thu, 24 Apr 2014 20:00:53 -0400 Steve Snyder swsnyder@snydernet.net wrote:
Let us know if/when obfsproxy runs on CentOS.
It's broken? If someone files a bug explaining what's broken about it, the chances of it working again will rise significantly.
For what it's worth asn and myself have been looking into making sure that it will run with the distribution packaged python (and assorted libraries) shipped with Debian oldstable which is probably similarly ancient (See Bug #11558).
Even better, if/when it is back to being written in C, instead of version-specfic Python. That will increase obfsproxy use more than any heartfelt request.
That's unlikely to happen. The closest thing that exists to a native implementation of the more recent pluggable transports is obfsclient, but it's client only and uses "version-specific C++" that the standard CentOS compiler will choke on.
From my perspective it would be easier to fix obfsproxy to better tolerate dependencies being prehistoric, but again, without a detailed bug report to work off of, that won't happen unless by happy accident.
Regards,
On 04/24/2014 11:16 PM, Yawning Angel wrote:
On Thu, 24 Apr 2014 20:00:53 -0400 Steve Snyder swsnyder@snydernet.net wrote:
Let us know if/when obfsproxy runs on CentOS.
It's broken? If someone files a bug explaining what's broken about it, the chances of it working again will rise significantly.
[snip]
https://lists.torproject.org/pipermail/tor-relays/2013-April/002091.html https://lists.torproject.org/pipermail/tor-relays/2013-April/002108.html
Still true a year later. You can have a obfs3 written in Python, or you can have a working RHEL6/CentOS6 system, but not both.
The obfs3 developers, of course, have every right to support the platforms of their choosing, and they owe nothing to RHEL/CentOS users.
That said, making it painful to use your software on a given platform will dissuade users of that platform from running your software. Who knows, maybe the upcoming RHEL7 will make a perfect platform for the Python-based obfsproxy. Today, though, not so much.
On Fri, 25 Apr 2014 22:43:38 -0400 Steve Snyder swsnyder@snydernet.net wrote:
On 04/24/2014 11:16 PM, Yawning Angel wrote:
On Thu, 24 Apr 2014 20:00:53 -0400 Steve Snyder swsnyder@snydernet.net wrote:
Let us know if/when obfsproxy runs on CentOS.
It's broken? If someone files a bug explaining what's broken about it, the chances of it working again will rise significantly.
[snip]
https://lists.torproject.org/pipermail/tor-relays/2013-April/002091.html https://lists.torproject.org/pipermail/tor-relays/2013-April/002108.html
Still true a year later. You can have a obfs3 written in Python, or you can have a working RHEL6/CentOS6 system, but not both.
[yawning@leningrad ~]$ cat /etc/centos-release CentOS release 6.5 (Final) [yawning@leningrad ~]$ tor -f torrc Apr 25 22:57:14.613 [notice] Tor v0.2.4.21 (git-c78a5e53283f65b9) running on Linux with Libevent 1.4.13-stable and OpenSSL 1.0.1e-fips.
[snip]
Apr 25 22:57:17.000 [notice] Registered server transport 'obfs3' at '0.0.0.0:33225' Apr 25 22:57:17.000 [notice] Registered server transport 'scramblesuit' at '0.0.0.0:42788'
https://trac.torproject.org/projects/tor/ticket/11610#comment:1
I'll look into adding backward compatibility code for the version of pycrypto CentOS packages so it's possible to setup one of these without pulling in all the development tools next (Git is temporary till the next obfsproxy release, since the #11558 changes are needed). Follow the bug for future progress.
Regards,
On Sat, 26 Apr 2014 06:05:27 +0000 Yawning Angel yawning@schwanenlied.me wrote:
[snip]
I'll look into adding backward compatibility code for the version of pycrypto CentOS packages so it's possible to setup one of these without pulling in all the development tools next (Git is temporary till the next obfsproxy release, since the #11558 changes are needed). Follow the bug for future progress.
Ok, I just closed the bug[0] as "invalid", with no planned further action on my part with regards to this.
Summary of current state of obfsproxy on CentOS 6:
It works with the vendor provided packages (Including python 2.6), as long as you install a more recent version of pycrypto.
The vendor provided pycrypto (python-crypto-2.0.1-22) is not usable because it is missing `Crypto.Util.Counter` *and* more importantly, the CTR-AES implementation only handles plaintexts/ciphertexts that are sized as a multiple of the AES block size.
Any version of pycrypto that has a fully working CTR-AES implementation will also provide `Crypto.Util.Counter`, so there is no need to implement the latter in obfsproxy as a compatibility hack.
Till the next release of obfsproxy, people that wish to use this will need to grab obfsproxy from the git repository to get a fix for #11558.
How one will properly update pycrypto is left as an exercise to someone that actually uses CentOS.
Let us know if/when obfsproxy runs on CentOS.
Why would anyone want to use CentOS? Obviously this is a rhetorical question since there isn't a good reason to use CentOS instead of say Debian... AND if someone gave me access to thousands of CentOS servers for the purpose of running tor relays I would immediately want to change their distro to Debian.
Even better, if/when it is back to being written in C, instead of version-specfic Python. That will increase obfsproxy use more than any heartfelt request.
um yeah sure... it may even perform faster... but there are other considerations in choosing a language to development in. Is C considered a secure language? Is it easy to write "secure" code in C? No... it's not. Also development time is generally longer.
Right now there are lots of pluggable transports being written for the obfsproxy python api; here are some of them: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports
We need a low development time for writing PTs... because all the current PTs in theory could get blocked by fascist censorship regimes.... and then we'll have to write new PTs or modify existing PTs.
On 04/23/2014 02:32 AM, Matthew Finkel wrote:
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.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 2014-04-25 12:09 , David Stainton wrote:
Let us know if/when obfsproxy runs on CentOS.
Why would anyone want to use CentOS? Obviously this is a rhetorical question since there isn't a good reason to use CentOS instead of say Debian... AND if someone gave me access to thousands of CentOS servers for the purpose of running tor relays I would immediately want to change their distro to Debian.
Or easier: make a chroot with in that a Debian install.
Then you can run all Debian stuff easily, without having to bother with CentOS/RHEL/Fedora/etc...
Just make sure that you disable most services and/or keep these upgraded.
For a public relay you will want to do that anyway, as these hosts will be scanned by external "friendly" people.
Greets, Jeroen
Jeroen,
How can the unnecessary services be disabled? One Debian VPS is the source of SQL injection attacks and I have no idea how that happened.
Robert
for the purpose of running tor relays I would immediately want to change their distro to Debian.
Or easier: make a chroot with in that a Debian install.
Then you can run all Debian stuff easily, without having to bother with CentOS/RHEL/Fedora/etc...
Just make sure that you disable most services and/or keep these upgraded.
For a public relay you will want to do that anyway, as these hosts will be scanned by external "friendly" people.
Greets, Jeroen
tor-relays@lists.torproject.org
-
David Stainton -
Grozdan -
I -
Jeroen Massar -
John Katakowski -
Matthew Finkel -
Steve Snyder -
Yawning Angel