Father of SSL says despite attacks, the security linchpin has lots of life left
If properly upgraded automatically when issues come up, the protocol is still useful
By Tim Greene | Network World US | Published: 15:58, 12 October 2011
SSL/TLS, the protocol that protects security of e-commerce, has taken a beating lately, with news items ranging from the violation of certificate authorities to the discovery of an exploit that beats the protocol itself.
With all the noise about SSL/TLS it's easy to think that something is irreparably damaged and perhaps it's time to look for something else.
But despite the exploit - Browser Exploit Against SSL/TLS (BEAST) - and the failures of certificate authorities such as Comodo and DigiNotar that are supposed to authenticate users, the protocol has a lot of life left in it if properly upgraded as it becomes necessary, says Taher Elgamal, CTO of Axway and one of the creators of SSL.
Related Articles on Techworld
The problem lies not in the SSL/TLS itself but in the trust framework built around it and the problems that causes when it comes time to patch the protocol to fix vulnerabilities. Network World Senior Editor Tim Greene spoke recently about these issues with Elgamal. Here is an edited transcript of that conversation.
The flaw exploited by BEAST has been around since 2004. What's up with that?
Taher Elgamal: The problem is complex. It started with, yeah there is a weakness in the security protocol and we ought to recognise that and we have to go update it and fix it. That was before the whole BEAST thing - the practical attack, so to speak.
All the different browsers in the world are using TLS which is known to have that weakness. It's important to understand what that attack really is.
The way the BEAST thing's deployed is you have to have a piece of malware on the browser that can inject certain things to force the browser to produce cookies so that these cookies are passed into the channel. Then they have to have a man-in-the-middle point that allows them to actually get the encrypted data. So you have what is called a chosen plaintext attack - you choose the plaintext and you read the ciphertext and you try to match these up and find out what the keys are. It's very, very clever. There's no question about it.
Now, from a practical standpoint, the real problem is you have to have malware on the machine. Honestly, if I can put malware on your machine, I'm not going to be bothering with your SSL because I can see all the data before it gets encrypted.
It became very public because there are some 2 billion browsers and all of them use SSL for one thing or another and all e-commerce uses it and we should be careful. But obviously if you have a protocol that does not have any security problems - that does not exist.
So on the one hand you have a bunch of smart guys who did a very clever thing. It is clever and it uses a known vulnerability and it shows what you can do with these things. On the other hand, the real issue is Windows is a really terrible operating system - what can you say. It's pretty amenable to malware that can redirect stuff. It's a combination of a lot of things.
What's the practical step to take? Go to TLS 1.1?
TE: Unfortunately no. That is the problem. The browsers still do not support TLS 1.1. That is actually the real problem. TLS 1.1 is more than two years old. It's not like it came out last week.
What can a corporate user do about the problem?
TE: You have to watch out for malware. What can I say? You should watch out for it in any case. Make sure you're running your machine in a good state, and you're running a/v and that kind of stuff, anti-malware spotting things - which you do in any case. If you've got malware on your machine somebody's reading your data regardless of SSL.
Are there downsides to TLS 1.1?
TE: Not that is known today, but the issue with security is that as human beings we all want something that is secure forever. We want to feel safe about it and move onto the next thing, and unfortunately that is the wrong thing to do because security is always relative to something or another. Ten years from now computers will be a lot faster so today's safe things may not be safe, and we will be doing exactly the same thing again. It's not because it's bad or good and doesn't have anything to do with a particular setup or protocol or operating system. It's just the truth of the matter, since we have to always look out for these things. We have to monitor for what the weaknesses are. We have to update things. This continues to happen basically forever and ever. There's honestly no one-time solution to this issue. It has nothing to do with SSL in particular. SSL becomes the poster child for this because SSL is being used in all of e-commerce. Replacing SSL by itself as a protocol doesn't solve any problem.
How about those certificate authority breaches against Comodo and that wiped out DigiNotar?
TE: It's a combination of PKI and trust models and all that kind of stuff. If there is a business in the world that I can go to and get a digital certificate that says my name is Tim Greene then that business is broken, because I'm not Tim Greene, but I've got a certificate that says this is my name. This is a broken process in the sense that we allowed a business that is broken to get into a trusted circle. The reality is there will always be crooks, somebody will always want to make money in the wrong way. It will continue to happen until the end of time.
Is there a better way than certificate authorities?
TE: The fact that browsers were designed with built-in root keys is unfortunate. That is the wrong thing, but it's very difficult to change that. We should have separated who is trusted from the vendor. If we cannot separate the root of trust from the vendor then the best we can do is build a side reputation system that everybody consults. When a browser gets a certificate from an unknown CA it says what the heck is this? Tell me if the reputation of this thing is OK, and if it is OK, it's fine. And if that particular CA is doing bad things its reputation will go down and the browser should actually refuse the connection. We want the consumer to get ease of access a lot more than we want to protect them. So we allow the consumer to trust random things. After somebody trusts something it's very difficult for them to untrust it in the current setup. So the browser guys needed to undo things. This is unfortunate but it only has to do with the way the PKI was implemented inside of the browser system rather than any particular protocol. You could have removed SSL and put in IPSec and the exact same problem would actually come out because they all use PKI.
What can be done?
TE: If there is a way that we can separate who we trust from the vendor of the browsers then that would be the best thing to do. And the root of the trust should be the Internet with its built-in reputation ecosystem. All the CAs will have reputations built in because that's how the Internet runs, and then you have a better trust model that way. Rather than build it into the browser itself, that's what I'm saying. And I'm not saying I know how to implement this, but it's a better model.
If that were to happen and people have noticed that a particular CA is issuing bad certs the reputation will kick it out immediately. Nobody will have to issue patches, we don't have to wait for somebody to send something over for us to update. It will just be done in the ecosystem.
How would that work?
TE: We have to build a mechanism to automatically update things. We did not do that. The right way to design, if we were to update things an updating protocol that automatically updates itself so when the next version comes up it knows where to find the next version rather than having to wait for a Windows update or whatever. I think there is technology that is known to the world to do that. And I hope people look for these things because honestly, every protocol will have roles for self-updating things. Nothing will remain secure forever. It's a bad idea actually to shoot for something that will be secure forever because we won't find any.
Do you see a way automatic updating could take place with SSL/TLS?
TE: I think it's not just TLS, I think it's the self-updating thing in general. It's a good idea, right?
Are you working on that?
TE: Am I working on that? No. It's something that exists but I'm not actually working on it.
What do you know about what's being worked on?
TE: The beauty of living in Silicon Valley is that you talk to people every day, and people tell you interesting ideas. I'm not sure I'm allowed to say. People have approached me with some ideas of that type.