I’m sure everyone has read, or heard, something about the Open SSL bug that was discovered a couple weeks ago, called “Heartbleed.” I wanted to take a little time and explain exactly what it is, what it means, why it matters, and what you should do about it. You might be sick of hearing about it by now, but there has been a massive amount of incorrect information posted in many different places. Most news agencies don’t understand the technology well enough to explain it, and many tech blogs are either incomplete or stating assumptions as fact. I wanted to take some time to research this more completely before writing anything, to make sure I can do an in depth look and explain it in a way that people will understand, and know what to do about it. It’s a long read, but I think it’s important to understand this problem, understand what the real world risk is, and how to mitigate any potential threat because of this.
To understand the bug, I have to explain a little bit about internet protocols in general. The internet transmits data in tiny little segments called “packets.” To truly understand what these packets are, it would take longer than you will want to read, but I’ll give you a basic description of a packet. Basically, when your computer is sending or receiving information across the internet (or even on local networks), it breaks it up into tiny segments, called ‘packets,’ and sends them that way. Part of the packet says what kind of information is coming, part of it has the address of where it’s going, and part of it is how long the packet is going to live. That last part is the important one. The reason it’s important for packets to have a “time to live,” is because the internet is kind of messy. When you’re communicating with Google, Facebook, or any other website, your computer is sending packets all over the place. Some of them do not get routed correctly, and could end up somewhere completely different from where they are going. This is completely normal, but there needs to be a way for these packets to expire; or the entire internet would get clogged with these packets that are just sitting in the wrong place not knowing what to do.
To back up a little bit more and understand this bug in particular, I should explain that there are two main protocols used with these packets. There are more kinds, but for the majority of the internet these are the only two that you need to worry about. The protocols are called TCP and UDP. They each serve different purposes, and it’s all in the background so you never really see what is going on. There is a lot of detail that you can go into about both kinds of protocols, but there’s only one part that is important regarding this bug. TCP requires a two way communication between the sender and the receiver of the information. You can think of it like your computer says, “Hey Facebook, this is me,” and then Facebook has to respond back and say, “Hi me, I’m Facebook.” Built into the TCP protocol is the ability to tell if all of your packets reach their destination. There’s basically an inventory of everything that you will be sending, and what order they should be in, and the other side verifies that information. If one gets dropped or misplaced on the way, it will ask your computer to send that small segment again. If they arrive in the wrong order, it will be able to rearrange them so that they are in the right order. Much of the internet runs on this, because it’s important that your information be received completely, verified, and doesn’t get corrupted on the way. TCP also has security measures built in, because it was designed much later than UDP. TCP has this, “Time to Live,” built right into it.
UDP is only a one way communication. That’s not to say that you can’t have UDP packets going both ways, but they don’t REQUIRE a specific response. They also don’t have any way of telling if things are arriving in the correct order, if a packet got dropped or anything like that. You may be thinking, “well why don’t we just use TCP for everything on the internet instead?” Well, UDP is still very useful for a lot of types of communication involving the internet. A good example is VOIP phone systems, or phones that work over your internet connection. TCP has to verify everything so much that it would cause a huge delay on a phone call, resulting in terrible quality issues. UDP is much faster and it probably doesn’t matter if a packet drops here or there, because you wouldn’t hear that small amount of data being lost. There are other parts of the internet where UDP is used because of it’s speed.
UDP started as a fairly insecure protocol, for some functions that didn’t matter. Since it is so much faster and lightweight than TCP, researchers have been working on adding security layers, and other features, to UDP to take advantage of the speed, as well as add more security to it so that it can be used for more things. This is where the Open SSL project comes in. About two years ago, an addition was added to Open SSL that basically allowed the addition of a version of “time to live” to a UDP packet that is using SSL.
SSL is a little complicated to explain, but it’s basically a way of securing a connection on a network, including across the internet. It essentially allows you and the server you are connecting to, to share a secret key with each other. That key authenticates who you are, who they are, and once that trust has been established, it encrypts the data so that no one can spy on your information. That’s a ridiculously simple explanation of a complex problem. If you want to understand it a little better, watch this video http://bit.ly/1h7TlJ6. This video explains encryption, and shared vs. private keys really well. That is basically what SSL is doing. Open SSL is a version that was created by a ton of people over the years, all contributing to the overall product in different ways, and tweaking it along the way. It is a hugely popular way of encrypting data on the internet, partially because it is free, and since it is a community project. And honestly until now, it hasn’t had any major problems.
So, where is this going? Well the “Time to live” protocol that was instituted in Open SSL is called a “heartbeat.” And this is the part that was found to have a weakness in it.
So what happened, and what does this mean?
There’s a fairly long timeline with this bug, and many of the details have been released after the information was released to the public. Let me first explain what exactly is happening.
Essentially, during the process of establishing a secure connection with a server, a security researcher at Google figured out that there wasn’t a size limit on how big the section of the packet that includes the heartbeat could be. So he tried making one that was way too big to be a normal heartbeat. He discovered that when you did that, the server didn’t know how to handle the extra piece of information, and spit back 64 KB of information to the person who sent the oversized packet. 64 KB doesn’t sound like a lot of information, but it depends on WHAT the information it spits back contains.
This is kind of the part where some news/blog stories started inserting their opinions on how dangerous it is, rather than stating the facts. Here’s what happens: when someone sends that overloaded packet and receive the 64 KB back from the server, it’s completely random noise from the server. It could be from any part of the memory on the server, and will almost always be useless noise. Seems like an odd flaw, but not that dangerous. What they found, though, is if they keep doing this over an extended amount of time, depending on the server, SOMETIMES they would get something interesting back. This could be a username and password stored on the server, or far more importantly it could be the servers private key. This is where a lot of the confusion comes in to play. It’s almost impossible to get the user name and password out of these servers. You may get one or two here and there, but it would be completely random, and out of the hundreds of thousands of users on some of these servers (or millions on Facebook, Google, etc.) that is basically useless. If they steal the servers private key, however, that could be disastrous.
Here is where the panic started setting in, and why certain sites were claiming this was the worst exploitable flaw the internet has ever seen. Almost 70% of the ENTIRE internet uses open SSL as their security method, which means a HUGE number of sites could potentially be vulnerable to this attack. This is misleading, however.
Only 17% of that 70% actually use this extension of SSL, the heartbeat, while the remaining amount don’t have that extension enabled, making this bug not a threat to them. Still a big deal? Absolutely. 70% of the internet at risk? Absolutely not.
So why is it so scary that someone could steal a private key (stored in something called a certificate) from a site like Google, or Facebook, or even your bank? Well, if they have that private key, then they can impersonate that site, and you would have NO way of telling if it was the real site or not. Your web browser is constantly checking these private keys in the background to make sure that sites you go to are really who they say they are. The list is updated in the background by whoever makes the browser, so you never even see this happening. If someone gains the ability to impersonate the other site perfectly, then there is no way for you, or your computer, to tell if it’s really on wellsfargo.com, or if it’s a fake site that looks exactly the same. You put in your username and password, and boom, they have your info.
This could have been disastrous, but all indications are that it was mitigated very quickly. There was a fix out almost immediately, and all of these websites fixed it on their back end within a day or two. So why were every one of these sites emailing you to tell you to change your password? Well, technically if you logged in during the time after this bug was discovered, and before they fixed it, it’s possible that someone may have snagged your login information. Likely? Not really, but certainly possible. But now that these sites have fixed their end of things, changing your password guarantees security, so why not change it just to be sure?
This is a very brief overview of what the problem is, how it could be used, and why you should change your passwords on important websites. This absolutely could have been the worst internet disaster in the history of the internet, but it was mitigated very quickly. The main lesson from all of this is that much of the internet was designed pretty poorly for how we use it today, and we need to take that problem seriously.
Should you change your passwords? I think so. We don’t know the full impact of this bug yet. It appears to not be as big of a deal as it could have been, but the threatening part is that there is no way of being able to tell how much it has been exploited. We also don’t know if hackers were aware of this bug before the general public. Just change your password on the websites you have any information you care about, and you’ll be fine. It doesn’t have to be a major change, because this is not a brute force attack, so having a similar password is good enough. Make one letter a capital, or add a number, and that’s good enough.
Lastly, Apple’s services do not use Open SSL. Your Apple ID is safe. Your Mac and iPhone are safe. You still should change your passwords on the internet, but your computer or iDevice are safe. Android is unfortunately vulnerable to this, and there isn’t a great way to fix that. Currently Google does not have a fix for it, but we’ll see what they say in the next few weeks.
If you want a more detailed explanation on heartbleed, check outhttp://heartbleed.com/
If you want to take a look at the timeline of what has happened with this bug, check out this site http://bit.ly/1gycgxt
And for those of you who understand this bug and want a good laugh (and actually decent explanation) check out http://xkcd.com/1354/