There are many websites who are not currently vulnerable, but I have no idea if they were vulnerable a few days ago.

For example:

  • twitter.com: Not vulnerable right now, but the certificate is from Wed Mar 05 00:00:00 UTC 2014
  • google.com: Not vulnerable right now, but the certificate is from Wed Mar 12 09:53:40 UTC 2014
  • bankofamerica.com: Not vulnerable right now, but the certificate is from Thu Dec 05 00:00:00 UTC 2013

What do I do? Not use these until they reissue? How do I know that they reissue the certificate with fresh keys? It seems I shouldn't even log in to these sites to change my password because there's no way of knowing that they're the real website.


7 Answers 7


Updates 2014-04-11

Cloudflare set up a challenge to verify that private key extraction was in fact possible. It has been done with around 100 thousand requests, and it verifies the fears. It's no longer theoretical, but proven. You can go here to read about it.

Also, Bloomberg has reported that the NSA have known about this exploit for at least two years. This makes sense as the NSA has the resources to hire analysts whose sole job is to find exploits in software such as this. Now that we know that the US government has been exploiting it for so long the probability that other states have known and exploited it is significant.

TL;DR Watch for announcements from organizations regarding the status of their systems, change ALL of your passwords, and watch for fraud/suspicious activity on important accounts such as banking or other financial systems.

To understand why the situation is so dangerous we first have to understand what this attack actually does. CVE-2014-0160, AKA Heartbleed, is a buffer overread bug that allows an attacker to get up to 64 kB of memory from a server running a vulnerable version of OpenSSL.

That sounds really bad. How does it work in practice

You're right, it's a serious flaw, but we'll get back to that a little later. Right now let's talk about why the exploit works. Transport Layer Security (TLS) is used to secure information by many applications including HTTP (HTTPS) or to secure SMTP if enabled for example. In RFC 5246, which set the standards for TLS, there is a function known as a heartbeat. The client and server send some data back and forth to keep the connection alive so that it can be used later. Now in practice the client will send some data and the server will just send it back, and everything is great. However in the affected OpenSSL versions there is no check to see if the client actually sent the amount of data that it said it did. So if I send it 1 byte and tell the server that I actually sent it 64 kB then it is going to happily send me back 64 kB. Where do those other bytes come from? That's the key to the problem right there. OpenSSL is going to send you back 64 kB - 1 bytes of memory that the process has access to and that you originally didn't send, depending on where your 1 byte is stored. These extra bytes from memory are the problem as they can contain valuable information such as private key material¹ and information that the server is decrypting to use. Examples of this would be: passwords, credit card information, and/or PINs.

OK. What does that mean for information security? If you understand how asymmetric cryptography works then you already know that this is serious as disclosure renders the encryption no more than obfuscation. This means that even though the servers might be patched and are no longer leaking memory, sessions still may be insecure. It is possible that this was exploited before it was publicly known or while patching was taking place, but there is currently no method proven to show that an attack took place. It is possible that rules for IDSs may become available, but as of now that is not the case. IDS rules have been released. That of itself is extremely dangerous, because the operators do not know whether their keys are still secure.

We are forced to assume that the keys have been leaked, meaning that it is possible that everything you send across the wire can be decrypted by a third party. The only way to mitigate this is by regenerating keys and getting new certificates reissued while having the old ones revoked. Unfortunately, this takes time as the CAs are no doubt being flooded with these requests right now. Still this leaves the possibility for a man-in-the-middle attack, or other phishing opportunities.

When will it be safe? Knowing when it will be safe is a tough question. Some things I would suggest watching for are public announcements explaining that the bug has been patched in their environments or that they were never vulnerable, because they never used the affected versions. When they have announced that they had upgraded to a new version of the OpenSSL I would ensure that they are using a new certificate signed after the date of public release of the exploit which was 2014-04-07.

**Note that previously recorded traffic may be decrypted if the private key was later leaked.

What can I do as a user to protect myself

For the next few days if you can avoid using critical sites such as online banking or online medical chart access I would suggest you to do so. If you must do so understand that your session is potentially at risk and be prepared to accept the consequences of that. Also, after organizations announce that they are no longer vulnerable you should change your password; using a password manager can help. You should also get ready to change or monitor any other information that you used such as bank details or credit card numbers.

Special notice to activists

Anything that uses OpenSSL may be affected, including Tor. It is possible that governments have been able to use this flaw since its inclusion in OpenSSL releases from over two years ago as they would have the vast resources required to look for exploits such as this, and as such you should be prepared that the information could no longer be private.

**Note that previously recorded traffic may be decrypted if the private key was later leaked unless perfect forward security (PFS) was implemented.

¹- There have been claims that it is likely that private keys wouldn't be in memory, but at the same time there have been claims of successful key extraction. At this point it is uncertain which side is correct.

  • 45
    This is by far the most informative piece of text that I read about this new hot-crazy-critical Heartbleed attack (all other articles/blog/news posts contained just bits and pieces of information). Nice job :) . Commented Apr 9, 2014 at 15:12
  • 4
    How can we know that new certificates are generated using a new key?
    – user148324
    Commented Apr 9, 2014 at 17:10
  • 3
    Note that previously recorded traffic may be decrypted if the private key was later leaked. Not if the server was using a cipher with forward secrecy.
    – Wes
    Commented Apr 9, 2014 at 22:59
  • 2
    @Wes You are correct that PFS would most likely have kept the traffic secure. I was trying to walk a fine line of explaining the situation without confusing people. Unfortunately PFS was not widely deployed.
    – Jacob
    Commented Apr 9, 2014 at 23:02
  • 6
    To sum up what is heartbleed bug xkcd.com/1354
    – GoodSp33d
    Commented Apr 14, 2014 at 14:59

The risk posed by this vulnerability is being overhyped. I say this because there is ZERO evidence that this vulnerability was known or exploited prior to its publication by researchers 2 days ago.

Let me be clear, it is urgent that vulnerable web sites, particularly those transacting sensitive data across the Internet, be patched. It is equally urgent that signatures for the attack be loaded into IDS and malware protection tools. Inside IT, we should respond to this vulnerability with the highest priority.

Having said that, I do not feel that the level of risk associated with this vulnerability by the public press is justified.

What should individuals do to protect themselves? Don't use sites that are running vulnerable versions of OpenSSL.

Until and unless there is evidence that this vulnerability was exploited, any further action is pointless and motivated by nothing more than FUD. You disagree? Consider the many vulnerabilities released each month or quarter that allow arbitrary code execution. Those that give the attacker root or system level privileges or where the attacker can subsequently gain them through privilege escalation present as much or more risk to the security of all data handled by the vulnerable systems as this vulnerability presents.

In many cases, these vulnerabilities are discovered by the software vendor or researchers who inform the vendor. The vendor produces a patch and releases it to the market without publication of the vulnerability details. In some cases, the details are published and exploits are published by the security community for use in testing tools. We don't react to these many vulnerabilities by saying "All our secrets MAY have been exposed!"

If there is evidence of exploitation, we must react to that appropriately. I see great risk in the overreaction of the researchers who announced this vulnerability and in the press who have amplified the researchers' loose talk. They are crying wolf.

-- El viejo

  • 9
    This answer should be up voted more IMO. There are plenty of vulnerabilities published every month that would allow people to steal servers' private keys, and not a lot of fuss is made about them. This one is more serious than average because of the ubiquity of OpenSSL, but it is still being over-hyped.
    – al45tair
    Commented Apr 10, 2014 at 10:40
  • 2
    "Until and unless there is evidence that this vulnerability was exploited" "If there is evidence of exploitation, we must react to that appropriately." You talk a lot about evidence of exploitation. Yet one of the scary things about the Heartbleed bug is that successful exploitation is undetectable after the fact (unless you're storing the incoming heartbeat message in full every time in perpetuity, and even then it's not guaranteed that successful exploitation led to a breach of security). How do you propose we establish after the fact evidence of successful exploitation of the bug?
    – user
    Commented Apr 10, 2014 at 11:22
  • 6
    -1 because this author does not really understand the nature of attacks I don't think. For one, attackers who had this sort of access would work very hard to keep it secret and to not allow evidence of their intrusion to come out. A bug of this sort that cuts into the security of about half of secure traffic on the internet is not crying wolf at all. It is a very serious matter I think. Commented Apr 10, 2014 at 20:14
  • 19
    I hold Bruce Schneier in the highest regard, when it comes to IT security. To quote his blog post about the Heartbleed vulnerability: "Catastrophic" is the right word. On the scale of 1 to 10, this is an 11. That alone is enough for me to strongly disagree with your downplay of the issue.
    – abstrask
    Commented Apr 10, 2014 at 21:24
  • 8
    This post should be downgraded. The problem IS NOT being ovehyped, it is a catastrophic failure of OpenSSL, besides which even if it was not used until publicly announced, bad players have definately compromised sites with it subsequently. It is also highly likely the NSA knew about it (but this can't be proven). There are convincing theories pointing to this being a deliberate compromise although the author denies it.
    – davidgo
    Commented Apr 11, 2014 at 8:37

Not every website uses OpenSSL libraries for HTTPS (there's also GnuTLS and PolarSSL for example), and not every version of OpenSSL was vulnerable (older versions were not). This means there's a fair chance the websites you mentioned didn't change certificates because they did not need to. Just looking at the dates certificates were issued doesn't tell you enough.

There are a number of tools and sites which can help you check if a website is vulnerable, for example: - http://filippo.io/Heartbleed - https://gist.github.com/mitsuhiko/10130454 - https://www.ssllabs.com/ssltest/

Unfortunately, as you already stated, this does not tell you if they were. I'm afraid the key issue here is trust: there's no way objective way to verify which SSL libraries they use and used without inside information. You have to hope they did what they need to do (because it's the right thing, or even because they fear public humiliation) and if they did you can only hope they are open about it.

Of course, you could always ask these websites if they were affected, I've seen a number of websites issuing public statements about this. Asking publicly using social media like Twitter or Facebook often works.

So the best advice I can give is a piece of general advice: be careful what you leave behind on the internet and which websites you trust with your personal information.

  • 3
    waits for the inevitable PolarSSL bug to appear (it is next in the list...)
    – strugee
    Commented Apr 9, 2014 at 6:56

Regarding the private keys being exposed, it is worth adding that, while someone may be able to decrypt data in an encrypted session, because they now have the private key, they will still need to establish themselves as the man in the middle of the session. Not just anyone on the Internet can do this.

My understanding is that they will still need to be intercepting traffic either by being on your local LAN and ARP spoofing or being able hijack/redirect traffic by advertising false routes to Internet routers. These kind of attacks have always been possible even without this vulnerability.

  • 2
    Not necessarily true with Heartbleed. The bug exists because the (whats supposed to be encrypted) data can be exposed by accessing the RAM. Therefore, they don't need to intercept/sniff traffic to exploit this vulnerability. However, there would need to be some malicious software installed on either the server or client and also it would need proper access to access the RAM. Commented Apr 10, 2014 at 16:13
  • Not so. It could be compromised by a Man-In-The-Middle attack as well. Further the memory dump does not only affect that session, it is possible (depending on the contents of the memory block) to see unencrypted usernames and passwords of other users, in addition to private keys to facilite decoding all traffic [via MITM attack]
    – davidgo
    Commented Apr 11, 2014 at 8:39
  • I guess i should have been a little clearer that i was mainly referring to the use of the compromised keys after the server is patched.
    – PeterJ
    Commented Apr 16, 2014 at 4:19

You can enter the URL for a site at LastPass Heartbleed Checker and it will tell you whether the site was or is still vulnerable, and when its certificate was updated.

There's also a Chrome extension called Chromebleed that will warn you if you're visiting a site that's affected by Heartbleed.

Mashable.com has a list of well known sites, whether they were affected, and whether you should change your password. Interestingly, none of the sites in the Banks and Brokerages list were impacted.


I would also visit the following site:


They have a list of popular sites that have been impacted and when and where you should change your passwordss


Overall, I would say don't let the paranoia get to you. Realistically just being able to have decrypted the traffic and obtained your password is not the same as having actually done it.

If you use two-factor authentication (and you should) on sites such as Twitter, Facebook, Gmail, and your banking then you shouldn't be too overly worried, and even if you don't you're probably OK as is.

If you feel the need to change all your passwords, you're going to have to go ahead and do it where you feel you need it. That's all there is to it, really.

  • 1
    two-factor authentication won't stop a malicious party from do anything that is possible surrounding this exploit. I am not sure the reason you bring it up. Gaining access to your social accounts isn't really the concern of somebody who might take advantage of this exploit in OpenSSL anyways.
    – Ramhound
    Commented Apr 12, 2014 at 8:30
  • 1
    @ramhound I mentioned in the comments before the comments got removed, two factor helps because once a site has a new cert issued any passwords an attacker may have had are no longer useful. Because there's no point changing a password until after a new cert is issued (and servers patched) what you gain is instant re-securing of the account from possible credential leakage that may have occurred while the attacker had the private key. Also, twitter and Facebook are important as they can be used as single sign on for many other websites (including this one I believe?)
    – Sirex
    Commented Apr 12, 2014 at 14:53
  • The password is still helpful because people use the same password, yes, even people who use 2-factor authentication. As long as the attacker is able basically dump the session data they can perform a MiTM attack against you.
    – Ramhound
    Commented Apr 12, 2014 at 15:45
  • Yeah, but reusing passwords is a separate fail really. My point was two factor helps mitigate the severity and longevity of the aftermath, but yes it won't help with actual bug being exploited.
    – Sirex
    Commented Apr 12, 2014 at 19:01
  • @Sirex As far as I can tell no site that I log into using two-factor auth has invalidated the cookies on my machine. This is of course a failure on their part, but my point is, at the moment two-factor auth is not a savior. An attacker could quite easily intercept the cookies and use them on their own requests. Furthermore, since there is no way to know whether anyone exploited this bug (even for the system administrators) the ONLY safe assumption is that it was exploited. I know for instance that chase.com was still vulnerable as of Wednesday morning. Unlikely the attackers missed that one.
    – CrazyCasta
    Commented Apr 14, 2014 at 2:31

You must log in to answer this question.