The Baby and the Bathwater, SSL cert edition

Posted by:

admin 13 years, 9 months ago

Background:  Comodo, the SSL certificate authority was attacked and fraudulent certificates for a number of high-value sites were issued.  Sites like mail.google.com, login.skype.com etc.  as well as addons.mozilla.org. 

We've known for a long time that the Certificate Authority/Browser trust model is completely broken, filled with externalities and conflicting incentives.  We've long theorized that an attack against a Certificate Authority and now here it is.   Comodo released an incident report on it. Now, you might expect me to post a rant about the  blog post where they stated: 

The attacker used the username and password to login to the particular Comodo RA account and effect the fraudulent issue of the certificates.

But, actually, this will not be about how CAs and their partners should use stronger forms of authentication, because there is no way that will occur in any time frame that would benefit enterprise users of certificates.  Rather, this is a call for a rational reaction.  While Comodo would have you believe that this was a state-sponsored attack by Iran (who then decided not to bother hiding their IP address), it is also likely that the attacker was trying to gather credentials for Google, Yahoo and Microsoft Live that could then be used to attack enterprises.

Many enterprises rely on SSL now for VPN access that it is not going away anytime soon.  SSL as a tunnel encryption mechanism works. What doesn't work is: 1.The Certificate Authority system, as proven by the Comodo attack and Moxie Marlinspike's SSLStrip and 2.  The reliance on users to make decisions about the validity of certificates.

This is where mutual authentication comes in.  Mutual authentication or mutual https authentication means that the SSL server is strongly authenticated to the user.  Strongly means cryptographically, not photographically.  WiKID's PC tokens can do this by downloading a hash of the targeted site's SSL certificate when it gets the one-time passcode from the WiKID server.  Then, before the OTP is presented to the user, the token goes to the targeted site, grabs the cert, hashes it and compares that hash to the one downloaded from the server. If they match, the OTP is presented with the URL and the default browser is launched to the site. 

This process is simply an evaluation of whether the certificate has changed from when it was loaded into the server without the need for the user to do so.  There are other ways for the to happen, certainly and it's time that enterprises investigate and consider implementing additional https security mechanisms.  The key is to eliminate the need for the chain of trust.

Anther option (perhaps more suited to consumers) is to install a browser plugin that notifies you if the cert has changed, such as Certificate Patrol.  (Note that addons.mozilla.org was one of the compromised certificates.)  Plugins like this still require the user to approve the change in certificate, which is cause for concern. Share on Twitter Share on Facebook

• ← My not-about RSA blog post
• Adding two-factor authentication to (web) applications →