CVE-2014-0160 - Heartbleed

Jul 2, 2020

CVE-2014-0160 - Heartbleed

Late Monday, April 7th, 2014, a bug was disclosed in OpenSSL's implementation of the TLS heartbeat extension. The bug's official designation is CVE-2014-0160, it has also been dubbed Heartbleed in reference to the heartbeat extension it affects. The Heartbleed vulnerability is something OpenSSL users should take very seriously as it enables an adversary to obtain data from portions of the web server memory.

While the Heartbleed bug isn't a flaw with certificates, passwords, or even the TLS protocol itself, the exploitation of the bug can lead to compromised private keys and other sensitive data. The Heartbleed bug is present in OpenSSL versions 1.0.1 through 1.0.1f as well as 1.0.2 beta. By extension, server software such as Apache, Tomcat, Nginx, utilizing vulnerable versions of OpenSSL are also at risk.

How do I know if I'm vulnerable?

If you are running an earlier version of OpenSSL or other software that does not use OpenSSL, your server is not affected by the Heartbleed bug.

You can use our SSL Configuration Checker to test your server for Heartbleed vulnerability.

Note: Although your server may not be vulnerable, there is a high probability you connect to sites that were directly affected. Because of this, it is strongly recommended that you change your passwords for any sites and services you use, once they are patched for Heartbleed.


My Server is Vulnerable, What do I do next?

1. Download Patches / Update OpenSSL

If you're running a standalone version of OpenSSL, update to the latest version 1.0.1g that has been patched for the Heartbleed vulnerability.

You'll want to install any product specific patches & updates for this vulnerability. This may include updates to your GNU/Linux distribution, or updates for hardware appliances.

Once you have updated your OpenSSL libraries and applied any patches to your platform / appliance you can move on to reissuing your certificate.

If you are using a hosting service, check with your provider to make sure they have patched their own systems before continuing.


2.  Generate New Keys, Reissue, and Install Your Certificate:

The next step is to reissue your certificate with a new private key since the original one may have been compromised.

1. Generate a new private key*
2. Generate a new CSR*
3. Reissue your certificate using the new CSR.
4. Install the new certificate.
5. Verify the new certificate is functioning properly.

Detailed instructions for reissuing your certificate can be found in our related article:
https://support.globalsign.com/customer/portal/articles/1223116

Be sure to choose the correct intermediate certificate for your product type and hashing algorithm.


3.  Revoke the Original Certificate:
Reissuing will generate a uniqe order ID; once your certificate has been successfully reissued, installed, and tested, you can revoke the original certificate order. Note, you only want to revoke after you have successfully reissued your certificate as you cannot reissue a revoked certificate.

Detailed instructions for revoking your certificate can be found in our related article:
https://support.globalsign.com/customer/portal/articles/1251577.


Security Advisories and Patches:

GNU/Linux Distributions:

• Red Hat
• CentOS
• Fedora
• Ubuntu
• Debian
• Arch

Serverside Software:

• Apache CloudStack
• Apache CouchDB
• F5
• mongoDB
• NGINX
• Parallels Products
• XAMPP

Hardware:

• Cisco Products