With so many people talking about heartbleed and offering their insights (e.g. excellent posts from Bruce Schneier and Dan Kaminsky) I could not help but add my own. That is not entirely true. I was happy to let others field questions and then reporters contacted me and wanted insights. After I sent my response they said my answers were helpful, so I thought I might as well re-post here.

So this is what I recently sent a reporter:

What is Heartbleed?

Heartbleed is a very small change made to small part of code that is widely used to protect data. You might even say it is a flaw found in the infrastructure that we all rely upon for privacy. It is not an understatement to say it impacts just about everyone who has a password on the Internet. It’s basically like discovering all your conversations for the past two years that you thought were private actually could have been heard by someone without any effort. This is very dangerous and why it had to be fixed immediately. Potential for harm can be huge when trusted systems have been operating with a flaw. It is hard to quantify who really has been impacted, however, because the damage is a leak rather than an outage. We could look for evidence of leaks now, because people trying to take advantage of the leak will leave particular tracks behind, but it is very unlikely tracks will have been preserved for such a long time, since the code change was made. The change unfortunately was not recognized as dangerous until very recently.

How is it related to encryption and the websites I use?

The simple explanation is that encryption was used on websites (as well as many other sites, including email) to protect data. Encryption can prevent someone from seeing your private information. A change in code, known as OpenSSL, used for encryption actually undermined its ability to protect your data. Heartbleed means someone from a remote location can see data that was believed and intended to be private. Your password, for example, would have been seen by someone who knew of this OpenSSL flaw.

If possible, how can I protect myself now that it’s happened?

You can protect yourself going forward with two simple steps. First verify the sites you use have fixed the heartbleed flaw. Often they will push a notice saying they have addressed the problem, or they will post a notice that is easy to find on their site, or you can consult a list of sites that have been tested. Second, change your passwords.

Another way to protect yourself is to get involved in the debate. You could study the political science behind important decisions, such as when and how to trust changes, or the economics of human behavior. You also could study the technical details of the code to join the debate on how best to improve the quality that everyone may rely upon for their most trusted communication.

The reach of this story is amazing to me. It is like information security just became real for every person in every home. I sat on a bench in an airport the other day and listened to everyone around me give their (horribly incorrect) versions of heartbleed. Some thought it was a virus. Some thought it was related to Windows XP. But whatever they said, it was clear they suddenly cared a lot about whether and how they can trust technology.

I was probably too bullish on the traces/trail part of my answer. It is hard to stay high level while still figuring out some of the details underneath. I haven’t yet built a good high-level explanation for why the attack is not detectable by the system itself but that attack traffic has some obvious characteristics that can be captured by the system.

Anyway, this clearly boils down to code review. It is a problem as old as code itself. A luminary in the infosec space recently yelled the following on this topic:

THIS IS CALLED A BOUNDS CHECK. I SAW CODING ERRORS LIKE THIS IN THE 70’S

We know there are people very motivated to pore over every memcpy in an OpenSSL codebase, for example, to look for flaws. Some say the NSA would have found it and used it, but in reality the threat-scape is far larger and the NSA officially has denied awareness.

We also know that finding a really bad bounds check does not necessarily mean any obligation to report it in a “fair” way that minimizes harm, which is a harsh reality that begs the question of human behavior. Before looking to deeply at the technical aspects of the problem, consider Bruce’s perspective:

This may be a massive computer vulnerability, but all of the interesting aspects of it are human.

If you are Bruce, of course you would say that. He finds human aspects interesting, with all due respect, because it is the less familiar angle to him — the focus of his new research. However, most people are unfamiliar with technology, let alone encryption and keys, so the human aspects are the less interesting angle and they want the technical problem explained. XKCD sees this latter demand. That’s why we now have the following beautiful explanation of technical aspects:

With that in mind I still actually agree with Bruce. The industry really needs to dig deep into the following sequence of events related to trusted infrastructure change controls and bug discovery. This is what I’ve gathered so far. We may learn more and revise this in the future, but I hope it helps illustrate the sort of interesting human aspects to sort out:

1. OpenSSL code that created heartbleed is committed an hour before midnight on New Years Eve 2011
2. Codenomicon in early 2014 started tested an alpha piece of their Defensics fuzz product called Safeguard — their automated tool in April finds a flaw in the authentication layer of OpenSSL messaging
3. Flaw is privately communicated by Codenomicon to CERT in Finland
4. Someone at Google finds the same flaw and notifies OpenSSL
5. OpenSSL issues a patch and flaw goes public, leaving many scrambling to respond on an immediate basis

One other thought. I alluded to this in my answer to the journalist but I want to make a finer point here. Some are calling this a maximum level danger event. That perspective begs whether data being destroyed, changed or denied could ever been seen as more dangerous. To a cryptography community the 11 out of 10 event may be different to the availability community. That actually seems to be one of the reasons I have seen management allow encryption to fail — availability risks were seen as more dangerous than confidentiality risks when unfortunately there was a trade-off.

Updated to add: Google staff have started to actively dispute claims anyone found the bug earlier than their company did. Microsoft and Facebook offered money to the Google person who proved the bug to them first, but the money was redirected to a charity rather than accepted.

A timeline favoring Google’s interpretation of events, with the vague discovery listed as “March 21 or before,” has been published by a paper in Sydney. Note the author request:

If you have further information or corrections – especially information about what occurred prior to March 21 at Google – please email the author…

This makes it sound like Google needs help to recall events prior to March 21, or doesn’t want to open up. Codenomicon claims were that it had been testing months prior to discovery. In any case, everything seems to initiate around September 2013, probably not by coincidence and begging the question of human issues more than technical ones.