Last Updated: 2011-08-30 14:56:16 UTC
by Johannes Ullrich (Version: 1)
You probably heard about the breach of the DigiNotar SSL certificate authority by now. In the process, a fraudulent certificate was issued for *.google.com and there is some evidence that the certificate was used to intercept traffic from Iran.
The reason we haven't really written about this so far is that we are somewhat struggling with the advice we should give you.
First of all: The SSL "race to the bottom" CA model is broken. Fraudulent certificates have been issues before, even without breaching a CA's systems.
But what can you do to replace or re-enforce SSL? Lots go over some of the options:
One possibility is to remove the DigiNotar CA from the list of trusted CAs. The problem with this approach is that now legitimate certificates, signed by DigiNotar, will no longer validate. The last thing you want to do IMHO is to get users accustomed to bypassing these warnings. I am not sure how popular DigiNotar is, so maybe it is an option in this case.
Certificate revocation lists are supposed to solve this problem. But they are not always reliable. However, for high profile breaches like this one, expect a browser patch that adds the certificate to a blocklist. Apply the patch as it becomes available.
Use DNSSEC. DNSSEC provides an alternative means to validate that you are connecting to the correct site. It is not perfect either, but somewhat complimentary to SSL and the two together provide some meaningful protect. Sadly, it is not up to you to enable DNSSEC on most sites you connect to.
There are a number of browser plugins that implement reputation systems. I am not sure how well they work. They are pretty new. One that gained some traction is Convergence, which will compare the certificate you received with certificates others received from the same site. How well this works (in particular: false positives...) will yet need to be shown.