Quo vadis Certificate Authorities?

I’m sure you’ve heard about DigiNotar compromize (e.g. here http://www.theregister.co.uk/2011/08/29/fraudulent_google_ssl_certificate/) where DigiNotar (a subsidiary of Vasco) signed a certificate for “*.google.com” to someone who isn’t google. We’ve seen this before with another well known Certificate Authority Comodo where one of their resellers got hacked which resulted in 9 certificates to be issued fraudulently (http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html)

Fraudulent certificate

“real” google certificate

 

Well, the certificate was issued on July 11, 2011 and exactly 7 weeks after issuance it is now revoked and all browser vendors even got rid of the CA altogether with a client update (!)

I’ve been involved with SSL and certificates for the last 11 years and frankly it has been a mess for the most of these 11 years.

• We’ve seen incidents where a financial institution “forgot” to renew its certificate and only 1 in 200 (that is 0.5%) customers denied the connection.
• We’ve seen the list of Certificate Authorities growing and growing and when the system almost broke down, the EV-SSL certificates were “invented”. Basically along the lines of “hey, the system is broken. Let’s not fix it, let’s just charge more”.
• We’ve seen many, many browser flaws that wouldn’t properly validate the certificate, allowing the use invalid certificate for well known sites without a browser warning.
• The revocation system is broken at best, simply unusable at worst.
• On the malware front, more and more trojans use HTTPS (even with valid certificates) for the C&C communication.
• Most modern MITB trojans have to use real HTTPS certificates for injecting malicious JavaScript and other content into a legitimate bank website. We have seen with every decent attack, such as Gozi, Carberp

Apparently a new Browser feature in the google Chrome browser alerted the user of this fraudulent certificate. The feature is that only a very small subset of CA’s are allowed to vouch for Gmail (see http://blog.chromium.org/2011/06/new-chromium-security-features-june.html). Did I read right? Chrome has hardcoded CA’s that override the default behaviour? That can’t seriously be the right solution going forward.

This reminds me of an initiative of “Safe Webbrowsing” from the FSTC a couple years ago where the idea was to switch to a “banking mode” in your browser which would limit the CA’s and only allow certain CA’s. Goes in the right direction, but is still based on CA’s.

So what’s the solution?

Unfortunately that’s not the easiest question to answer as it has to do with trust in the internet. SSL was always designed for encryption and authentication. While in the beginning the encryption part got most of the attention, the authentication part is actually at least equally important. It proves to users who they are talking to. In a world of explosive growth rates in eCommerce, the consumer needs to be sure that the site he’s looking at is the right site. If we can’t guarantee that, trust is gone…

We know that the hierarchical trust structure from the CA’s won’t solve the problem – regardless how much one pays for a certificate.

In fact it even solves the wrong problem. What a consumer wants to know whether he is at the right page and NOT if the certificate was signed by some CA, is not expired and the URL matches the CommonName of the certificate.

Maybe if we could relate a particular webservice to one or many SSL certificates, that would make a big difference to the trust model? How cool would it be if I go to (say) www.citibank.com and I would know that the SSL certificates that I’m about to encounter are all owned by Citibank and are actually used for the banking session?

As a matter of fact, TrustDefender realized this a long time ago and their concept of  “Client Policies” provides exactly that relationship for enterprise customers of ours. This enables TrustDefender to “distinguish” internet requests that belong to the current banking session from other completely irrelevant connections (such as malicious C&C server communication).

How would this have solved this incident?

Well, because all SSL certificates are part of these Client Policies, the fraudulent one from above wouldn’t be in there and from the very first second it would have been detected.

Regardless of what technology will be employed. We need to do something different.