Heartbleed Q&A

Q: What is the Heartbleed Bug?
A: When using the heartbeat function with SSL, a message is sent by the client or the server and repeated back to the sender. You can ask to repeat back more characters than were submitted, and when using the vulnerable version of OpenSSL, it will then append other data from memory. This data could include the server private key, user’s passwords or other sensitive information.

Q: Why is it called the Heartbleed Bug?
A: The Heartbleed name is making fun of the heartbeat function name.

Q: How long has the Heartbleed Bug been out?
A: The Heartbeat bug was included with OpenSSL 1.0.1 which was released in March 2012.

Q: Is this an SSL/TLS specification or protocol issue?
A: No, the standards that define the SSL/TLS protocol are not the cause of this issue. This was an implementation error when developing OpenSSL.

Q: Is this a certification authority or SSL/TLS certificate issue?
A: No, there were no errors performed by the CAs to create the Heartbleed bug. The SSL certificates also did not create the bug.

Q: Will the certification authorities have to change their root certificates and private keys?
A: No, the private keys for root certificates are protected in HSMs and are not exposed to external servers using OpenSSL.

Q: Do certificate subscribers need to pay for certificate revocations?
A: This would depend on the subscriber agreement with the CA. No members of the CA Security Council are charging for certificate revocations related to Heartbleed.

Q: Were there ways to mitigate the Heartbleed bug?
A: Perfect forward secrecy, multi-factor authentication, end-to-end encryption, and hardening are ways to mitigate the Heartbleed bug.

Q: Which of my servers are at risk?
A: All servers and clients which use OpenSSL 1.0.1 to 1.0.1f and 1.0.2 beta. Apache and Nginx are two of the most popular web servers that often use OpenSSL, although they can use alternatives like GnuTLS.

Q: Are the certificates on my affected servers at risk?
A: If your server was running with a vulnerable version of OpenSSL, the certificates on your affected servers need to be replaced as the server key pair may have been compromised.

Q: Why are my certificates at risk?
A: The certificates contain a public key which supports the server’s private key. The server private key is used to encrypt the SSL session keys during an SSL session. Heartbleed may have been used to compromise the server’s private key, so that all SSL sessions may be decrypted. As such a new private and public key need to be generated and the SSL certificate needs to be replaced with a new one containing a new public key.

Q: If I used the same certificate on more than one server, do I need to replace both of them? Even if one server does not use OpenSSL?
A: Yes and yes. Once the certificate is revoked, it cannot be used on any server.

Q: What version of OpenSSL is vulnerable (contains the Heartbleed Bug)?
A: OpenSSL 1.0.1 to 1.0.1f and 1.0.2 beta.

Q: Why is patching my OpenSSL servers not enough to fix the problem?
A: Patching the OpenSSL servers will stop the problem from reoccurring, but then actions need to be taken to mitigate potential compromises of sensitive data. As such the server private/public keys must be replaced, the certificate needs to be reissued with a new one containing a new public key, and users’ passwords should be changed.

Q: How does it affect my business?
A: The main risk to your business is the possibility that your customers’ passwords and other sensitive data could have been stolen from any vulnerable server. If passwords are in use on any server that was vulnerable, we recommend that you notify your customers and force a password reset the next time they visit your site. Since many users share passwords between a number of sites, you should remind your customers that they should consider changing an affected password wherever it was used.

Q: What is the difference between rekey and reissuing a certificate and revoking a certificate?
A: Rekey means that the server must generate a new private and public key pair. Reissue means that the SSL certificate is reissued with the new public key. Revoke means the old SSL certificate authorization is revoked as the old private key has been compromised.

Q: Why must I rekey, reissue and revoke my certificates?
A: You must rekey in order to generate a new private key to replace an old private key that may have been compromised. (In other words, if you had saved the CSR you used to obtain your current certificate, you must not reuse that CSR to obtain a new certificate.) You must reissue your certificate with a new public key that will support the new private key. You must revoke your old SSL certificate so that it cannot be used to attack your users.

Q: What must I do if I am vulnerable?
A: Inform, fix, rekey, reissue, revoke and re-inform. Inform your users that your site may be vulnerable. Fix the OpenSSL problem by installing OpenSSL 1.0.1g or recompiling OpenSSL with the heartbeat function removed. Rekey your server with a new private and public key pair. Reissue and install your SSL certificate using your new public key. Revoke your old SSL certificate. Inform your users that the problem has been fixed and that they should change their passwords.

Q: Do I need to notify my clients/customers that my site has been secured and they should reset their passwords?
A: Yes, the clients/customers which use your site need to know whether the site has been vulnerable and if it has been fixed. When the site is fixed, the customers should be advised to reset their passwords.

Q: When should my clients/customers change their passwords?
A: Customers should change their passwords after you have fixed the OpenSSL problem and have replaced the SSL certificate.

Q: Which passwords should my clients/customers change?
A: Any passwords they use over the Internet to authenticate to your service.

Q: How do I know if I am currently vulnerable?
A: Check whether the version of OpenSSL is 1.0.1 to 1.0.1f and if the heartbeat function is enabled. This check can be supported by tools which have been developed to test for Heartbleed, or by using the CA Security Council SSL Configuration Checker

Q: As a user of the Internet, should I be concerned about providing sensitive information to a server that hasn’t been patched?
A: Yes, the sensitive information could be your username and password, which would allow an attacker to post information or steal your identity. You may also submit sensitive or private information which could be revealed to an attacker.