The first logical step to mitigating the Heartbleed vulnerability is to patch OpenSSL. If your software is using OpenSSL 1.0.1 – 1.0.1f, you have two options:
- Upgrade to OpenSSL 1.0.1g, which was released on April 7, 2014
- Compile OpenSSL with the -DOPENSSL_NO_HEARTBEATS flag
If your third-party software that you use is vulnerable, you will need to contact the vendor to obtain a fix.
On the server side, it is possible to set up IDS/IPS rules to detect attempts to exploit this issue. For example, see http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/. However, I would not recommend this approach. If you can’t deploy a fix to your vulnerable server right away, I would highly recommend taking it offline until you deploy the fix.
From the client side, do not try to connect to servers or networks that you don’t trust until you have a fix. That is common security advice, but it is especially relevant given that the Heartbleed vulnerability is easily exploitable and publicly known. Remember that this vulnerability can be exploited before the SSL handshake is completed (i.e., before any authentication has taken place). So attackers on untrusted networks can cause your client to connect to arbitrary hosts so that they can extract data from your client’s memory.
Change private keys
As I mentioned above, compromise of private TLS keys is unlikely. However, just to be on the safe side, generate new key pairs (after deploying a non-vulnerable version of OpenSSL of course) and get new certificates from your certificate authority. Ensure that the certificate authority revokes your old certificates. Now, the unfortunate part is that revocation doesn’t work very well in practice. Most browsers for example probably will not perform certificate revocation checks anyway (see http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html). So, if somebody has stolen your private key, they may be able to continue using it until your old certificate expires. There is little we can do about this.
As for what you should do regarding other information that may have already been compromised (e.g. your users’ credentials, session identifiers, etc.), there is no easy answer. If you have good application-layer monitoring controls in place, keep an eye out for unusual behavior – whatever that may be for your application. Keep in mind that the stolen information could be used in social engineering attacks against your customer service representatives. So make sure that they’re aware of what attackers could attempt over the next few days/weeks/months.