TurnKey 13 critical security issue (Heartbleed / CVE-2014-0160)

Systems which run on static ip's (rather than DHCP) do not get system updates at install time - first boot.  It would be great if Networking could be defined before updates are called as it often happens that having installed a new system, then a static ip, Apt-Get updatemay not be configured to auto-run.

Perhaps system updates are automatic but it seems that if not called at first boot these are not always automatic.

Thank you for the notice on this.  In terms of "issuing new keys" what would be the best proceedure?  Any risk of losing control of ones system in the process?

I'm certainly no expert when it comes to security, but from some of the articles on Heartbleed I gathered that SSH keys are also at risk because they are stored in memory on the server.  After all the updates are in place, I plan to regenerate all new keys for users and hosts.  I know that most of my virtual hosts are probably safe because they weren't exposed to the Internet but it's as hard to figure out which ones have exposure as it is to change them all.

Does the OpenSSL system also effect the key generation for Name Based SSL Certs or is this just for the self generated Certs that run by default on WebShell, Webmin and Apache without further configuration of SSL?

2) Individually restart any service (e.g., webserver, shellinabox, webmin, etc.) that uses the OpenSSL library:

OK... I'll bite. How do I determine which services utilize OpenSSL?

My submission is triggering the spam filter... ugh!

Drew

Wunderlist, which I don't actually use just sent me the following in email:

How we fixed the Heartbleed bug

As you opened up Wunderlist today, you would have noticed that you had been logged out. We did this to protect your data against an internet-wide security vulnerability called ‘Heartbleed’. Heartbleed affects the OpenSSL framework which is used by many websites to privately send data to and from an internet server.   For you, this now means you’ll have to simply log back intoWunderlist. We also strongly recommend that you reset your password for Wunderlist.

Reset Password

We want you to know, that we’ve made Wunderlist’s Sync Service completely safe from Heartbleed, and this is how we’ve kept your data safe and sound: As soon as we were made aware of Heartbleed, we protected your data by preemptively turning off our Sync Service, eliminating any potential security breaches by stopping all communication to our servers. We deployed the updated OpenSSL libraries. We then renewed all of our SSL certificates. We logged out all users to ensure that everyone would create new, secure connections.

Want to know more? If you have any questions or want to learn more, please take a read of our in-depth article at the Wunderlist Support Center. Also, one of our engineers, Duncan Davidson, has written a personal account of what happened in more technical detail.

With all the attention that HeartBleed has brought to security, now might be a good time to think about implementing Forward Secrecy, sometimes referred to as 'Perfect' Forward Secrecy or PFS in all TurnKey appliances that use OpenSSL.  Forward Secrecy protects against the future compromise of your private keys revealing the contents of prior communications.  Forward Secrecy is already implemented in OpenSSL but is usually not configured.

After applying the HeartBleed updates and generating a new set of self-signed certs, I looked into implementing PFS.  I'm currently running nginx configured as a reverse-caching-proxy and setup to handle all SSL requests for my backend apache servers.  The configuration allows me to handle multiple domains while having a single external IP address.

"Enabling forward secrecy can be done in two steps:

1. Configure your server to actively select the most desirable suite from the list offered by SSL clients.
2. Put ECDHE and DHE suites to the top of your list. (The order is important; because ECDHE suites are faster, you want to use them whenever clients supports them.)"

I followed the configuration advice for nginx from Qualys Security Labs (links below).  I did have to modify their example slightly to get nginx to accept it (doesn't like '\').  My nginx config now looks like this:

ssl_params

server_tokens off;
ssl_protocols        SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;
keepalive_timeout    60;
ssl_session_cache    shared:SSL:10m;
ssl_session_timeout  10m;

ssl_prefer_server_ciphers tells the server to choose a matching cipher from the list in the order given. Specifying each cipher explicitly makes sure that the most secure, highest performance ciphers are given highest priority, but the list may need to be updated from time to time.  I chose to include SSLv3 to support older clients even though it does not support Forward Secrecy.

References:

https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-depl...

https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-a...

I just came across an interesting article in the Sydney Morning Herald quoting public statements made by Dr Robin Seggelmann regarding his inadvertent introduction of the 'Heartbleed' bug into OpenSSL. Have a read here.

I find it particularly interesting that whilst he takes responsibility for introducing the bug, he ultimately blames lack of resources for the OpenSSL software as being the main factor... Raises the valid point that if you care about free open source software then people need to put their money and/or their time where their mouths are! :)

Thanks for sharing!