«Transcript of Episode #478 Page 1 of 18 Transcript of Episode #478 Poodle Bites Description: After catching up with a few interesting events from the ...»
Steve: Anyway, that's pretty much all of our news for the week. I did want to just sort of
- I noted over the last couple weeks that I was getting many more sets of four yabbadabba-dos. And I had noted over the summer that that seemed to have sort of disappeared. And of course the difference is an individual license for SpinRite generates a single yabba-dabba-do when a purchaser obtains a license.
And the way we operate is that corporations can get a license for all of the machines in a Security Now! Transcript of Episode #478 Page 7 of 18 single physical site, like whatever, regardless of how large the site is, by having four licenses. And that just seemed, when I was coming up with the policy, a much simpler way of organizing things because I thought someone might want to try it and see if it works, and then they would have bought a license for one. So then if they wanted a site license, you have to have some sort of a site license for people who already owned one, or refund their purchase and then issue them a site license, and it just seemed like a mess. And so I liked the idea of just having X number of regular licenses.
And then it also kind of was really cool with upgrades because if we then had a paid-for upgrade, then they could upgrade their site license by upgrading their individual licenses.
Anyway, just so the idea is that when I hear four yabba-dabba-dos, somebody purchased a four-license site license. And for whatever reason, in the last couple weeks, there have been, like, they've come back.
So I just wanted to thank people because - actually one of my favorites is when I hear three because that means that someone got one, they checked it out, and then they said, okay, we want to - this thing works. We want to use it sitewide. And then they bought three more in order to have a total of four licenses and then have permission to run it on all of their machines within a facility. So anyway, thank you. I really appreciate that. That keeps the wheels turning here over at GRC and lets me do everything else I do.
Leo: Did you - I guess you explained why yabba-dabba-do and all of that. We don't hear it anymore, right, because you turn it off during the show. Every once in a while it will be on by accident.
Steve: Yeah. I mute it because it's a little distracting. But it was just - what I have is I have a system that sort of monitors the GRC servers. It's sort of like my custom version of the advertiser you just introduced us to.
Steve: So, and for example, there was a time when we were under denial-of-service attacks, more or less annoyingly frequently. And so I built a sort of a real-time bandwidth monitor and server monitor that watches all of the things, the processes and servers in our offsite facility at Level 3. And among other things, it - and it's very cool. It uses UDP.
It's all custom stuff that I built. And so I'm behind multiple layers of NAT, and so nothing can get in here. But UDP, as we know, is able to return up the path that it exited.
So my system here sends out a UDP query every second or two, actually I think it's every two seconds. It sends out a UDP query just asking for an update. And that maps through all of the security that surrounds the Fortress of Solitude and Research so that the server, when it receives a query, or the system at GRC, when it receives a query, it assembles a current state and then returns a UDP reply, which UDP doesn't really expect one. It's just the idea is it might get one. But the NAT routers have like been opened by Security Now! Transcript of Episode #478 Page 8 of 18 the outgoing query. And so the servers send back a "here's where everything stands" reply.
One of the things in there is the total of SpinRite sales. And so at this end I look to see if there's been any change. And if there is, I divide that by the cost of SpinRite, which tells me how many licenses sold, and I emit that many yabba-dabba-do WAV files.
Leo: So it's modulus SpinRite cost.
Steve: It's modulus SpinRite licenses, yes.
Leo: Oh, I love it. I think we assume that everybody who listens over the years has learned this. But, you know, people still come in the chatroom and say, "What are those lights blinking over Steve's left shoulder?" So we have to assume that there are people here who are not...
Steve: What's Fred Flintstone doing in the background?
Leo:...hip to the lore of the Fortress of Solitude.
Steve: Yeah, exactly.
Steve: But I think everyone's going to enjoy this. Okay. So once again the industry suffered another shock. Much like Heartbleed and - why can't I remember the name? Shellshock.
Leo: Shellshock. You're blanking it out.
Steve: I am. So this was - okay. And the headlines all were hyperventilating, and people were making sure on Twitter that I had seen this, and I knew what was going on. And the scary headline title is that there's a new problem with secure connections involving a means of making browsers and servers use SSL v3, and then leveraging a vulnerability in that in order to crack the security of SSL v3.
test to allow anyone to check. I started getting people saying, [gasp], "Oh, Steve, GRC is vulnerable." And it's like, okay, everybody. First of all, GRC is not vulnerable. Never has been a problem. I'll explain that at the end of the podcast, why this is not, I mean, independent of this, why it's not a concern for the way I implemented things.
But so here's the story. Here is exactly what's going on and why, despite all of this, and the fact that none of that is wrong, it's actually not a problem. The fact, well, I don't want to step on myself, so I'll take us through this. So what's going on? As we know, SSL has had problems through time. It was originally created by well-meaning smart guys at Netscape in order to create a secure link between browsers and servers so that we could do things like have usernames and passwords and cookies that were not in the clear, because before that everything was in the clear. It was like email is pretty much today.
Just there, there go the bytes. If you're sniffing the wire, you can see them go by.
So SSL of course started off at 1.0 and has been incrementing sort of slowly and in various amounts over time as problems have been found and fixed. And we finally got up to the point where we were ready to go to 3.0, and someone decided, let's change the name. And it's like, oh, really? Okay, fine. And that decision never comes off very well.
And in fact that's been a problem because we have SSL v3.0, and then TLS v1.0. But TLS v1.0 is newer than SSL v3.0. So not only did we change the name, but we reset the version number. And so that confuses people.
But then we've moved with TLS. SSL was Secure Socket Layer, that's what the acronym SSL stands for, because in UNIX world, UNIX thinks in terms of communication sockets.
That's the name of the abstraction for communicating between two endpoints on the Internet. You create a socket, and then you connect to another socket on a different machine, and then they talk to each other. So Secure Socket Layer is SSL. TLS is Transport Layer Security. So we have a new acronym for the same thing, just a newer version of the same thing.
Steve: Acronym Soup.
Leo: Yes. Really we should do that. It'd be a good thing to do, like just give people acronyms and say, "Can you define this?" Because it's crazy.
Steve: You know, I'll bet it would be possible to do an entire podcast where you simply bring...
Steve:...and so forth, yeah.
Leo: You could, definitely.
Steve: So, and actually having listened to Andy Ihnatko on MacBreak Weekly talk about how he wants to use NASA portable audio...
Leo: As his ringtone, as his ringtone.
Steve: It's like, have you ever heard of anything more geeky? I mean...
Steve: So, okay. So TLS is where we are now. And we went, of course, we started at 1.0, 1.1. We're now at 1.2. So there's always a problem as we are moving standards forward with systems that aren't advancing. And it's, like, not good not to advance, but it's the reality. So it turned out, when we moved forward to TLS, and clients, that is, users with Windows, Linux, and Mac, and smartphones and so forth, had clients that were initiating state-of-the-art, modern, recently updated, refreshed connections. They would connect to a server and say, "Hi there. I know about TLS 1.1." Because 1.2 is really very much newer. So probably 1.1. Maybe, well, certainly 1.2 now. And there were some servers that said, "Huh?" And hung up.
Again, if everything worked smoothly, there's supposed to be like a version protocol handshake. And we've discussed how SSL negotiates. The idea is that both ends of a connection advertise the highest level of the protocol that they're aware of, and they agree on the highest level they both speak. So that happens on a monotonic scale in terms of versioning. But then the client may have a different set of ciphers that it knows about. So it sends a list of all the ones it knows about to the server. And then the server browses through those and chooses, in some order, hopefully from strongest to least strong, the ones that it knows about, that it has in common. And then they agree.
So, and that's a neat theory. But it has been subject in the past to so-called "protocol downgrade attacks," various ways, I mean, again, bad guys are clever. And as we know, they only get cleverer. So we need to protect ourselves against a bad guy coming in, well, I mean, a classic one in the early days, there was actually a null cipher that was in the set of ciphers because the original engineers of SSL said, hey, you know, what if Security Now! Transcript of Episode #478 Page 11 of 18 something - if you're trying to connect to a skate key or something, I mean, that has no crypto whatsoever? So maybe we should allow that. And so you could actually say, I would like to talk to you over SSL, but I don't have any ciphers. And the other end would say, oh, shoot. Well, okay. And so you'd have an SSL communication with no encryption, which really sort of defeated the whole purpose.
Steve: Socket layer, but no secure socket layer. So, okay. So when we realized, we the industry, that there were lame servers that were confused if we even mentioned TLS we'd say "TLS," and they'd just hang up. It's like, ooh, okay, I guess not. So browsers learned to, if they got hung up on when they offered TLS, to try SSL. And if they knew about TLS, they certainly knew about SSL3 because that was the end of the line of the SSL acronym. So they'd say, how about SSL3? And at least it was SSL. So then the server would go, oh, okay, yeah, fine. What have you got? And we'd go from there.
So the problem with that is that that opens us to a version downgrade. That is, if - and this is an "if" we'll be coming back to several times. If an attacker managed to get into the connection, the classic man in the middle - now, in this case, it's not just an eavesdropping connection, that is, not a passive man in the middle who can monitor, like we now know the NSA likes to do. This is an active man in the middle which is, again, it's another escalation in attack requirement where somehow the victim's client traffic is passing through the attacker, who is able to change it.
And in the initial packets, which are going back and forth during this negotiation, there have been weaknesses in the past which TLS further strengthens. But in this case all the attacker has to do is force an error, which is trivial. It's hard, actually, you've got to balance checksums and do all kinds of things, not to have an error. But all the attacker does is lead the browser to believe that they are trying to connect to one of these lame servers. And so the client will go, oh, I guess no TLS here. Fine, we'll use SSL3.
So the stage-setting portion of this is that we are, today, are subject to this protocol downgrade where a bad guy convinces the browser that the server can't do TLS. So now we do SSL3. And so the first part of this is that we're forced onto SSL3 from an active man-in-the-middle attack. Now we have SSL3 problems which we had deliberately gotten away from, moving to TLS. And SSL3 has a choice of basically two ciphers. It can use RC4 or CBC. And we've talked about both in the past. I'll give a quick review.
like, basically two vectors. Or, no, I'm sorry, one vector. It's two pointers. One vector, one table of 256 one-byte entries, and two pointers into the table. And basically, when you give it the key, it scrambles the initial starting conditions into something which is based on the key. And then, as you run the cipher, it continues to basically swap bytes in the table and, at the same time, emit pseudorandom data. And you could almost imagine how, if the table wasn't really scrambled up well, then the bytes coming out wouldn't be that random.
And that's precisely the problem. If the designers had just warmed it up more, if they'd, like, run it for 256 extra bytes, then the table would have always been sufficiently scrambled that it wouldn't have been a problem. But the weakness turned out to be that the first data being emitted by the RC4 cipher, which is then XORed with the user's plaintext to create ciphertext, it wasn't as random as we needed. And in fact, even more recently, detailed additional analysis showed that it's worse than we thought. So RC4 is out. No one likes it anymore. We hope no one's using it anymore. Not only was it used, of course, famously in SSL, but even more famously in the original WiFi protocol, WEP, which is where we really saw it collapse.
Okay. So the better cipher, although not without its own problems, is CBC, which is an acronym for Cipher Block Chaining. CBC takes the data in blocks of bytes where the size of the block is the size of the cipher's block. So let me just say to remind people that RC4 is a stream cipher, meaning that it emits a stream of bytes which are unpredictable, and so you XOR those bytes with your data to get your data encrypted. And then on the other end you give it the same key. It generates the same stream of pseudorandom key-based bytes, which are unpredictable. You XOR those with the ciphertext, and out pops the original plaintext. So very neat and elegant.