(spoiler: Here’s the shorter answer: if you use SSL/TLS, you’re probably not using it for the right reasons and you’re probably not getting the level of security you think you’re getting, because you’re probably doing it wrong.)
Ivan’s points boil down to this: SSL/TLS, by itself, is secure. It’s all these implementation details that render it insecure in practice. Ivan then offers eleven areas where SSL is “broken” in practice.
Here’s my issue with the slides: some of them don’t detail problems with SSL at all, and the other half are built into the design of SSL itself.
Let’s go through the slides by point.
Ivan’s first contention is that self-signed certificates are bad. Ivan argues that they’re insecure, they teach users to ignore warnings, and that it’s cheaper to get a “real” certificate than to use a self-signed one anyway.
Well, a self-signed certificate is certainly differently secure than one signed by a root CA, but as to whether or not it’s less secure or insecure, that’s a completely different question (trusted authorities and exploitation scenarios deserve their own post, so I’ll leave it at this for now — edited to add — thank you, Ed Felten, now I don’t need to write this up). The second contention is just silly, users don’t need to be trained to ignore warnings, they do it already. The last is at best incomplete. It requires a certain level of skill to deploy a service that relies upon a self-signed certificate, so saying “you have to maintain it” should be considered as part of the cost is mostly pointless. You have to maintain any certificate, whether you sign it yourself or pay Verisign to sign it for you. If I have to pay Bob the Apache Wizard to maintain my site and Bob knows how to generate a self-signed cert, it’s going to be cheaper for me to have Bob sign the cert than it will be for me to pay Verisign to do it, because Bob is going to get his salary (or his packaged SLA payment) either way.
Ivan’s second contention is that private certificate authorities are bad. The logic follows mostly along the lines of the previous point… it’s better for you to pay someone else to do this for you than it is for you to do it yourself. Now, he has something of a point here. Building a CA isn’t the same as self-signing a certificate, it takes a higher degree of knowledge to build the thing properly. I would imagine that there are a number of CAs out there that are unnecessary and they could be easily covered under one of the existing root CAs. However, there are any number of completely legitimate reasons for running your own CA, and in any event I don’t think one-off CAs represent a big threat to the overall infosec domain.
Points 3, 4, 8, 9, and 10 are all basically the same point: if your site needs to be encrypted some of the time in transmission, it really needs to be encrypted all of the time, period. This is a good point (really should be a single point with examples, though), and I’m more or less with Ivan on this one, although I understand why it isn’t always the case.
Point 7 is that SSL sometimes isn’t used at all when it should be. Not sure why this belongs on the list, that’s not a problem with SSL implementation, per se. And I personally haven’t seen an unencrypted site that handles sensitive data in a long while, so I don’t know how germane it is anymore.
Point 11, and to a lesser extent 5, aren’t so much problems with SSL as they are problems with the couplings between SSL & DNS, pushed through the lens of user expectations. DNS has had its own problems.
Finally, point #6 (using an EV certificate, as opposed to a normal SSL certificate) illustrates the problem I have with computer security engineering professionals.
Now, I haven’t seen the talk and I haven’t read any of Ivan’s blogging (I should, and I’m adding it to my blogroll now), so I can’t say that this is fair, but just reading the slides, here’s how I interpret the underlying context of this talk:
“SSL is totally secure, if you are using it in the totally most secure way and no other way, because we designed it to be totally secure if you use it in the totally most secure way. Oh, but we also made it so that you could use it in all of these other ways, but DON’T DO THAT because you ruin our perfect design by using it in the non-perfect way!”
There’s a reason why I switched my research focus from infosec to disaster/crisis management, and this is it. Information systems security designers have a tendency to draw a box in their head, and design a system that is secure inside that box. If you use the tools they provide within the boundaries of that box, you’re golden, and if you don’t, you’re probably screwed. But that’s not on them because they can only design out to the edges of the box.
The problems with this approach are that most systems don’t fit inside that box, the box itself often sits on top of a completely insecure table, and often the box itself has lots of little holes in it that are punched into it for various reasons.
Ignore those reasons! Don’t use that functionality! It’s bad! But it’s necessary, that’s why we put it in there! But you’re probably not doing it right, and it’s not necessary for you, so just pay someone else to do it!
If setting up your own CA is bad, then why is it good to have multiple root CAs? Shouldn’t there be just one? (no)
If EV certificates are the best, why do CAs offer regular certs? (because)
If using incomplete certs is a problem, then why is it possible to generate an incomplete cert in the first place? (because not all certs are certifying the same thing)
Heck, if self-signed certs are bad, then why do you have the ability to generate them in the first place? (because in most practical cases, you’re looking for session security, not authoritative identification).