Our Heart Breaks From Heartbleed

a couple of years before we knew about it. Oops. Yeah, we're talking about heart bleed, which if any of you, I'm assuming a lot of our listeners keep up with tech news in general, and normally on tech stuff, we don't cover things that are of the immediate uh past, because often we record ahead of time and it's over. We we often, in fact kind of kind of almost avoid very breaking news so that we have a chance

to discuss more in depth exactly what has happened. However, this is such a huge story and it's one that is a little difficult for someone to to understand if they don't really have a working knowledge of of what actually is going on behind the scenes, that we thought it was important to address this and actually talk about what you guys can do in order to protect yourselves as best as possible. It's not all gonna be a happy story, folks. This is actually a pretty serious problem.

In fact, pretty serious is an incredible understatement. Um So, really, what it gets down to is this is a story all about encryption. So encryption pretty simple. I mean you've probably heard the term. It's not not too simple. I mean, the concept is simple. Execution is somewhat more complicated. But the concept is that you are you are changing something so that the content is not easily readable from anyone else unless they have the key to decrypt that information. Right.

And this is really important for many different web related purposes because you know, any any time that you don't want everyone on the internet who chooses to to read your emails or get your get into your bank account or etcetera, etcetera. Yeah, you want to you want to

make sure that stuff is encrypted. So you know, you probably have heard that when you log into sites that are going to have a lot of access to to secure what should be secure information like things like your bank account or just shopping history or your medical information

that's a great example. Then you know that you want to look for that HTTPS which tells you it's a secure or it's supposed to be a secure connection right, or that little padlock that will show up in your in your web browser right exactly, and that tells you, hey, uh, there's a there's a handshake that's going on between your browser and that website that indicates the connection is secure and encrypted, and that anyone looking in from the outside

should just see gibberish. And furthermore that the website that you're that you're on is what it says it is, that it's not an imposter for possibly nefarious purposes exactly because there's an attack called the man in the middle attack, which is where you have a hacker insert him or herself in the middle of communication between you and whatever service you actually want to use, and that way they are able to access all the information you're sending and

you think you're sending it to the service, but you're really sending it to the hacker. This security is supposed to allow you to make you know, to be sure that it's going exactly where it needs to go and that no one is snooping on you. So it turns out that the most popular online encryption software used on the web today had a fundamental flaw and its security in several recent builds of that software that have been in use for the past two years or so. Yeah,

and that is heart bleed. So, first of all, the software we're talking about is called open s s L. This is an open source version of SSL. Yeah, it stands for Secure Sockets Layer. Now it's it's a protocol, so it's a set of rules that tell UH sites how to encrypt information. And there are lots of different ways you can implement this. SSL is just that's kind of like the the the the specific category, but then you can implement it in different ways. Open SSL is

one of those ways. Yeah, I would say proprietary, but since it's open source, that might be kind of the wrong word. So it's a specific version exactly exactly. So you know, it's all about securing your transmissions across the

Internet so that they remain opaque to anyone else. They're not gonna be able to see them, and UH in general, to communicating parties are given encryption keys which allow each party to encrypt and decrypt messages so that they can send it back and forth and only in theory the other party can see what's going on, and only for the length of this particular communication session, right, because once that session ends, then the session keys that's what you're

using to encrypt and decrypt are magically dissolve. So there's actually two different types of encryption keys we're talking about here. There's one that's called an asymmetrical key, and that's sort of a long term key that's like the the overall rules that guide the any individual session. The session key is dependent upon lots of stuff. It's dependent upon the client. That's the that would be you using your computer to access whatever it is you want to access. Let's, for

the argument's sake, say it's your email. So your client, your your computer is the client. You send out a request to log into your email. The email exists on a server. That's that's the server on the client server side, and so the the session keys are going to depend upon that asymmetrical key. They're going to depend upon the fact that you're the client. It's going to depend upon

whatever server hosts the email that you access. It's going to depend upon the session time when you've actually started this. There are a lot of different factors that all uh come into play, and then that is what determines the individual session keys that then allow you to send information that's encrypted and receive information that's encrypted then decrypted so that you can read it, because if you just received encrypted information, it would not be terribly useful for a

human being. Interesting maybe, but not useful. Yeah, exactly, you just be thinking that while somebody let their cat walk around on their keyboard for like an hour or something, because it's just it's there's nothing meaningful here. So this is the basic idea here. Those the session keys are symmetrical and they're used in that encryption and decryption and symmetrical keys in general are not uh, by themselves incredibly secure because you've got one, you know how it all works.

But because it's based on the session and once the sessions over it's no longer a factor, it's considered pretty secure because it's not like it's something that lasts forever. It's not that long term asymmetrical key that's the really super important one. So yeah, this is used for um, pretty much anything that involves sending information across the Internet, which I don't know if you know this, that's what the Internet's for. So everything really is what it boils

down to. We're talking web mail, we're talking we're talking instant messages, web browsing voice over Internet protocol. So if you happen to use a void phone, it involves that as well. Uh. Even facts is for those of us who still have to um, yeah, so and and on and on every website, I mean, you know, and any anything that you have to log into. So Netflix uses yeah, oh yeah, exactly. Yeah. So here's the thing is that

open SSL is is one version of this implementation. Like we said, right, it's not that uh it's the only one, but it happens to be the most popular. And there's part of that name is pretty interesting. Or we we've talked about SSL, now it's time to talk about open right. Like I said earlier, it's an open source version of this right now. Open source, of course means that the the source code is available for people to look at,

to modify, to update, to tweak. And it's important because if there are two very different philosophies when it comes to security, right, you have the one philosophy where the idea is let's lock it all down, let's have a let's have a secure room where we've got our own experts developing this stuff. They are the one and only group that can do it. And furthermore that if you know, we only have these five people who know how this works, then it's a very secure system because we trust those

five people and everything's going to be cool. Assuming that none of those five people ever make a mistake, uh, then we're awesome. The other approach is the open source approach, where the idea is everyone who has the ability to look at this and to improve it has the chance to do so, and therefore you would in theory, end up eventually with the strongest kind of security because you would have some It wouldn't be limited to five people that you've identified as being really good at it. It's

it's not limited at all. Anyone can start making tweaks to it. It doesn't mean that the uh CO just runs rampant and gets out of control. You do have people in charge of making sure everything is still working, everything is on the up and up right, But you also have this entire network of checks and balances of people who are who are looking for any problems and trying to solve them and advancing them to that that

higher up system right exactly. So you know, again, two different approaches to the same goal, and depending upon what you're trying to accomplish. You might say one is better than the other. Now, the web at large has said the open SSL model was better. The reason I can say that is because it's so popular. We'll talk more about that a little later in the podcast. Right, but so so versions of this are available for I mean for for everything, for Unix Space systems, Linux Space Systems, uh,

Mac and also Windows. Yeah. And so you also have server software using it. Yeah, yeah, some of the major the two biggest types of our brands, I guess of server software Apache and how do you say that other one? Let's go with that, because here's the thing. A lot of these are names that you see written out all the time, but you don't ever have to say them if you if you are communicating, it's basically by text. Yes,

uh so injinks, let's go with that one. Um uh but but but right, But it's not totally universal, like, for example, Microsoft has proprietary server software called Internet Information Services,

which does not use open SSL. Right. And in fact, if you were to look at lists of sites that have been affected by this heart bleed bug, you would see that Microsoft Microsoft are not in Microsoft's are not involved because are using a completely different security approach completely different in the sense that it's it's a different implementation of the same sort of uh security. It's again, like I said, open SSL is a very specific one, so

heart bleed. The bug was announced on Monday, April seventh, two thousand fourteen, and the day we're recording this is April tenth, And of course this will be going live the following week, so you guys are are hearing. Probably I think this might be the most uh topical episode I have recorded in recent memory. So is the open SSL team, who said, all right, here's the news. Guys,

Uh it's bad, and prepare yourselves right. The bug was actually discovered the previous week independently by UM by a Google security employee named Neil Meta and researchers from a finished security company called Kotonomicon, which best name. Ever, it's pretty good. As soon as I saw Cotonomicon, I was like, I'm gonna have to flip a coin to find out which of us gets to say that first. I got to it suck Lauren. Lauren took that one. Well done,

thank you. But so the notifications spread through a few select organizations before the big announcement came out, so that those organizations could begin working on updates and fixes kind of quietly. This was because the disclosure would alert potential attackers to the security flaw as much as it would system administrators, so everyone was trying to be really careful. The announcement might have even been delayed further if the open SSL team thought that they could have gotten away

with it. Basically, they were afraid of leaks and so they figured that they might as well go forward. Yeah. I mean, if you're going to sit there and have to alert presumably some of the really big names on the Internet to this thing, then eventually you're going to say, well, someone on one of those teams is going to say something because this is such a huge issue, right Uh.

And you know this is this really reminds me a lot about white hat hackers, the people who make it there and sometimes you can call them gray hats too, but these are people who will find security vulnerabilities, and generally speaking there there m O tends to be alert. Whatever organization is responsible for fixing that vulnerability, give them a little time to do so, and if they haven't done it, say listen. If you guys don't do it soon, I'm gonna make this public because then you will have

to do it. You'll be obligated to because then everyone's gonna know about and if you don't do anything, someone's going to exploit it. And it's it's kind of this crazy sort of almost like I guess blackmail is the wrong word for it, but you're kind of holding a virtual gun to the head of the responsible organization. But you're doing so in order to keep security right forward, right it's in the best interests of everyone involved, and

there's a really delicate balance involved there. There there is a wee bit of controversy over who was notified when you know, some of the big companies like Yahoo and Amazon feel a little bit left out in the cold because they were. To be fair, Amazon the store was not affected, but Amazon as in the company that also, yeah,

the services that was affected. So it's it all depends on how like chances are most of our listeners don't have to worry about the Amazon side unless you happen to use the Amazon services to host major apps or or other sites or things of that nature, in which case you need to look into it. Right So, so, at any rate, I think that it's generally agreed upon right now that the involved parties we're using responsible disclosure to to mitigate damage as to the best of their abilities.

And the news then hit the public consciousness. I think on Wednesday, April nine, that's the first time that I heard stories about it. Of course I'm not assistant men, so yeah, and that's the day before we record this. So that's how how fast this stuff has really held Healy, This news is broken. Yeah, So the bug is present

in only certain versions of open SSL. Like all great software, open SSL has generations of versions, right, So if you were to run open ss L one point zero point to dash beta or any version that is uh involves one point zero point one up to one point zero point one F, those are all affected. One point zero point one G and later perfectly fine because that's when the vulnerability was patched. Or if you're running something that's earlier than that, you're fine because the bug had not

been implemented into the code. So really we're looking at one point zero point one through one point zero point one F and that one point zero point to DASH beta. Those are the ones that are um problematic. So some companies that are using open SSL, they might not be affected at all just because they never up updated the software, which you know, a lot of people will say when it comes to security, you want to keep yoursel up whereas up to date as possible. This is not one

of those times. Yeah, could as could as to those lazy ye maybe maybe they just felt something bad was coming. But what exactly is going on? So this bug, we've we've mentioned it a few times. This, this heart bleed bug, is a severe memory handling bug in the implementation of the tl S heartbeat extension. That's why it's called heartbleed because it's involving this heartbeat. A heartbeat here we go, Um,

a heartbeat. I'm gonna try and avoid making any nineteen eighties power ballad references here, but they're all going through my mind, trust me. So a heartbeat in this case, and the technology sense is a message sent from one machine to another while they are connected in one of these sessions. And the purpose of this message is really just to say, hey, are you still there? Right? Yeah, exactly, It's it's it's you know, saying I'm still here, are

you still there? And then the responses you still here, let's keep fund trucking? So um, that's generally what it is. But the way that heartbeats work is a little problematic. So normally what happens is you have machine A send a little message over to machine B, and if they don't hear anything back after a few seconds, machine A says, okay, Machine B has ended the session or as otherwise inoperable.

We will cancel the session on this side, and everything is over, and then if we want to start up again, we have to initiate a new session, all right, where we're throwing away those session keys. Yeah, yeah, but now now we know that we need to you know, re up security. But these heartbeat bugs are the heartbeat could reveal up to sixty bytes of data, and a heartbeat does not need to be sixty four kilobytes in size.

And they found out that if you were to send a heartbeat message, uh, and the actual file size is pretty small. Let's say it's just to kill bite. So you're just sending a one kilobyte message saying, hey, I'm here. Are you still there? Now? Technically what's supposed to happen is machine BE gets the message and sends an identical message back to machine A, Yes I'm still here, or technically it's hey, are you still there? Because it's whatever

the message was in the first case. But let's say that machine BE gets the message and the actual file size is one kilobyte, but for some reason, the stated file size is larger. Let's say it's sixty k by, so it's the maximum that a heartbeat can be. Now, Machine B has to reply back to Machine A, and it's doing it based on that stated file size, right, So it's going to take that that one kilobyte of the correct information and fill the rest of that up

with junk. With a junk. Yeah, it's kind of like, you know, if you've ever heard people say when you dream, it's just your brain making up junk to try and get rid of it, kind of the same thing. It's really the machine be starts to panic and says, oh, uh, this message needs to be way bigger than what I thought it need to be. Uh, let's just ship them

everything here. Uh. And And the thing is that when you when you dream, that junk is made up of I don't know, your your worries about passing chemistry in high school. In this case, the junk is made up

of stuff from your computer's random access memory. Now, random access memory tends to be pretty awesome stuff because it allows you to uh to have quick access to data that you use over and over again, and that means that you don't have to have your computer access the deep memory banks like the hard drive to try and find this information. It stays there in the random access memory makes things much faster Without it, everything which slow down. Right,

So here's the issue. Uh, normally random access memory, if you turn off a machine, it erases it's it overwrites itself all the time, and so nothing that stays in random access memory will stay there for very long comparatively speaking. So because of that, in general, it's considered to be pretty safe to have cryptograph keys stored in random access memory because one, you're going to need them all the time, right, You're gonna need it in order to make these communications.

And secondly, because if you turn off the power to your computer, it goes away, so you don't have to work right, right, and it could be overwritten at any given moment exactly. So the issue here is that since it can be in random access memory, if you were to if you were a hacker and you wanted to exploit the system, you can send a heartbeat that is the mimimum amount of information that you need to send,

but looks like the maximum amount of information. The server that you target is going to send you that maximum amount of information back, which may or may not include within it one of these cryptograph keys. Yeah, yeah, whatever John happens to be in the RAM, including potentially Yeah,

so it's it's a grab bag. It doesn't mean that you're every single time you hit it that you're going to end up with the jackpot of Now I can decrypt everything that goes across your network, right, but with enough of these heartbeat attacks, you can you can absolutely put together in piece together, uh a lot of scary information. Yeah. Yeah, you can get completely decrypted information. Maybe you didn't get the key, but you might get some information that was

going through the server that's really important. Or maybe you get a session key so you can see everything that's going on in that session, or maybe you get like the private key that the that's the golden goose that would allow you to not only be able to snoop on everything that's going through that server that normally would be encrypted, you could also potentially pose as that server and suddenly people think they are having a secure connection

with the service that they trust because all indications show that they are, but in reality, it's going to a hacker. Now, this is a fundamental flaw in internet security. There is no way to overstate how bad this is. Yeah, and and it's exists and since December one. Um, I mean it's technically only been in distribution since March of so so so that's much better. So here's here's the thing. We know how long it's been since the good guys

found out about it. The problem is we don't know if bad guys knew about it before then, because the other issue here is that you can't tell when someone's using this. They're completely untraceable. This is not like some sort of vulnerability where you have to have someone install a trojan backdoor program onto their computer. There's no need for that because it's it's a vulnerability, it's a bug within the security software itself. So yeah, this is bad,

bad news. And um we're going to talk about more why it's bad bad news. But wait, it gets worse. Yeah, So before we really dive into all that, let's take a quick break to thank our sponsor. Okay, law Ran We've talked about that this is seriously bad news. I think we we managed to communicate that the consequences are dire. But do we have a rough percentage of how many machines and services out there on the web actually use

open ssl? H Yeah about six? Okay, so you're telling me that two out of every three sites, services, apps, etcetera. Are working on a compromise security system. That that is exactly what I'm saying. Wow, that I mean, you know that's that's the estimate. That is that is what open ssl themselves have have have guessed. Yeah, yeah, that is m M. There are no words at this point. So I ended up creating an analogy. And this is a drastic oversimplification, as all my analogies are, but I was

an English lit major and I like them. So here we go. All right, Now, imagine that you have just purchased an old house. It's a gorgeous old house that you you have managed to buy, but you have no knowledge whatsoever of what the previous owners were like, or the kind of people that they hung out with, who they might have given keys to. So so you do the logical thing when you move in and you you have a locksmith come out and put new locks in the house. Yeah, so you have the keys to the

new locks. You're feeling pretty confident. Why you don't know is that that locksmith, uh not necessarily through any kind of malicious behavior, is just not the not the sharpest knife in the drawer. And so the locksmith keeps copies of all the keys that he or she makes in uh in in like a box that's easily found by anyone who happens to know where to look, completely accessible

to the to the public. Yeah, And so that means that while you feel that your box are completely secure because you have changed them all, in reality people can get access to copies of the sink keys that you use and us just walk right on into your house. That's not good. So now I think that two thirds of the internet has that same problem. That's not great either.

So including I'm talking like your email, your instant messaging, banking, all your user names and passwords, which are the kind of the clients side of this handshake we keep talking about, all of this can be read in plain text by someone who can exploit this bug. So and and it really only takes like like basic programming skills and a desire to do mischief or harm or to you know, impress your bosses at the n s A. But Lauren, come on, let's let's get some bright bright spots and

bright sunshine shining through the dark clouds. What can the average person do to protect him or herself more bad? Is not much? Oh those dark clouds. Yeah. Basically, the responsibility here lies not on you probably, but on the web. Yeah. So the administrators of the various sites, services, apps, people who develop operating systems, you know, everything that you encounter

on the web that requires this kind of security. That stuff has to be rolled out in the background on that back end, the stuff behind the scenes of the websites and apps that you use. That's where this needs to happen. So it's the The nice news is that this vulnerability has been patched. There is a solution out there, right, and it's right. It's it's just up to those system means to take that patch and implement it on their systems, right.

They have to be the ones to distribute it. And as of the recording of this podcast, some of them have done it. Some of them, of course, knew ahead of time by however many days, and they implemented the change. Then others are implementing it now. Others we hope will implement it soon. Right. So, so the responsibility of the

of the user of you guys here is really too. Um. Just just watch out for getting messages from any kind of services that you use online about when to change your password, right, because it doesn't do you any good to change your password right now. Yes, don't just go run out and change all of your passwords. Really niling right if you know for a fact that one of the services like Gmail, for example, Google is a great example. Google has addressed this now. They've said that you don't

necessarily have to change your password. I'm telling you change your password. This is coming from me, guys, change your password. Uh, it's better to be safe than sorry. And Google has already addressed the vulnerability so that it's safe for you to change your password there, but in other places it

may not be. And to go back to my locksmith analogy, Let's say that you have figured out that people have copies of your keys, so you go back to that same locksmith and have brand new locks put in and the old ones, the ones you had, the replacement ones you have thrown away new new locks are put in, the locksmith is still following that same protocol of keeping everything out in plain site. Then you haven't really solved the problem. All you've done is just changed your locks

one more time. So that's the same sort of thing. If you were to change your password before one of those sites, services, apps, etcetera. Was to implement this this this patch, you're still vulnerable. So it doesn't matter how much times you change your password, that password is still vulnerable to one of these attacks. Yeah, and and it could be it could be days or potentially even longer for some sites that you use to to get with

the program. Yeah, So the best thing to do is to use there are lots of different utilities online to check and see what which sites have addressed this already.

In fact, I think the heart bleed dot org has a link to a tool where all you do is you put in the u r L for the website that you're concerned about, and it'll do a little ping of that website and determine which version of open SSL, if any, is running on that site, and then it will give you a message saying whether or not it's okay for you to change your password, or if you need to or if you can't, then it may tell you, hey, you might need to send an email and say hey,

could you could you guys get on this because it's really important. So you can be a little proactive in that sense, but honestly you are dependent upon those those administrators doing their job to make sure that they're running

the latest of the open SSL protocols right there. There are some sites that have said that they were never vulnerable, and those include uh, Microsoft sites, as we stated earlier, a O L and LinkedIn, So they're safe unless, of course, you use the same password across multiple sites, which you should not be doing. No, don't do that. Um really, and I've recommended these before. Get yourself a password vault program, something like last pass or dash lane is what I use.

UM dash Lane, uh does use open s sl old, but it doesn't at all involve the passwords in your vault or your even your master passwords. So according to dash Lane, it's still safe, which was a big relief to me. Yeah. Yeah, last Pass has come out and said the same thing. And last Pass also has the benefit of it's telling users when to go in and change passwords. As we get updates about this security implementation right as as of the recording of this podcast, which

which again is Thursday, April tenth. Sites that were vulnerable at some point but are currently safe to change your passwords for now include Google, Facebook, Tumbler, Dropbox, and Yahoo, among the really big ones that are probably going to affect lots of people um and and Again as of right now, other sites are still working on fixes. Um and And probably will send you a message when it's

safe to get back in the digital water. But um, you know, yeah, if you if you want to check the status Jonathan talked about that, yeah, using last pass or using They're also blog posts out there that are kind of keeping a running alley of which sites have addressed it, because in some cases, you know, I would hope that any service at least at least has your email address is going to send you a message saying, hey,

change your password. But in in other cases you may have companies that do this through a blog post, which you know, maybe you see it, maybe you don't. I don't visit the blogs of most of the services I use. I know that a lot of them have blogs, but you know, I've only got so many hours in a day. So there are blog posts run by other people who are just kind of keeping a list as these different companies are upgrading and announcing it, so that you can just go to a master list and take a look

at all of them. Uh, it is important for you to actually change your passwords at that point when it tells you it's time to do so. Other bad news. I hate to do this, but anything that was done on those old open SSL channels that still out there is still going to be vulnerable. So for two years this was going on, so anyone who can access any of that older information will be able to do so.

From this point forward, things will be fine. But yeah, I mean, this is this is why when when security experts who were not prone to being um, hyperbolic, say to go to the hyper Bowl every year like we like to, they said, when you make this, uh you know, if you were to say, is this on the scale one of ten, how bad is secure? Yeah, this was all spinal tap on our butts here people. This was

not a good thing. So one other thing I recommend doing is if the service you use offers to factor authentication, do it. You know, usually it's a an option you don't have to use to factor authentication, and a lot of these services, some of them require it, but not all of them. Google has this, Facebook has it as well. Uh. And by the way, both Google and Facebook have addressed this issue. And you could go in and change your passwords, which I did just before I came in here. Um,

but yeah, you can. You can activate two factor authentication, which requires a secondary uh piece of log in information beyond just your user name and password that's generated specifically when you try to log in. So usually you get like a text message or an email that has a numeric code that you have to also enter in ord to log in. Once you've cleared a machine, usually it stays clear. Sometimes it will expire, which means that eventually

you'll have to do it again. But as irritating as you may find that, it's so much better than knowing that your stuff could be open for anyone to see at any time. So yeah, this, UM, this was definitely a topic that we felt we had to address um right away, because it's it's such a fundamental part of how the Internet works. I mean, really, the only thing that I can think of that would be more monumental is if, for some reason uh t c P i P protocol stopped working, in which case we wouldn't have

a job. I just I just had like a like a shiver. Um. Yeah, and I mean it's affecting everyone. Yeah, I mean everyone. This is across the globe. Um and and and it's complicated enough that yeah, yeah, we you know, we we really wanted to talk about what SSL does and what open ssl particularly does and yeah, so so we we We hope that you are at least um more comfortable in your knowledge of the doom. It's definitely better to know than not know. I mean, it is

not a happy story by any means. We have top men working on it, and women as well, of course, But you know, in Indiana Jones's day, they only they only acknowledge the men. Well that's yep. Hey, at least we don't live in Indiana Jones time. That's that's true. I have not had to outrun any boulders in days, so that's good. But yeah, this is a This was a topic. We thought it was interesting enough and important

enough that we had to cover it right away. But if you guys have suggestions for topics that we should cover next, whether it's something that's happened in the news recently, or maybe there's that one piece of technology dating back to twelve fifty a d that you've always wanted to know more about and we're afraid to ask. I'd say to you, do not be afraid ask us your silly question, because we will give you a silly answer, probably in podcast form. But in order to ask that question, you

need to send us email. It address is tech stuff at Discovery dot com. You can also get in touch with us via various social media networks. Those are Twitter, Tumbler, and Facebook. In all three places, our handle is tech Stuff HSW and we will talk to you again. True encryption really soon. For more on this and thousands of other topics. Does it has stuff works dot com check checks