SSL 3.0 co-creator assesses the protocol, Apple's SSL security flawDate: Apr 29, 2014
While the recent Heartbleed OpenSSL vulnerability may have grabbed headlines around the globe, it was hardly the first time a security flaw has been uncovered in an implementation of the Secure Sockets Layer (SSL) protocol. In fact, Apple was forced to release new versions of its iOS and OS X operating systems in February due to an SSL security vulnerability, which, if successfully exploited, would have left SSL and Transport Layer Security connections vulnerable to man-in-the-middle attacks.
"It was a nasty bug of the kind that you might put in if you are trying to be nasty," said Paul Kocher, president and chief scientist at Cryptography Research Inc., a division of Rambus, and SSL 3.0 co-creator.
In this interview, recorded at the 2014 RSA Conference, Kocher discusses Apple's SSL security snafu, including speculation that the gotofail bug may have been planted by the National Security Agency or another government entity. Kocher also revisits the creation of the SSL 3.0 protocol, when he and two Netscape engineers, Phil Karlton and Allen Freier, were rushing to plug the many security holes that riddled the 2.0 version of SSL. Kocher believes that much of the core protocol still stands up today, though he did not anticipate the creation of hundreds of certificate authorities and the associated problems that resulted.
"The fact that we're still using it today I guess means I did something right," said Kocher, "despite the number of emails I get from people complaining about ambiguities in the specs and so forth."
Read the transcript below.
Hi there. I’m Brandan Blevens, with SearchSecurity.com. Thanks for watching this video. Joining me today is Paul Kocher. Paul is Founder and Chief Scientist of Cryptography Research Inc. Paul, it’s great to have you with us today.
Kocher: Thanks for having me.
Paul, it’s been nearly 20 years since you worked on the SSL 3.0 standard. I’d like you to revisit that time period and discuss some of the challenges you were trying to overcome, as well as maybe some of things that you wished you had done better.
Kocher: Got me. Bring out the dirty laundry here. The basic problem that SSL solves, just to bring your readers up to speed here, is to create an encrypted and authentic endpoint between two devices. The most common use case here is you’ve got a PC connection to a web server, and the SSL protocol encrypts the traffic going back and forth and also lets you authenticate that domain name of the server you’re talking to is authentic. That’s a very, very useful building block. This protocol gets used in all kinds of places. Of the things that I view as successful about the protocol, the cleanliness of the design, the lack of extraneous features that you can sit down in an afternoon and read it and understand it, are things that many protocols haven’t done and have generally not been as successful as a consequence.
When I was co-developing SSL 3, there was also in parallel a protocol called SET that was designed for doing payment security. The specifications were just these giant set of books that you could never comprehend, go through, and really gain trust and understanding, and implement. I think that the simplicity is one of the things that I’m proud of having done pretty well. I think of the things that I wish I had thought through better; the Number 1 thing that comes to mind is that I thought there were going to be just 1-2-3, very small number of certification authorities in the system. At that time, VeriSign was pretty much it. It never crossed my mind that you’d have the hundreds and hundreds of CAs that you have today, and just this architecture where your security is the weakest of these many, many CAs, yet you have so many of them; that that leads to all kinds of difficult problems which we’re still struggling with. You’ve got various proposals, like certificate pinning now, to try to stick Band-Aids on the issue. I feel like that’s probably the single greatest problem that, really, I didn’t anticipate when working on the protocol.
We’ve seen a number of attacks on SSL NTLS over the years, including those using certificates like you just mentioned. How do you think that the security mechanism is holding up in the year 2014?
Kocher: The core protocol’s done pretty well; I would give it probably a B+. There’ve been a couple of things that were … needed fixing. There was an error-handling problem that [inaudible: 03:14] identified, there have been a couple of things around padding, some of which were in the original version and some of which were introduced later. Generally, the protocols held up well, though, and there haven’t been the same catastrophic problems that many protocols have had, but it’s needed some updating. There also are better methods now for analyzing protocols and proving their correctness that weren’t available then, and some of them I wasn’t aware of them. There are things, again, I would like to have done better.
A little history here: That project was a crash project. There was an early protocol called SSL 2 that Netscape was using, and attacks against it were the daily fodder for the press. It had a lot of problems with it. It really wasn’t designed to be a long-term solution to a lot of the web security needs that have come along. I got brought into re-architect SSL and produce what was really a new protocol from the ground up, although it addressed the similar problem of connection security. There were a lot of things that I put into there that were relatively new and I don’t think had been done before, like negotiation of algorithms and being able to have strong algorithms and weak ones co-existing, where you got the strongest from the weakest of them. Those capabilities have been really important to the protocol’s success, but it was a rushed job.
As I was working on it, there were 3 of us who were developing it together; 2 Netscape engineers, Phil Carlton and Allen Friar, who were working on both the implementation as well as pieces of protocol, myself doing the crypto and core design work. As we were working on it, the code was being written as the protocol was being developed as it was being reviewed because this was an immediate need that needed to be solved. I wish I could go back and have some more time to have worked on it, explain some things better in the spec, clean some things up, but such as life. You have a critical need to produce something and it goes from there. The fact that we’re still using it today, I guess, means that I did something right despite the number of emails I get about people complaining about ambiguities in the specs and so forth.
Just before we arrived at the 2014 RSA conference, Apple was caught in a bit of an embarrassing episode when it was discovered that a single line of erroneous code in iOS and OSX made SSL and TLS sections vulnerable to man-in-the-middle attacks. Any thoughts on that situation?
Kocher: It’s interesting in a number of ways. It’s interesting because it highlights some of the problems in the C language and the programming languages that we’re using, where this relatively innocuous-looking bug results in a catastrophic failure, and where practices like having indentation that almost all programs use don’t have any syntactic meaning in the language. It also brings up questions about how the vulnerability got there and questions for our compilers. I think one of the areas that a lot of security work needs to be done is around making compilers better, because this situation was one around where you had code that had no effect and was indented in a way that implied a particular intent on the programmer’s part, yet the bug wasn’t creating warnings and failures the way that you might like.
There’s also always the tinfoil hat perspective on this, which is to ask the question of: How did this bug get put in? Was there any malicious intent behind it? I think there’ll be some folks looking at this question right now, as there should be. It was a nasty bug of the kind that you might put in if you were trying to be nasty. That doesn’t mean that it was, because most things that people ascribe to malice are really due to human error in the security space. That said; there’s a lot of malice going around, and perhaps more than we’d realized given the recent NSA revelations and others. I wouldn’t immediately leap to the conclusion, even if it was malicious, that it was NSA; it could well be any country in the world. I think there’s a lot more to be learned about what happened there.
Attackers are always on the lookout for ways to break SSL and TLS, but perhaps a bit ironically, they’re also increasingly using those protocols to hide their own malicious traffic; for example, data being exfiltrated from an enterprise network. What are your thoughts on that end, how enterprises should be defending it?
Kocher: If you’re in enterprise and there’s an encrypted pipe coming out sending data somewhere and you don’t know where it’s going, that is something that you should be paying attention to. From a technology perspective, really, any technology is unaware of what the intent of the humans behind operating it are, whether it be an automobile that might carry you to the grocery store or carry the robber away from a bank. Encryption, likewise, conceals information and it is used for good and for ill. The vast majority is for good, but there certainly are cases where you’ve got cryptology being used like this. We’ve got some malware out there, like Crypto Locker, that’s using cryptology in, really, quite nasty ways. It’s unfortunate, I think, as a whole a society depends on these technologies, though, to protect us from attacks. The conclusion that we should try to prevent the use of cryptology is certainly not the correct one. We do also have to recognize that with all of the benefits that we get, there will always be some problems that come along with them.
Paul Kocher, thanks for joining us today.
Kocher: Thanks for having me.
Thank you for joining us, as well. For more of our videos, please be sure to visit SearchSecurity.com/video.