How to use the Internet while Heartbleed is being fixed?

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

I would also visit the following site:

https://www.ivpn.net/blog/heartbleed-passwords-change

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

Answer 7

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.