If you haven't heard of the Heartbleed Bug, it's something to take a look at immediately. It essentially means that an attacker can exploit a vulnerability in many versions of OpenSSL to be able to gain access to a server's private key. It is not a theoretical threat, it is a demonstrable and reproducible threat. See the above link for more information.

The question I think most organizations are asking themselves is the following:

Does every company now need to create new public/private keypairs and ask their CA to invalidate the original signed keypairs?


4 Answers 4


It means much more than just new certificates (or rather, new key pairs) for every affected server. It also means:

  • Patching affected systems to OpenSSL 1.0.1g
  • Revocation of the old keypairs that were just superseded
  • Changing all passwords
  • Invalidating all session keys and cookies
  • Evaluating the actual content handled by the vulnerable servers that could have been leaked, and reacting accordingly.
  • Evaluating any other information that could have been revealed, like memory addresses and security measures

Summarized from heartbleed.com (emphasis mine):

What is leaked primary key material and how to recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

What is leaked secondary key material and how to recover?

These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.

What is leaked protected content and how to recover?

This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.

What is leaked collateral and how to recover?

Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.


This is the worst case scenario, as described by Codenomicon who set up the quoted web site.

The "raw" vulnerability description is:

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. (OpenSSL)

I am not saying that they gone too far, it IS very very bad, but:

  • Check your OpenSSL version (not all versions are affected).
  • Even better, test it:

    openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe

  • Or use http://filippo.io/Heartbleed/

Then if you were using Perfect Forward Secrecy (PFS), exchanged data cannot be decrypted, unless a MITM were performed.

To perform a MITM attack, the hacker had to know about the vulnerability and successfully exploited it. An attacker can try to access random pieces of 64ko memory without being noticed, by doing so he should be able to end up getting part of memory where the private key is stored.

To answer the question, if you are vulnerable to the Heartbleed bug. Yes, you have to change your private keys and certificates. And if you want to be on the safe side, either check about 2 years of log files to be sure nobody used Heartbleed on your site or simply and safely perform the already mentioned operations.

  • 19
    "check about 2 years of log files to be sure nobody used heartbleed on your site" - the scary part is, use of heartbleed is not detectable from logs.
    – Xan
    Apr 9, 2014 at 12:31
  • "the hacker had to know about the vulnerability and successfully exploited it" - better to use "attacker" instead of "hacker". Hacker implies a lesser threat, whereas the attackers here are domestic and foreign government agencies, organized crime, unscrupulous companies, or talented/well-funded hackers or script kiddies benefiting from the work of blackhat hackers. Given those attackers, and the inability to detect past attacks, it's prudent to assume vulnerable servers have already been exploited.
    – user44192
    Apr 11, 2014 at 4:23
  • And how exactly can you find heartbleed traces on the logs, @BrnVrn ?? Apr 11, 2014 at 20:39
  • You would need Network logs, meaning the raw packets, not simply web server (HTTP logs or whatever protocols above TLS). If you have the TCP logs, you can see if there are Heartbleed requests and responses.
    – BrnVrn
    May 11, 2015 at 16:30

The issue of using new SSL cert/key for all servers is often overstated. You need to assume

  • There exists a hacker who know the Heartbleed before you fixed the openssl
  • He/she is interested in hacking your servers, not other popular web sites
  • He/she has the ability to extract the private key from 64K server memory, he/she should be a very sophisticated hacker
  • He/she can intercept the local network (user/server) and able to decrypt the traffic

Given all the conditions, then you judge do you need to update the SSL cert/key.

I am not saying you should not, I am just saying sometimes people in the interweb blindly listening to others and saying if you don't do that, your site will be 100% hacked, it is just FUD, IMHO

  • 4
    Someone qualified wrote, "the probability is close to one that every target has had its private keys extracted by multiple intelligence agencies" (schneier.com/blog/archives/2014/04/heartbleed.html), heartbleed foreknowledge not required. MITM not required; though MITM become possible. Unpopular/obscure servers are equally vulnerable because you should assume automated harvesting of every reachable server. Go with the security experts on this, not some low rep pseudonymous guys on an Q&A forum, which includes myself and @Ryan.
    – user44192
    Apr 11, 2014 at 1:59
  • My point is: intelligence agencies know the bug long time ago, it is almost sure that they've capture the user password already. so it cannot be fixed by updating ssl cert only (again, I am not saying it is useless), and if you updated the openssl bug in day 0, I am quite sure that you prevented from most of the random hackers in the internet already. asking people to update cert without forcing user to change password is just a fake sense of security.
    – Ryan
    Apr 11, 2014 at 3:26
  • Your answer is essentially "it depends" or "maybe" with implications that advice to revoke & replace certs is cargo cult and FUD. It does not depend: "Since there's no way to tell whether a server has been exploited...you need to assume that it is..." (blog.cryptographyengineering.com/2014/04/…). Nor is your answer a variation of "revocation is only the first step; force user password changes." Your answer as written is bad advice; corrected it would be a lesser version of @scuzzy-delta's answer.
    – user44192
    Apr 11, 2014 at 4:07

If the person is collecting these 64K pieces of data until they finally capture the private key, they can then decrypt everything they have collected (and collect more). That is how an attacker can grab usernames and passwords without being a MITM. If the person is can get the private key, the rest is pretty easy.

  • the point is when the attacker can get the username/password, you already lose, it cannot be fixed by updating the ssl cert/key. it can only be fixed by asking/forcing user to change the password. if you update openssl, then mitm would not be possible anymore, so the benefit of using a new cert is not as significantly as someone pointed out.
    – Ryan
    Apr 11, 2014 at 3:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .