Building The Net

Heartbleed – What is it? (for non geeks)

The Heartbleed bug was caused by a programming error in a software package called OpenSSL. This error had the potential of allowing bad people to attach to secure web and email servers, as well as services that rely on the TLS/SSL protocol, and steal the private encryption key off the servers. The TLS/SSL protocol is what puts the pretty little lock in the address bar in your browser. The private key is what the owners of the sites you go to are suppose to keep secret, and not share with anyone because if someone has it, they can decrypt the encrypted data traveling between your system and the server. THIS IS BAD…

Heartbleed – What is it? (for geeks)

The Heartbleed bug was caused by a programming error in the OpenSSL library that deals with TLS handshakes. A couple years back, a new RFC (rfc 6520) proposed a new extension to the TLS protocol that would allow a heartbeat to be exchanged between the client and server to reduce the number of re-negotiations during a TLS session. This all sounds good, and actually is a very beneficial to the protocol in general, but when it was implemented in OpenSSL, an error in the way the code was written allowed a request to grab a bunch of data without checking the boundaries of the data itself. This could allow someone to make a request crafted in a certain way that would cause OpenSSL to return 64k of protected memory data possibly containing the SSL private key of the server.

Oh My God! Really!

Yes, really… But don’t get your nickers in a bunch just yet. For most everyone, this is not as bad as it might sound. Even if a bad guy knew about the exploit, they would need to get into the network stream between you and the site you were attached to. This would mean that they would need to:

• Have gotten the private key for the site and service you were attaching to.
• Have figured out a way to get in the data path between you and the site.
• Managed to capture enough of your conversation to reconstruct the data needed to exploit it.

Now, these things are all possible, and if you do a lot of banking and purchasing on public networks then you probably should be a bit concerned about this, but for the most part, you are probably OK.

What you should do to protect yourself.

Even though most people are probably not going to be effected by this, there are some things you should consider doing to protect yourself.

• Change your passwords.
• Keep an eye on your bank accounts and credit card activity
• Don’t do things involving financial transactions and private communications on public networks.

And yes, I know that the 3rd one won’t help if you have already been compromised, and I also know that many of you travel all the time and need to use public networks just to get on line, but it’s still good practice if you can get away from those coffee shop wireless connections for transaction stuff.

So, I’m OK then?

Well, yes and no. Although this was only made public on April 7, 2014, it has existed in the code for well over a year. So there is the possibility that a group or groups could have gotten private keys from from your bank or credit card company. This week, all of us around here have been working around the clock upgrading systems and replacing key sets on all of our servers as well as our customers servers. This is a lot of work! And it takes time. Sadly, there appears to be no way to ascertain if a private key was ever compromised because from the servers view, it’s just another request. So the cleanup continues. If you are on you home network and it is secure, then I wouldn’t be too concerned, but as far as public networks, for now, I might take a few days off from financial transactions till us tech types get this sorted out.

— Stu