A Layman’s Guide to Heartbleed, David Pitts, April 18, 2014
Originally published on http://www.dpitts.com/2014/04/a-laymans-guide-to-heartbleed.html

The modern world relies on computer security.  Unfortunately, the modern world also takes security for granted.  My goal with this article is to write about the Heartbleed security flaw so that non-technical people can understand what it is, what its impact is, and how to help protect themselves and to be able to have an intelligent discussion about it.  I try to limit the technical jargon, but given it is a technical topic, some will have to be there.  The reader can search the internet for “CVE-2014-0160” or visit http://heartbleed.com/ to get a more technical understanding. 
The Heartbleed security flaw has been all over the news the past couple weeks and rightfully so.  Its official reference is “CVE-2014-0160”, but that’s hard to remember and hard to sensationalize in the news.  The flaw is part of the software that allows and responds to “heartbeat” requests.  So, it gets called the Heartbleed bug as a play on words.  This is (hopefully) the worst security flaw the computing world will see exposed this year.   I say this, not because I know what has yet to be exposed, but because I understand what this one does and can do.   Generally when I think about security I break it down into three major factors – impact, severity, and difficulty.
Impact:  How prevalent is it – in other words, how many systems and services are potentially affected.  Also, how many users are potentially affected. Severity - How much damage can it do – what is capable of giving or exposing and to whom? Difficulty - How difficult is it to exploit – do you need special access or knowledge, etc.  This would also include whether an exploit has been made available “in the wild”.
For Heartbleed, it is the trifecta of security flaws.  It has very high impact, very high severity, and very easy to exploit.
What is it
Heartbleed is the term that has been given for a flaw in some software used to encrypt data.  It is not a virus.  You can’t update your antivirus and be protected.  The software is part of the OpenSSL project.  The particular bug was in the transport layer security protocol.  If you want to know more about the heartbeat protocol, search the internet for RFC6520.
Where is it
It is used for web sites, network equipment, mobile phones, firewalls, etc.  Basically, it could be anywhere where developers have wanted to secure a transmission and have used this library.  The fix, therefore, is for organizations to be responsible and to fix their services.  According to heartbleed.com, about 2/3rds of all servers on the internet use software that uses the OpenSSL library.  Some percentage of those potential servers was actually affected. 
Why is it
It was a human mistake.  One of the nice things about open source is if you have the inclination, you can see who wrote the code, when it was made part of the library and actually look at the code. 
When
It was found by several groups around the same time.  Google reported it on April 1, 2014, Codenomicon (a Finnish cybersecurity company) discovered it on April 3rd.  They are the ones that named it and then put up the heartbleed.com web site to explain it to the public.  In giving these dates, I am presuming that some security agency didn’t find it before then, so they don’t get credit.  The bug was analyzed and verified.  The organizations contacted the OpenSSL group and reported the flaw.  A patch was put in place and released on April 7th and the bug was publicly disclosed the same day.  The code that introduced the bug was written in 2011 and became part of OpenSSL March, 2012.  Rumor has it various entities have been exploiting this bug for months if not years.  One such story was published here:  http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-been-exploited-months-before-patch/. I’m a fairly paranoid person, so I don’t believe that two independent organizations within two days of each other found the same bug.  I would be more willing to believe they were led that direction or that they were working together or that they were tipped off, or some other such story.  I just have a hard time suspending my disbelief for such a coincidence.
What does it do
The heartbeat protocol is a way to keep a communication conversation from timing out.  It ensures that the peer can be reached and is alive.  In computing terms, starting and shutting down a secure communication stream is much more work for the computers than maintaining an open connection.  The basic concept is that almost any time a “heartbeatrequest” can be sent.  The receiver then responds with a “heartbeatresponse”
But, what does it respond with?  Since computers can’t do random, it can’t pull something out if its magic hat, instead it pulls data from memory somewhere near what it is working with.  As a heartbeat response is just supposed to be a single character response, pretty much any single character response will do.  (I am reminded of Sean Connery’s character in The Hunt for Red October requesting “just one ping please” - https://www.youtube.com/watch?v=jr0JaXfKj68.)
If that was the extent, then there wouldn’t be a problem.  The problem is that the way the code was written, the requestor can change the size of the request.  Instead of one character, say an “A”, it can request up to 64K of data. That is 64536 sequential characters from memory.  Technically speaking, the memory that it is reading has been marked to be reused.  However, computers don’t clear out the old data, it just over writes it.  I used to do the same thing with my file folders.  I had a file folder labeled “Windows NT”.  I then took another label and put it on it that said “Red Hat Linux”.  If you lift up the old label you can still read the label underneath.  To put it another way, let’s say you ask me for a playing card.  I’m supposed to give you one playing card.  So, I reach in, and I pull out a playing card and I give it to you.  You then come back and say, “Hey, I want a playing card, give me 10 of them.”  So, I see the request for a playing card, and I give you 10 of them (or sixty-four-thousand of them).  
Another aspect of this bug that makes it even more insidious is that in by far the majority of the cases, the exploit is not logged.  The device being affected would have to monitor both the incoming and outgoing traffic and notice that a single byte was requested but more than one byte was delivered.  The request isn’t going to a normal service (such as the web server itself), so that service is not logging it.  When you hear it said that there is no indication that it has been exploited.  The statement is true.  However, the statement means nothing.  I don’t know Latin, but I’m sure there is some Latin phrase that means “listener beware because the speaker is spouting doo-doo”, maybe something like “Qui audit, dicentis implebitur fimo” if http://translate.google.com is to be believed.
As a consumer, what should I do?
This is the tough part.  The real answer depends on many factors.  I used to say that there is no such thing as security.  The only way to make a computer secure, is to unplug it, put it in concrete, once the concrete sets, dig a deep hole, put it in the hole, bury it, and then forget where you buried it.  However, I am not convinced that this is secure either.
The question is really about what is secure enough?  The data you have on a social media account (Facebook, Twitter, Google+, Youtube, Pinterest, etc.) is supposed to be fairly public.  The data you have at your bank or the doctor’s office is supposed to be fairly private.  Now, treat it that way.
The media is telling you to change your passwords.  This is a good idea.  However, if the service is still vulnerable, then changing your password doesn’t help much, does it?  So, you want to make sure that the service you are using and care is secure is not vulnerable – at least as best you can.
Unfortunately there are a couple problems here.
First, at least in the United States, there have been laws on the books since the mid 1980’s trying to define what is legal and what is not.  I’m not a lawyer and I don’t play one on the internet.  There are people trying to figure this stuff out (http://www.fas.org/sgp/crs/misc/RS20830.pdf for example), but it seems to be a slippery slope.  If you test the service, you may or may not be violating laws.
Second, the current set of tools is only partially accurate.  Many organizations have released heartbleed checkers that you can run against websites, add as extensions to browsers, etc.  While I do not endorse any of them, the list includes http://filippo.io/Heartbleed/, https://lastpass.com/heartbleed/, https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafdggilajhpic.  What the industry is finding is that various tools are looking for something specific that may or may not be accurate. 
In the US we live in a world where we feel we have very little control.  The rich, the law breakers, the “man”, or whoever, makes the rules and all we can do is try to cope as best we can within the constraints we are given.  Public awareness is probably the greatest tool. 
When former President Ronald Reagan said “Trust but Verify” (https://www.youtube.com/watch?v=As6y5eI01XE) he was referring to the treaty between the US and Russia over nuclear arms.  This concept is a good one and one that should be followed here.  Is the organization transparent in its treatment of security in general?  They should be.  Is the organization transparent in its treatment of this and other bugs?  They should be.  As a consumer, your job is to ask, and expect an answer.  Ask publicly, and expect a public answer.  There are several lists out there that will tell you some of the sites that were affected by the heartbleed bug.  One such site is Mashable (http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/).  As mentioned earlier, this bug, in almost all cases, does not get logged.  When they do tell you that “Currently, we have no indication that any of customers’ information was compromised“as one email I received on April 13th stated, then you know they are telling you the truth.  It doesn’t mean anything, but it is the truth.
In an article on americanbanker.com (http://www.americanbanker.com/issues/179_75/heartbleed-bug-lurks-beyond-websites-1066969-1.html?zkPrintable=1&nopagination=1) on April 17th, JD Sherry is quoted to say, “We don’t know the breadth or depth of this yet.”  I know JD. He is right.  We don’t.  As a consumer, our job is to make sure that our providers are being responsible.  JD said in the article that it may take “weeks and months to get people’s arms around this, and quite frankly some people are never going to get to the patch all their systems, which is a scary thing.”  Again, JD is correct, it is scary.
Hopefully the lesson from this is that we need better transparency from our service providers.  We need a more mature security model, particularly for those services that contain protected data, private information, health information, and personally identifiable information that the consumer wants kept private.  This also means that we, as consumers, need to be better informed.  Hopefully, this article has helped with that.
[Image]Mr. Pitts is a seasoned technology executive with over 30 years technology and operations experience including 10+ years senior technical executive management and 16+ years total management,.  Mr. Pitts has experience planning, developing, and implementing large distributed environments, public and private cloud computing platforms, utilizing resources, and managing projects and staff in such areas as E-Government, Internet, manufacturing, healthcare, and higher education. He is adept at crisis management, trouble shooting, problem solving, and systems architecture.  He is a trained educator, published author and an experienced public speaker.