MD5, SSL, CAs etc.: Summary opinion

In the past few posts (this one, this one and this one) I've tried mostly to lay out the facts as I understood them. But this story is prominent enough that everyone seems to have an opinion on it. So here's mine, keeping in mind that when I'm not busy not being a security expert, I spend my spare time not being a lawyer.

First, the CAs [that is, the ones that persisted in using MD5] clearly deserve a good dose of public humiliation on this one, if only to remind everyone that bad press and possible loss of sales are an additional cost of not acting, even if no actual exploit occurs. They deserve it not because a weakness turned up -- that's pretty much inevitable -- or because they don't always respond to every conceivable threat -- that's a natural consequence of doing business and weighing costs against benefits. They deserve it because in this particular case the threat was clearly large, the fix was clearly not that hard and they had years of lead time to fix things quietly.

Verisign in particular argues that RapidSSL was an acquisition and they were just now able to get to know RapidSSL's code base. Well yeah, but ... Verisign chose to acquire RapidSSL and it would have taken very little due diligence to determine that they were using weak certificates. Depending on their negotiating position, Verisign might even have been able to make RapidSSL's fixing its certs a condition of the acquisition. But in any case, it's a problem Verisign took on voluntarily, and if they didn't know about it they should have.

However ...

It would be a grave mistake to focus completely on the CAs. When you (say) visit your bank's web site, you are trusting

• The bank to keep your money safe to the best of its ability.
• The bank to keep your private info safe to the best of its ability.
• The banking system and government to clean up if the bank fails. [When I wrote this, I was thinking more of a security breach. Heh.]
  

And on the technical side:

• The CAs signing your bank's certificate
• The design of the certificate system (PKI)
• The researchers that claim all this works they way they say it does
  
• The implementation of SSL you're using
• DNS (the system that figures out which actual server to contact when you ask for "foobank.com").
• Your browser
• Your operating system (a whole separate kettle o' fish)
• Whatever else I didn't think of, and I'm sure I've left out several major factors.

Any of these can and does have problems from time to time. However, you're not counting on all of them to be perfect, always. You're counting on the system, in aggregate, to be safe enough. The wrong lesson to learn from all of this would be "The CAs are too lazy to protect our data". A better lesson would be "Every part of the system is imperfect. And so is the system. That's probably OK, but we really don't know."

Not exactly a reassuring story with clear good guys and bad guys, but it's the best I can come up with.