Atomicorp

Most updated distros with OpenSSL are affected. Updates for CentOS 6 have been released today (do not forget to restart software using SSL, such as your web and mailserver). It is unknown wether this attack has been used in the wild, you might want to create new private keys and get a re-issue for your certificates.

AFAIK ASL has not protected against this vulnerability, but perhaps I am wrong?

More info http://heartbleed.com

EL 6 update: https://rhn.redhat.com/errata/RHSA-2014-0376.html

If you want to be on the safe side (you can't detect if attacks have been taken place) it is recommended to re-issue your SSL certificates with new private keys and revoke the previous certificates. If you have exchanged important passwords or other sensitive data via SSL this data could also be compromised.

Would ASL be implementing virtual patching against this vulnerability?

Thank you for the question. In this case, this isnt something you can virtually patch. You'd need a time machine to patch this.


The reason is that the vulnerability leaks your keys. Its a memory leak, so if you've been attacked your keys may already be compromised and since openssl cant detect this, you wont know if it happened either. So you should assume the worst. The fix is to rekey your EL6 servers - and update openssl (so it wont leak your new key). We cant patch your keys being leaked, if its been lifted the bad guys already have it.

So, the fix is:

1) upgrade openssl on el6 (el5 is not effected by this bug)

yum -y upgrade openssl

2) Generate a new private key for your server(s), and if you work with a CA send a CSR to them and get a new signed cert for your box

This is going to vary from control panel to control panel, but if you work with a CA they should good docs to do this.

3) Restart all SSL based services

Note: This does not effect SSH. SSH does not use the TLS protocol.

You can read more about this bug in openssl at this URL below:

http://heartbleed.com/

And you can test your sites from this URL:

http://filippo.io/Heartbleed/

With that said, if you had configured apache to use Perfect Forward Secrecy (PFS) that would have helped to mitigate the impact of this vulnerability. https://www.atomicorp.com/forums/viewto ... f=8&t=7140

As far as I can tell, unless you are a big player, the bad guys obtaining your SSL certificate's private key is an insignificant issue in most cases since they would have to be able to sniff your traffic in some way in order to exploit it once it has been obtained.

The real problem is that other data may also have been leaked through this vulnerability, for example a Plesk password, email credentials etc.

So while re-keying an SSL certificate is a good thing to do, what's potentially more important is to change your Plesk admin password. More realistically in terms of what might leak, people will be logging in to collect or send email very frequently, so from where I'm sitting I think it more likely that an information leak would include some email credentials. Of course changing all customer credentials is a pain in the behind.

In addition, we can expect to see the botnets tasked to probe for vulnerable servers, which will result in higher apache slot use and potentially making a web server unavailable if they use too many at once (same as email).

The services I think probably need restarting for a Plesk box are:
psa (for 10.x and 11.x use "service sw-cp-server restart" and NOT "service psa restart" !!!)
tortixd
courier-imap (or courier-imapd for 11.5) (see post from prupert further down)
qmail? Not sure about that one.
possibly xinetd too?

Best practice would be to reboot the server after updating the package to make sure everything that might use it is restarted.

Corrections to my assumptions are, as ever, welcome.

Mike:

We've also seen that some sites suggest revoking the old certs in addition to generating the new certs.

I'd assume the need to revoke isn't as much of an issue for self-signed certs, correct?

We just upgraded our servers to EL6 last week and now this. Thankfully a quick yum update and rekey and we're good again but quite the scare from this.

Ironic that EL5 is not exposed to this problem.

I'd assume the need to revoke isn't as much of an issue for self-signed certs, correct?

That depends if you use OCSP to check to see if its revoked, but if its self-signed you will still want to replace the private key after you have upgraded.

Ironic that EL5 is not exposed to this problem.

EL5 uses an older version of openssl that doesnt support the heartbeat extension to the protocol. Only the newer versions have this bug.

With that said, EL5s openssl has its own limitations, for example it doesnt support Perfect Forward Secrecy (PFS) which makes it vulnerable to other types of cryptographic attacks as well as. You can read more about PFS here:

https://en.wikipedia.org/wiki/Forward_secrecy

While not as a immediately bad as the heartbleed vulnerability, the lack of PFS support in older versions of openssl makes it only a matter of time before something is found that it cant cope with. Defense in Depth.

And on that note, if you dont have PFS enabled for your TLS/SSL based services do it. PFS may help to mitigate the effects of a leaked key caused by this bug in openssl, plus it helps protect you from other scenarios. In general, PFS is a "Good Thing" to enable.

Heres an ssl.conf config that can set that up for you in Apache:

SSLProtocol -ALL +TLSv1
SSLHonorCipherOrder On
SSLCipherSuite EECDH+AES:EDH+AES:-SHA1:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5:!RC4

(Remember to remove any existing settings of the above in your apache configs, if you have dupes, this wont work)

And heres one for nginx, the first is very paranoid, the second supports older browsers or ones that dont support PFS:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED;


ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-RC4-SHA:ECDHE-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DES-CBC3-SHA;

And this one is the most flexible:

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

(Same warning for nginx, if you redefine these somewhere else in your config, this wont work)

To use PFS you must have openssl-1.0.1e and higher.

If you do not have PFS enabled, and you are using a vulnerable version of openssl, you server is in the most vulnerable condition. PFS helps to mitigate this, without PFS: like crane kick, no can defend.

@Mike: I thought PFS only fully worked with Apache httpd 2.4. EL 6 has Apache httpd 2.2.

Can you explain why your recommendation here differs from the one that is set by ASL?

Your recommendation: ASL sets: @Faris: Remember to restart courier-imaps and courier-pop3s as well on a Plesk 11.5 box.

@Mike: I thought PFS only fully worked with Apache httpd 2.4. EL 6 has Apache httpd 2.2.

PFS works with 2.2 if you use that configuration. It forces othe PFS ciphers first, so the browsers that support it can use it (well most of them anyway, this is the best you can do with 2.2).

Can you explain why your recommendation here differs from the one that is set by ASL?

Backwards compatibility. PFS doesnt work with all browsers, and that config will force PFS ciphers to the front, meaning that some older browsers will not work at all with that servers SSL/TLS configuration but its mostly old stuff. But since we dont want ASL to break anything, especially with hosting companies, ASL wont configure the system that way.

mikeshinn wrote:

@Mike: I thought PFS only fully worked with Apache httpd 2.4. EL 6 has Apache httpd 2.2.

PFS works with 2.2 if you use that configuration. It forces othe PFS ciphers first, so the browsers that support it can use it (well most of them anyway, this is the best you can do with 2.2).

Can you explain why your recommendation here differs from the one that is set by ASL?

Backwards compatibility. PFS doesnt work with all browsers, and that config will force PFS ciphers to the front, meaning that some older browsers will not work at all with that servers SSL/TLS configuration but its mostly old stuff. But since we dont want ASL to break anything, especially with hosting companies, ASL wont configure the system that way.

According to https://www.ssllabs.com/ssltest/index.html your configuration does indeed break compatibility with some older browsers (all on Windows XP, some older Android and Java; nothing too worry about too much), but still does not force PFS for every client. It gets the same grade as the ASL configuration, an "A-" because it doesn't force PFS for all major browsers.

Thanks Prupert -- I had indeed missed those on 11.5. Thanks for correction.

your configuration does indeed break compatibility with some older browsers (all on Windows XP, some older Android and Java; nothing too worry about too much)

Yep. The ones it doesnt work with are probably OK for most users, but because some sites might want those, we wouldnt want to force this configuration on anyone.

but still does not force PFS for every client.

That configuration forces PFS for browsers that (1) support PFS and (2) if they support the ciphers that apache 2.2 supports that require PFS. If they dont, it will fall back to some very specific non-PFS ciphers when those two conditions are not true, but not all ciphers or protocols and because some of those ciphers are all those older browsers support, and they are BadCiphers(TM) they are disable - and those browsers dont work. This is the best you can do with apache 2.2. If you force PFS for everything, you'll lose a whole bunch of browsers that just dont support with the ciphers apache 2.2 supports.

Try the defaults and see what you get with apache 2.2, no PFS at all.

It gets the same grade as the ASL configuration, an "A-" because it doesn't force PFS for all major browsers.

Well of course, its a good config by default, we are paranoid security guys we wouldnt stick you with a bad config.

It just doesnt force PFS, and ssl labs doesnt currently penalize for failure to support PFS heavily right now (because too many browsers in use dont support it, or dont support it very well). But if you want something more flexible that still supports PFS, change the SSLCipherSuite line to this:

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

If you want to drop RC4 (I would recommend you do), then use this one:

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK

The following script is a quick way to regenerate the tortixd ssl certificates if you have not already:

http://www.atomicorp.com/installers/ssl-cert-regen.sh

and restart tortixd with:

service tortixd restart

For those running cPanel WHM 11.42 (release), just restart the mail and apache services and you should be good to go.

Test your servers here: http://filippo.io/Heartbleed/

Update: This is only true if you allow nightly updates to pull down from cPanel