OpenSSL Heartbleed Bug

Bruce Morton

A new threat called the Heartbleed Bug has just been reported by some researchers at Codenomicon and Google. Heartbleed attacks the heartbeat extension (RFC 6520) implemented in OpenSSL. The official reference to the Heartbleed bug is CVE-2014-0160.

Heartbleed allows an attacker to read the memory of a system over the Internet and compromise the private keys, names, passwords and content. An attack is not logged and would not be detectable. The attack can be from client to server or server to client.

Heartbleed is not a flaw with the SSL/TLS protocol specification, nor is it a flaw with the certificate authority (CA) or certificate management system. Heartbleed is an implementation bug.

The bug impacts OpenSSL versions 1.0.1 through 1.0.1f. The fix is in OpenSSL version 1.0.1g. The 0.9.8 and 1.0.0 version lines are not impacted. OpenSSL 1.0.1 was introduced in March 2012, so the vulnerability is 2 years old.

The impacted systems are widespread. OpenSSL is used in Apache and NGINX, which Netcraft reports are 66 percent of the market share.

OpenSSL is also used in operating systems such as Debian Wheezy, Ubuntu 12.04.4 LTS, CentOS 6.5, Fedora 18, OpenBSD 5.3 and 5.4, FreeBSD 8.4 and 9.1, NetBSD 5.0.2 and OpenSUSE 12.2.

If you are using an impacted version of OpenSSL, you need to consider the following:

  • Upgrade your system to a software version that uses OpenSSL 1.0.1g or higher. You may have to wait until your software vendor publishes a new release
  • Renew your SSL certificates with a new private key
  • Ask your users to change their passwords
  • As content may have been compromised, you will need to consider whether you need to notify users

Updated April 9, 2014: Qualys SSL Labs has added a Heartbleed test to their SSL Server Test.

Bruce Morton
Bruce Morton
Director, Certificate Technology & Standards

Bruce Morton has worked in the public key infrastructure and digital certificate industry for more than 15 years and has focused on SSL and other publicly trusted certificates since 2005. He has been an active member of the CA/Browser Forum that released guidelines for extended validation (EV) certificates and Baseline Requirements for SSL certificates. Bruce oversees the governance and compliance of Entrust’s publicly trusted PKI.

12 Comments

  1. Bryan Hunter April 9, 2014 Reply

    1 Is there any possibility that your secret keys have been compromised.
    2 Are you advixing the replacement of certificates that have been used on servers having the defective version of OpenSSL?

    • Bruce Morton Author
      Bruce Morton April 9, 2014 Reply

      The private keys to our certification authorities are protected in a FIPS 140-2 Level 3 validated hardware security module (HSM). The private keys never leave the HSM and are not exposed to OpenSSL.

      The server operator does not know whether they already have data which is compromised. The recommended solution is to upgrade a server which has a defective version of OpenSSL. Once the fix is completed, then the server operator should consider replacing the server’s private key and the associated certificate in the event that they were compromised before the fix was implemented.

  2. Marlen Padberg April 10, 2014 Reply

    There’s articles and rumors going on that a majority of SSL certificates issued by public CA’s may need to be re-issued, and that those CA’s will need to be sunset. What is Entrust’s position on this? Will the L1B/L1C intermediate CA’s be sunset and a new intermediate be commissioned, with the need for customers to re-issue new certificates?

    • Bruce Morton Author
      Bruce Morton April 10, 2014 Reply

      The Entrust certification authority private keys are protected in a certified HSM. The private keys are not exposed to any software outside of the HSM, and of course are not exposed to any server using OpenSSL. The Entrust intermediate CAs do not need to be sunset. Customers should look at their own environments and see if they are using a vulnerable version of OpenSSL and renew their SSL certificates if required.

  3. Greg Stigers April 10, 2014 Reply

    http://www.entrust.net/ssl-technical/renew_faq.cfm isn’t clear about revocation and reissue under these circumstances. What is Entrust’s position on charging customers for revocation and reissue due to heartbleed?

    • Bruce Morton Author
      Bruce Morton April 10, 2014 Reply

      Entrust does not charge for certificate revocation. Under normal conditions, Entrust reissues most certificates for free. In the case of the Heartbleed bug, Entrust will reissue all vulnerable certificates for free.

Add to the Conversation