Speaker 1: Get in touch with technology with tech Stuff from how
Speaker 1: stuff works dot com. Hey there, and welcome to tech Stuff.
Speaker 1: I'm Jonathan Strickland and I'm Lauren and we're going to
Speaker 1: talk about a really bad day on the internet and
Speaker 1: the terrible, horrible, no good, very bad day and actually
Speaker 1: it's a it's a very bad day that lasted for
Speaker 1: a couple of years before we knew about it. Oops. Yeah,
Speaker 1: we're talking about heart bleed, which if any of you,
Speaker 1: I'm assuming a lot of our listeners keep up with
Speaker 1: tech news in general, and normally on tech stuff, we
Speaker 1: don't cover things that are of the immediate uh past,
Speaker 1: because often we record ahead of time and it's over.
Speaker 1: We we often, in fact kind of kind of almost
Speaker 1: avoid very breaking news so that we have a chance
Speaker 1: to discuss more in depth exactly what has happened. However,
Speaker 1: this is such a huge story and it's one that
Speaker 1: is a little difficult for someone to to understand if
Speaker 1: they don't really have a working knowledge of of what
Speaker 1: actually is going on behind the scenes, that we thought
Speaker 1: it was important to address this and actually talk about
Speaker 1: what you guys can do in order to protect yourselves
Speaker 1: as best as possible. It's not all gonna be a
Speaker 1: happy story, folks. This is actually a pretty serious problem.
Speaker 1: In fact, pretty serious is an incredible understatement. Um So, really,
Speaker 1: what it gets down to is this is a story
Speaker 1: all about encryption. So encryption pretty simple. I mean you've
Speaker 1: probably heard the term. It's not not too simple. I mean,
Speaker 1: the concept is simple. Execution is somewhat more complicated. But
Speaker 1: the concept is that you are you are changing something
Speaker 1: so that the content is not easily readable from anyone
Speaker 1: else unless they have the key to decrypt that information. Right.
Speaker 1: And this is really important for many different web related
Speaker 1: purposes because you know, any any time that you don't
Speaker 1: want everyone on the internet who chooses to to read
Speaker 1: your emails or get your get into your bank account
Speaker 1: or etcetera, etcetera. Yeah, you want to you want to
Speaker 1: make sure that stuff is encrypted. So you know, you
Speaker 1: probably have heard that when you log into sites that
Speaker 1: are going to have a lot of access to to
Speaker 1: secure what should be secure information like things like your
Speaker 1: bank account or just shopping history or your medical information
Speaker 1: that's a great example. Then you know that you want
Speaker 1: to look for that HTTPS which tells you it's a
Speaker 1: secure or it's supposed to be a secure connection right,
Speaker 1: or that little padlock that will show up in your
Speaker 1: in your web browser right exactly, and that tells you, hey, uh,
Speaker 1: there's a there's a handshake that's going on between your
Speaker 1: browser and that website that indicates the connection is secure
Speaker 1: and encrypted, and that anyone looking in from the outside
Speaker 1: should just see gibberish. And furthermore that the website that
Speaker 1: you're that you're on is what it says it is,
Speaker 1: that it's not an imposter for possibly nefarious purposes exactly
Speaker 1: because there's an attack called the man in the middle attack,
Speaker 1: which is where you have a hacker insert him or
Speaker 1: herself in the middle of communication between you and whatever
Speaker 1: service you actually want to use, and that way they
Speaker 1: are able to access all the information you're sending and
Speaker 1: you think you're sending it to the service, but you're
Speaker 1: really sending it to the hacker. This security is supposed
Speaker 1: to allow you to make you know, to be sure
Speaker 1: that it's going exactly where it needs to go and
Speaker 1: that no one is snooping on you. So it turns
Speaker 1: out that the most popular online encryption software used on
Speaker 1: the web today had a fundamental flaw and its security
Speaker 1: in several recent builds of that software that have been
Speaker 1: in use for the past two years or so. Yeah,
Speaker 1: and that is heart bleed. So, first of all, the
Speaker 1: software we're talking about is called open s s L.
Speaker 1: This is an open source version of SSL. Yeah, it
Speaker 1: stands for Secure Sockets Layer. Now it's it's a protocol,
Speaker 1: so it's a set of rules that tell UH sites
Speaker 1: how to encrypt information. And there are lots of different
Speaker 1: ways you can implement this. SSL is just that's kind
Speaker 1: of like the the the the specific category, but then
Speaker 1: you can implement it in different ways. Open SSL is
Speaker 1: one of those ways. Yeah, I would say proprietary, but
Speaker 1: since it's open source, that might be kind of the
Speaker 1: wrong word. So it's a specific version exactly exactly. So
Speaker 1: you know, it's all about securing your transmissions across the
Speaker 1: Internet so that they remain opaque to anyone else. They're
Speaker 1: not gonna be able to see them, and UH in general,
Speaker 1: to communicating parties are given encryption keys which allow each
Speaker 1: party to encrypt and decrypt messages so that they can
Speaker 1: send it back and forth and only in theory the
Speaker 1: other party can see what's going on, and only for
Speaker 1: the length of this particular communication session, right, because once
Speaker 1: that session ends, then the session keys that's what you're
Speaker 1: using to encrypt and decrypt are magically dissolve. So there's
Speaker 1: actually two different types of encryption keys we're talking about here.
Speaker 1: There's one that's called an asymmetrical key, and that's sort
Speaker 1: of a long term key that's like the the overall
Speaker 1: rules that guide the any individual session. The session key
Speaker 1: is dependent upon lots of stuff. It's dependent upon the client.
Speaker 1: That's the that would be you using your computer to
Speaker 1: access whatever it is you want to access. Let's, for
Speaker 1: the argument's sake, say it's your email. So your client,
Speaker 1: your your computer is the client. You send out a
Speaker 1: request to log into your email. The email exists on
Speaker 1: a server. That's that's the server on the client server side,
Speaker 1: and so the the session keys are going to depend
Speaker 1: upon that asymmetrical key. They're going to depend upon the
Speaker 1: fact that you're the client. It's going to depend upon
Speaker 1: whatever server hosts the email that you access. It's going
Speaker 1: to depend upon the session time when you've actually started this.
Speaker 1: There are a lot of different factors that all uh
Speaker 1: come into play, and then that is what determines the
Speaker 1: individual session keys that then allow you to send information
Speaker 1: that's encrypted and receive information that's encrypted then decrypted so
Speaker 1: that you can read it, because if you just received
Speaker 1: encrypted information, it would not be terribly useful for a
Speaker 1: human being. Interesting maybe, but not useful. Yeah, exactly, you
Speaker 1: just be thinking that while somebody let their cat walk
Speaker 1: around on their keyboard for like an hour or something,
Speaker 1: because it's just it's there's nothing meaningful here. So this
Speaker 1: is the basic idea here. Those the session keys are
Speaker 1: symmetrical and they're used in that encryption and decryption and
Speaker 1: symmetrical keys in general are not uh, by themselves incredibly
Speaker 1: secure because you've got one, you know how it all works.
Speaker 1: But because it's based on the session and once the
Speaker 1: sessions over it's no longer a factor, it's considered pretty
Speaker 1: secure because it's not like it's something that lasts forever.
Speaker 1: It's not that long term asymmetrical key that's the really
Speaker 1: super important one. So yeah, this is used for um,
Speaker 1: pretty much anything that involves sending information across the Internet,
Speaker 1: which I don't know if you know this, that's what
Speaker 1: the Internet's for. So everything really is what it boils
Speaker 1: down to. We're talking web mail, we're talking we're talking
Speaker 1: instant messages, web browsing voice over Internet protocol. So if
Speaker 1: you happen to use a void phone, it involves that
Speaker 1: as well. Uh. Even facts is for those of us
Speaker 1: who still have to um, yeah, so and and on
Speaker 1: and on every website, I mean, you know, and any
Speaker 1: anything that you have to log into. So Netflix uses yeah,
Speaker 1: oh yeah, exactly. Yeah. So here's the thing is that
Speaker 1: open SSL is is one version of this implementation. Like
Speaker 1: we said, right, it's not that uh it's the only one,
Speaker 1: but it happens to be the most popular. And there's
Speaker 1: part of that name is pretty interesting. Or we we've
Speaker 1: talked about SSL, now it's time to talk about open right.
Speaker 1: Like I said earlier, it's an open source version of
Speaker 1: this right now. Open source, of course means that the
Speaker 1: the source code is available for people to look at,
Speaker 1: to modify, to update, to tweak. And it's important because
Speaker 1: if there are two very different philosophies when it comes
Speaker 1: to security, right, you have the one philosophy where the
Speaker 1: idea is let's lock it all down, let's have a
Speaker 1: let's have a secure room where we've got our own
Speaker 1: experts developing this stuff. They are the one and only
Speaker 1: group that can do it. And furthermore that if you know,
Speaker 1: we only have these five people who know how this works,
Speaker 1: then it's a very secure system because we trust those
Speaker 1: five people and everything's going to be cool. Assuming that
Speaker 1: none of those five people ever make a mistake, uh,
Speaker 1: then we're awesome. The other approach is the open source approach,
Speaker 1: where the idea is everyone who has the ability to
Speaker 1: look at this and to improve it has the chance
Speaker 1: to do so, and therefore you would in theory, end
Speaker 1: up eventually with the strongest kind of security because you
Speaker 1: would have some It wouldn't be limited to five people
Speaker 1: that you've identified as being really good at it. It's
Speaker 1: it's not limited at all. Anyone can start making tweaks
Speaker 1: to it. It doesn't mean that the uh CO just
Speaker 1: runs rampant and gets out of control. You do have
Speaker 1: people in charge of making sure everything is still working,
Speaker 1: everything is on the up and up right, But you
Speaker 1: also have this entire network of checks and balances of
Speaker 1: people who are who are looking for any problems and
Speaker 1: trying to solve them and advancing them to that that
Speaker 1: higher up system right exactly. So you know, again, two
Speaker 1: different approaches to the same goal, and depending upon what
Speaker 1: you're trying to accomplish. You might say one is better
Speaker 1: than the other. Now, the web at large has said
Speaker 1: the open SSL model was better. The reason I can
Speaker 1: say that is because it's so popular. We'll talk more
Speaker 1: about that a little later in the podcast. Right, but
Speaker 1: so so versions of this are available for I mean
Speaker 1: for for everything, for Unix Space systems, Linux Space Systems, uh,
Speaker 1: Mac and also Windows. Yeah. And so you also have
Speaker 1: server software using it. Yeah, yeah, some of the major
Speaker 1: the two biggest types of our brands, I guess of
Speaker 1: server software Apache and how do you say that other one?
Speaker 1: Let's go with that, because here's the thing. A lot
Speaker 1: of these are names that you see written out all
Speaker 1: the time, but you don't ever have to say them
Speaker 1: if you if you are communicating, it's basically by text. Yes,
Speaker 1: uh so injinks, let's go with that one. Um uh
Speaker 1: but but but right, But it's not totally universal, like,
Speaker 1: for example, Microsoft has proprietary server software called Internet Information Services,
Speaker 1: which does not use open SSL. Right. And in fact,
Speaker 1: if you were to look at lists of sites that
Speaker 1: have been affected by this heart bleed bug, you would
Speaker 1: see that Microsoft Microsoft are not in Microsoft's are not
Speaker 1: involved because are using a completely different security approach completely
Speaker 1: different in the sense that it's it's a different implementation
Speaker 1: of the same sort of uh security. It's again, like
Speaker 1: I said, open SSL is a very specific one, so
Speaker 1: heart bleed. The bug was announced on Monday, April seventh,
Speaker 1: two thousand fourteen, and the day we're recording this is
Speaker 1: April tenth, And of course this will be going live
Speaker 1: the following week, so you guys are are hearing. Probably
Speaker 1: I think this might be the most uh topical episode
Speaker 1: I have recorded in recent memory. So is the open
Speaker 1: SSL team, who said, all right, here's the news. Guys,
Speaker 1: Uh it's bad, and prepare yourselves right. The bug was
Speaker 1: actually discovered the previous week independently by UM by a
Speaker 1: Google security employee named Neil Meta and researchers from a
Speaker 1: finished security company called Kotonomicon, which best name. Ever, it's
Speaker 1: pretty good. As soon as I saw Cotonomicon, I was like,
Speaker 1: I'm gonna have to flip a coin to find out
Speaker 1: which of us gets to say that first. I got
Speaker 1: to it suck Lauren. Lauren took that one. Well done,
Speaker 1: thank you. But so the notifications spread through a few
Speaker 1: select organizations before the big announcement came out, so that
Speaker 1: those organizations could begin working on updates and fixes kind
Speaker 1: of quietly. This was because the disclosure would alert potential
Speaker 1: attackers to the security flaw as much as it would
Speaker 1: system administrators, so everyone was trying to be really careful.
Speaker 1: The announcement might have even been delayed further if the
Speaker 1: open SSL team thought that they could have gotten away
Speaker 1: with it. Basically, they were afraid of leaks and so
Speaker 1: they figured that they might as well go forward. Yeah.
Speaker 1: I mean, if you're going to sit there and have
Speaker 1: to alert presumably some of the really big names on
Speaker 1: the Internet to this thing, then eventually you're going to say, well,
Speaker 1: someone on one of those teams is going to say
Speaker 1: something because this is such a huge issue, right Uh.
Speaker 1: And you know this is this really reminds me a
Speaker 1: lot about white hat hackers, the people who make it
Speaker 1: there and sometimes you can call them gray hats too,
Speaker 1: but these are people who will find security vulnerabilities, and
Speaker 1: generally speaking there there m O tends to be alert.
Speaker 1: Whatever organization is responsible for fixing that vulnerability, give them
Speaker 1: a little time to do so, and if they haven't
Speaker 1: done it, say listen. If you guys don't do it soon,
Speaker 1: I'm gonna make this public because then you will have
Speaker 1: to do it. You'll be obligated to because then everyone's
Speaker 1: gonna know about and if you don't do anything, someone's
Speaker 1: going to exploit it. And it's it's kind of this
Speaker 1: crazy sort of almost like I guess blackmail is the
Speaker 1: wrong word for it, but you're kind of holding a
Speaker 1: virtual gun to the head of the responsible organization. But
Speaker 1: you're doing so in order to keep security right forward,
Speaker 1: right it's in the best interests of everyone involved, and
Speaker 1: there's a really delicate balance involved there. There there is
Speaker 1: a wee bit of controversy over who was notified when
Speaker 1: you know, some of the big companies like Yahoo and
Speaker 1: Amazon feel a little bit left out in the cold
Speaker 1: because they were. To be fair, Amazon the store was
Speaker 1: not affected, but Amazon as in the company that also, yeah,
Speaker 1: the services that was affected. So it's it all depends
Speaker 1: on how like chances are most of our listeners don't
Speaker 1: have to worry about the Amazon side unless you happen
Speaker 1: to use the Amazon services to host major apps or
Speaker 1: or other sites or things of that nature, in which
Speaker 1: case you need to look into it. Right So, so,
Speaker 1: at any rate, I think that it's generally agreed upon
Speaker 1: right now that the involved parties we're using responsible disclosure
Speaker 1: to to mitigate damage as to the best of their abilities.
Speaker 1: And the news then hit the public consciousness. I think
Speaker 1: on Wednesday, April nine, that's the first time that I
Speaker 1: heard stories about it. Of course I'm not assistant men,
Speaker 1: so yeah, and that's the day before we record this.
Speaker 1: So that's how how fast this stuff has really held Healy,
Speaker 1: This news is broken. Yeah, So the bug is present
Speaker 1: in only certain versions of open SSL. Like all great software,
Speaker 1: open SSL has generations of versions, right, So if you
Speaker 1: were to run open ss L one point zero point
Speaker 1: to dash beta or any version that is uh involves
Speaker 1: one point zero point one up to one point zero
Speaker 1: point one F, those are all affected. One point zero
Speaker 1: point one G and later perfectly fine because that's when
Speaker 1: the vulnerability was patched. Or if you're running something that's
Speaker 1: earlier than that, you're fine because the bug had not
Speaker 1: been implemented into the code. So really we're looking at
Speaker 1: one point zero point one through one point zero point
Speaker 1: one F and that one point zero point to DASH beta.
Speaker 1: Those are the ones that are um problematic. So some
Speaker 1: companies that are using open SSL, they might not be
Speaker 1: affected at all just because they never up updated the software,
Speaker 1: which you know, a lot of people will say when
Speaker 1: it comes to security, you want to keep yoursel up
Speaker 1: whereas up to date as possible. This is not one
Speaker 1: of those times. Yeah, could as could as to those
Speaker 1: lazy ye maybe maybe they just felt something bad was coming.
Speaker 1: But what exactly is going on? So this bug, we've
Speaker 1: we've mentioned it a few times. This, this heart bleed bug,
Speaker 1: is a severe memory handling bug in the implementation of
Speaker 1: the tl S heartbeat extension. That's why it's called heartbleed
Speaker 1: because it's involving this heartbeat. A heartbeat here we go, Um,
Speaker 1: a heartbeat. I'm gonna try and avoid making any nineteen
Speaker 1: eighties power ballad references here, but they're all going through
Speaker 1: my mind, trust me. So a heartbeat in this case,
Speaker 1: and the technology sense is a message sent from one
Speaker 1: machine to another while they are connected in one of
Speaker 1: these sessions. And the purpose of this message is really
Speaker 1: just to say, hey, are you still there? Right? Yeah, exactly,
Speaker 1: It's it's it's you know, saying I'm still here, are
Speaker 1: you still there? And then the responses you still here,
Speaker 1: let's keep fund trucking? So um, that's generally what it is.
Speaker 1: But the way that heartbeats work is a little problematic.
Speaker 1: So normally what happens is you have machine A send
Speaker 1: a little message over to machine B, and if they
Speaker 1: don't hear anything back after a few seconds, machine A says, okay,
Speaker 1: Machine B has ended the session or as otherwise inoperable.
Speaker 1: We will cancel the session on this side, and everything
Speaker 1: is over, and then if we want to start up again,
Speaker 1: we have to initiate a new session, all right, where
Speaker 1: we're throwing away those session keys. Yeah, yeah, but now
Speaker 1: now we know that we need to you know, re
Speaker 1: up security. But these heartbeat bugs are the heartbeat could
Speaker 1: reveal up to sixty bytes of data, and a heartbeat
Speaker 1: does not need to be sixty four kilobytes in size.
Speaker 1: And they found out that if you were to send
Speaker 1: a heartbeat message, uh, and the actual file size is
Speaker 1: pretty small. Let's say it's just to kill bite. So
Speaker 1: you're just sending a one kilobyte message saying, hey, I'm here.
Speaker 1: Are you still there? Now? Technically what's supposed to happen
Speaker 1: is machine BE gets the message and sends an identical
Speaker 1: message back to machine A, Yes I'm still here, or
Speaker 1: technically it's hey, are you still there? Because it's whatever
Speaker 1: the message was in the first case. But let's say
Speaker 1: that machine BE gets the message and the actual file
Speaker 1: size is one kilobyte, but for some reason, the stated
Speaker 1: file size is larger. Let's say it's sixty k by,
Speaker 1: so it's the maximum that a heartbeat can be. Now,
Speaker 1: Machine B has to reply back to Machine A, and
Speaker 1: it's doing it based on that stated file size, right,
Speaker 1: So it's going to take that that one kilobyte of
Speaker 1: the correct information and fill the rest of that up
Speaker 1: with junk. With a junk. Yeah, it's kind of like,
Speaker 1: you know, if you've ever heard people say when you dream,
Speaker 1: it's just your brain making up junk to try and
Speaker 1: get rid of it, kind of the same thing. It's
Speaker 1: really the machine be starts to panic and says, oh, uh,
Speaker 1: this message needs to be way bigger than what I
Speaker 1: thought it need to be. Uh, let's just ship them
Speaker 1: everything here. Uh. And And the thing is that when
Speaker 1: you when you dream, that junk is made up of
Speaker 1: I don't know, your your worries about passing chemistry in
Speaker 1: high school. In this case, the junk is made up
Speaker 1: of stuff from your computer's random access memory. Now, random
Speaker 1: access memory tends to be pretty awesome stuff because it
Speaker 1: allows you to uh to have quick access to data
Speaker 1: that you use over and over again, and that means
Speaker 1: that you don't have to have your computer access the
Speaker 1: deep memory banks like the hard drive to try and
Speaker 1: find this information. It stays there in the random access
Speaker 1: memory makes things much faster Without it, everything which slow down. Right,
Speaker 1: So here's the issue. Uh, normally random access memory, if
Speaker 1: you turn off a machine, it erases it's it overwrites
Speaker 1: itself all the time, and so nothing that stays in
Speaker 1: random access memory will stay there for very long comparatively speaking.
Speaker 1: So because of that, in general, it's considered to be
Speaker 1: pretty safe to have cryptograph keys stored in random access
Speaker 1: memory because one, you're going to need them all the time, right,
Speaker 1: You're gonna need it in order to make these communications.
Speaker 1: And secondly, because if you turn off the power to
Speaker 1: your computer, it goes away, so you don't have to
Speaker 1: work right, right, and it could be overwritten at any
Speaker 1: given moment exactly. So the issue here is that since
Speaker 1: it can be in random access memory, if you were
Speaker 1: to if you were a hacker and you wanted to
Speaker 1: exploit the system, you can send a heartbeat that is
Speaker 1: the mimimum amount of information that you need to send,
Speaker 1: but looks like the maximum amount of information. The server
Speaker 1: that you target is going to send you that maximum
Speaker 1: amount of information back, which may or may not include
Speaker 1: within it one of these cryptograph keys. Yeah, yeah, whatever
Speaker 1: John happens to be in the RAM, including potentially Yeah,
Speaker 1: so it's it's a grab bag. It doesn't mean that
Speaker 1: you're every single time you hit it that you're going
Speaker 1: to end up with the jackpot of Now I can
Speaker 1: decrypt everything that goes across your network, right, but with
Speaker 1: enough of these heartbeat attacks, you can you can absolutely
Speaker 1: put together in piece together, uh a lot of scary information. Yeah. Yeah,
Speaker 1: you can get completely decrypted information. Maybe you didn't get
Speaker 1: the key, but you might get some information that was
Speaker 1: going through the server that's really important. Or maybe you
Speaker 1: get a session key so you can see everything that's
Speaker 1: going on in that session, or maybe you get like
Speaker 1: the private key that the that's the golden goose that
Speaker 1: would allow you to not only be able to snoop
Speaker 1: on everything that's going through that server that normally would
Speaker 1: be encrypted, you could also potentially pose as that server
Speaker 1: and suddenly people think they are having a secure connection
Speaker 1: with the service that they trust because all indications show
Speaker 1: that they are, but in reality, it's going to a hacker. Now,
Speaker 1: this is a fundamental flaw in internet security. There is
Speaker 1: no way to overstate how bad this is. Yeah, and
Speaker 1: and it's exists and since December one. Um, I mean
Speaker 1: it's technically only been in distribution since March of so
Speaker 1: so so that's much better. So here's here's the thing.
Speaker 1: We know how long it's been since the good guys
Speaker 1: found out about it. The problem is we don't know
Speaker 1: if bad guys knew about it before then, because the
Speaker 1: other issue here is that you can't tell when someone's
Speaker 1: using this. They're completely untraceable. This is not like some
Speaker 1: sort of vulnerability where you have to have someone install
Speaker 1: a trojan backdoor program onto their computer. There's no need
Speaker 1: for that because it's it's a vulnerability, it's a bug
Speaker 1: within the security software itself. So yeah, this is bad,
Speaker 1: bad news. And um we're going to talk about more
Speaker 1: why it's bad bad news. But wait, it gets worse. Yeah,
Speaker 1: So before we really dive into all that, let's take
Speaker 1: a quick break to thank our sponsor. Okay, law Ran
Speaker 1: We've talked about that this is seriously bad news. I
Speaker 1: think we we managed to communicate that the consequences are dire.
Speaker 1: But do we have a rough percentage of how many
Speaker 1: machines and services out there on the web actually use
Speaker 1: open ssl? H Yeah about six? Okay, so you're telling
Speaker 1: me that two out of every three sites, services, apps, etcetera.
Speaker 1: Are working on a compromise security system. That that is
Speaker 1: exactly what I'm saying. Wow, that I mean, you know
Speaker 1: that's that's the estimate. That is that is what open
Speaker 1: ssl themselves have have have guessed. Yeah, yeah, that is
Speaker 1: m M. There are no words at this point. So
Speaker 1: I ended up creating an analogy. And this is a
Speaker 1: drastic oversimplification, as all my analogies are, but I was
Speaker 1: an English lit major and I like them. So here
Speaker 1: we go. All right, Now, imagine that you have just
Speaker 1: purchased an old house. It's a gorgeous old house that
Speaker 1: you you have managed to buy, but you have no
Speaker 1: knowledge whatsoever of what the previous owners were like, or
Speaker 1: the kind of people that they hung out with, who
Speaker 1: they might have given keys to. So so you do
Speaker 1: the logical thing when you move in and you you
Speaker 1: have a locksmith come out and put new locks in
Speaker 1: the house. Yeah, so you have the keys to the
Speaker 1: new locks. You're feeling pretty confident. Why you don't know
Speaker 1: is that that locksmith, uh not necessarily through any kind
Speaker 1: of malicious behavior, is just not the not the sharpest
Speaker 1: knife in the drawer. And so the locksmith keeps copies
Speaker 1: of all the keys that he or she makes in
Speaker 1: uh in in like a box that's easily found by
Speaker 1: anyone who happens to know where to look, completely accessible
Speaker 1: to the to the public. Yeah, And so that means
Speaker 1: that while you feel that your box are completely secure
Speaker 1: because you have changed them all, in reality people can
Speaker 1: get access to copies of the sink keys that you
Speaker 1: use and us just walk right on into your house.
Speaker 1: That's not good. So now I think that two thirds
Speaker 1: of the internet has that same problem. That's not great either.
Speaker 1: So including I'm talking like your email, your instant messaging, banking,
Speaker 1: all your user names and passwords, which are the kind
Speaker 1: of the clients side of this handshake we keep talking about,
Speaker 1: all of this can be read in plain text by
Speaker 1: someone who can exploit this bug. So and and it
Speaker 1: really only takes like like basic programming skills and a
Speaker 1: desire to do mischief or harm or to you know,
Speaker 1: impress your bosses at the n s A. But Lauren,
Speaker 1: come on, let's let's get some bright bright spots and
Speaker 1: bright sunshine shining through the dark clouds. What can the
Speaker 1: average person do to protect him or herself more bad?
Speaker 1: Is not much? Oh those dark clouds. Yeah. Basically, the
Speaker 1: responsibility here lies not on you probably, but on the web. Yeah.
Speaker 1: So the administrators of the various sites, services, apps, people
Speaker 1: who develop operating systems, you know, everything that you encounter
Speaker 1: on the web that requires this kind of security. That
Speaker 1: stuff has to be rolled out in the background on
Speaker 1: that back end, the stuff behind the scenes of the
Speaker 1: websites and apps that you use. That's where this needs
Speaker 1: to happen. So it's the The nice news is that
Speaker 1: this vulnerability has been patched. There is a solution out there, right,
Speaker 1: and it's right. It's it's just up to those system
Speaker 1: means to take that patch and implement it on their systems, right.
Speaker 1: They have to be the ones to distribute it. And
Speaker 1: as of the recording of this podcast, some of them
Speaker 1: have done it. Some of them, of course, knew ahead
Speaker 1: of time by however many days, and they implemented the change.
Speaker 1: Then others are implementing it now. Others we hope will
Speaker 1: implement it soon. Right. So, so the responsibility of the
Speaker 1: of the user of you guys here is really too. Um.
Speaker 1: Just just watch out for getting messages from any kind
Speaker 1: of services that you use online about when to change
Speaker 1: your password, right, because it doesn't do you any good
Speaker 1: to change your password right now. Yes, don't just go
Speaker 1: run out and change all of your passwords. Really niling
Speaker 1: right if you know for a fact that one of
Speaker 1: the services like Gmail, for example, Google is a great example.
Speaker 1: Google has addressed this now. They've said that you don't
Speaker 1: necessarily have to change your password. I'm telling you change
Speaker 1: your password. This is coming from me, guys, change your password. Uh,
Speaker 1: it's better to be safe than sorry. And Google has
Speaker 1: already addressed the vulnerability so that it's safe for you
Speaker 1: to change your password there, but in other places it
Speaker 1: may not be. And to go back to my locksmith analogy,
Speaker 1: Let's say that you have figured out that people have
Speaker 1: copies of your keys, so you go back to that
Speaker 1: same locksmith and have brand new locks put in and
Speaker 1: the old ones, the ones you had, the replacement ones
Speaker 1: you have thrown away new new locks are put in,
Speaker 1: the locksmith is still following that same protocol of keeping
Speaker 1: everything out in plain site. Then you haven't really solved
Speaker 1: the problem. All you've done is just changed your locks
Speaker 1: one more time. So that's the same sort of thing.
Speaker 1: If you were to change your password before one of
Speaker 1: those sites, services, apps, etcetera. Was to implement this this
Speaker 1: this patch, you're still vulnerable. So it doesn't matter how
Speaker 1: much times you change your password, that password is still
Speaker 1: vulnerable to one of these attacks. Yeah, and and it
Speaker 1: could be it could be days or potentially even longer
Speaker 1: for some sites that you use to to get with
Speaker 1: the program. Yeah, So the best thing to do is
Speaker 1: to use there are lots of different utilities online to
Speaker 1: check and see what which sites have addressed this already.
Speaker 1: In fact, I think the heart bleed dot org has
Speaker 1: a link to a tool where all you do is
Speaker 1: you put in the u r L for the website
Speaker 1: that you're concerned about, and it'll do a little ping
Speaker 1: of that website and determine which version of open SSL,
Speaker 1: if any, is running on that site, and then it
Speaker 1: will give you a message saying whether or not it's
Speaker 1: okay for you to change your password, or if you
Speaker 1: need to or if you can't, then it may tell you, hey,
Speaker 1: you might need to send an email and say hey,
Speaker 1: could you could you guys get on this because it's
Speaker 1: really important. So you can be a little proactive in
Speaker 1: that sense, but honestly you are dependent upon those those
Speaker 1: administrators doing their job to make sure that they're running
Speaker 1: the latest of the open SSL protocols right there. There
Speaker 1: are some sites that have said that they were never vulnerable,
Speaker 1: and those include uh, Microsoft sites, as we stated earlier,
Speaker 1: a O L and LinkedIn, So they're safe unless, of course,
Speaker 1: you use the same password across multiple sites, which you
Speaker 1: should not be doing. No, don't do that. Um really,
Speaker 1: and I've recommended these before. Get yourself a password vault program,
Speaker 1: something like last pass or dash lane is what I use.
Speaker 1: UM dash Lane, uh does use open s sl old,
Speaker 1: but it doesn't at all involve the passwords in your
Speaker 1: vault or your even your master passwords. So according to
Speaker 1: dash Lane, it's still safe, which was a big relief
Speaker 1: to me. Yeah. Yeah, last Pass has come out and
Speaker 1: said the same thing. And last Pass also has the
Speaker 1: benefit of it's telling users when to go in and
Speaker 1: change passwords. As we get updates about this security implementation
Speaker 1: right as as of the recording of this podcast, which
Speaker 1: which again is Thursday, April tenth. Sites that were vulnerable
Speaker 1: at some point but are currently safe to change your
Speaker 1: passwords for now include Google, Facebook, Tumbler, Dropbox, and Yahoo,
Speaker 1: among the really big ones that are probably going to
Speaker 1: affect lots of people um and and Again as of
Speaker 1: right now, other sites are still working on fixes. Um
Speaker 1: and And probably will send you a message when it's
Speaker 1: safe to get back in the digital water. But um,
Speaker 1: you know, yeah, if you if you want to check
Speaker 1: the status Jonathan talked about that, yeah, using last pass
Speaker 1: or using They're also blog posts out there that are
Speaker 1: kind of keeping a running alley of which sites have
Speaker 1: addressed it, because in some cases, you know, I would
Speaker 1: hope that any service at least at least has your
Speaker 1: email address is going to send you a message saying, hey,
Speaker 1: change your password. But in in other cases you may
Speaker 1: have companies that do this through a blog post, which
Speaker 1: you know, maybe you see it, maybe you don't. I
Speaker 1: don't visit the blogs of most of the services I use.
Speaker 1: I know that a lot of them have blogs, but
Speaker 1: you know, I've only got so many hours in a day.
Speaker 1: So there are blog posts run by other people who
Speaker 1: are just kind of keeping a list as these different
Speaker 1: companies are upgrading and announcing it, so that you can
Speaker 1: just go to a master list and take a look
Speaker 1: at all of them. Uh, it is important for you
Speaker 1: to actually change your passwords at that point when it
Speaker 1: tells you it's time to do so. Other bad news.
Speaker 1: I hate to do this, but anything that was done
Speaker 1: on those old open SSL channels that still out there
Speaker 1: is still going to be vulnerable. So for two years
Speaker 1: this was going on, so anyone who can access any
Speaker 1: of that older information will be able to do so.
Speaker 1: From this point forward, things will be fine. But yeah,
Speaker 1: I mean, this is this is why when when security
Speaker 1: experts who were not prone to being um, hyperbolic, say
Speaker 1: to go to the hyper Bowl every year like we
Speaker 1: like to, they said, when you make this, uh you know,
Speaker 1: if you were to say, is this on the scale
Speaker 1: one of ten, how bad is secure? Yeah, this was
Speaker 1: all spinal tap on our butts here people. This was
Speaker 1: not a good thing. So one other thing I recommend
Speaker 1: doing is if the service you use offers to factor authentication,
Speaker 1: do it. You know, usually it's a an option you
Speaker 1: don't have to use to factor authentication, and a lot
Speaker 1: of these services, some of them require it, but not
Speaker 1: all of them. Google has this, Facebook has it as well. Uh.
Speaker 1: And by the way, both Google and Facebook have addressed
Speaker 1: this issue. And you could go in and change your passwords,
Speaker 1: which I did just before I came in here. Um,
Speaker 1: but yeah, you can. You can activate two factor authentication,
Speaker 1: which requires a secondary uh piece of log in information
Speaker 1: beyond just your user name and password that's generated specifically
Speaker 1: when you try to log in. So usually you get
Speaker 1: like a text message or an email that has a
Speaker 1: numeric code that you have to also enter in ord
Speaker 1: to log in. Once you've cleared a machine, usually it
Speaker 1: stays clear. Sometimes it will expire, which means that eventually
Speaker 1: you'll have to do it again. But as irritating as
Speaker 1: you may find that, it's so much better than knowing
Speaker 1: that your stuff could be open for anyone to see
Speaker 1: at any time. So yeah, this, UM, this was definitely
Speaker 1: a topic that we felt we had to address um
Speaker 1: right away, because it's it's such a fundamental part of
Speaker 1: how the Internet works. I mean, really, the only thing
Speaker 1: that I can think of that would be more monumental
Speaker 1: is if, for some reason uh t c P i
Speaker 1: P protocol stopped working, in which case we wouldn't have
Speaker 1: a job. I just I just had like a like
Speaker 1: a shiver. Um. Yeah, and I mean it's affecting everyone. Yeah,
Speaker 1: I mean everyone. This is across the globe. Um and
Speaker 1: and and it's complicated enough that yeah, yeah, we you know,
Speaker 1: we we really wanted to talk about what SSL does
Speaker 1: and what open ssl particularly does and yeah, so so
Speaker 1: we we We hope that you are at least um
Speaker 1: more comfortable in your knowledge of the doom. It's definitely
Speaker 1: better to know than not know. I mean, it is
Speaker 1: not a happy story by any means. We have top
Speaker 1: men working on it, and women as well, of course,
Speaker 1: But you know, in Indiana Jones's day, they only they
Speaker 1: only acknowledge the men. Well that's yep. Hey, at least
Speaker 1: we don't live in Indiana Jones time. That's that's true.
Speaker 1: I have not had to outrun any boulders in days,
Speaker 1: so that's good. But yeah, this is a This was
Speaker 1: a topic. We thought it was interesting enough and important
Speaker 1: enough that we had to cover it right away. But
Speaker 1: if you guys have suggestions for topics that we should
Speaker 1: cover next, whether it's something that's happened in the news recently,
Speaker 1: or maybe there's that one piece of technology dating back
Speaker 1: to twelve fifty a d that you've always wanted to
Speaker 1: know more about and we're afraid to ask. I'd say
Speaker 1: to you, do not be afraid ask us your silly question,
Speaker 1: because we will give you a silly answer, probably in
Speaker 1: podcast form. But in order to ask that question, you
Speaker 1: need to send us email. It address is tech stuff
Speaker 1: at Discovery dot com. You can also get in touch
Speaker 1: with us via various social media networks. Those are Twitter, Tumbler,
Speaker 1: and Facebook. In all three places, our handle is tech
Speaker 1: Stuff HSW and we will talk to you again. True
Speaker 1: encryption really soon. For more on this and thousands of
Speaker 1: other topics. Does it has stuff works dot com check
Speaker 1: checks