Wednesday, December 31, 2008

More than one way to skin a CA

Alex Sotirov, Jacob Appelbaum, and crew did some awesome work. They showed that it was possible to exploit RapidSSL's use of MD5 for signing certificates in order to create their own rogue CA signing certificate. This exploitation is many orders of magnitude more severe than when I used a loop hole to get the certificate from Thawte.

So what should happen when a CA screws up? Last summer, folks thought that the CA which issued the certificate should have its status as a trusted CA revoked. I'm sure people feel the same way about RapidSSL. In my opinion, they are correct. However, it is clear that this could not happen, as it would effect the millions of businesses that rely on these CAs being trusted, which is what a VP at Verisign reaffirms in the comments of this post.

A different question that Appelbaum asked during the presentation in Berlin, and one I've asked many times during my research of Certificate Authorities, is: if we were able to do this, how do we know if anybody else has done the same thing?

No one can ever give a straight answer. I've reported a number of flaws to CAs responsibly; flaws that can allow people to get certificates that they shouldn't be allowed to get. The flaws get fixed, and thats great, but the damage that could have already been done is immeasurable.

It sucks when an online retailer gets hacked one or even multiple times. It's bad for them, and it's bad for their customers. When a trusted CA gets hacked, it sucks for the ENTIRE INTERNET. The CAs are supposed to help us secure the Internet. What does it mean if they are not secure themselves? To me, it means that we can't rely on trusted third parties.

I know that abandoning PKI and trusted third parties is a bad idea, and probably won't happen. However, people need to be more involved in the process of making trust decisions when communicating online. And I don't mean little yellow locks and green address bars. I have some ideas on how to make better use of SSL in web browsers and other SSL clients. So far, I've gotten mixed responses to them from my peers :-) However, with what the Sotirov/Applebaum team accomplished, maybe my ideas will make more sense. Stay tuned...

(Cross post on PhishMe)

1 comment:

James said...

For many cases where certs (self-signed or not) are currently used to protect passwords, TLS/SRP RFC 5054 offers a clear solution that avoids having to trust third parties at all.