My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

DigiNotar SSL Breach

Published: 2011-08-30. Last Updated: 2011-08-30 14:56:16 UTC
by Johannes Ullrich (Version: 1)
9 comment(s)

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.

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: ssl
9 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

"One possibility is to remove the DigiNotar CA from the list of trusted CAs."

Will that even work with IE? I read somewhere that if a CA root is missing that IE will silently download and install it if it's on Microsoft's OK list.
Surely even if you use DNSSEC, if it is a country level intercept, presumably using transparent interception techniques rather than DNS spoofing, the only line of defense you have is the SSL certificate?

DNSSEC only really says "for this hostname contact this IP". If you contact the IP, but the packets are transparently intercepted and redirected to a proxy with the correct cert information, you're still screwed.

RFC 4255 specifies a way to put SSH host key hashes into DNS to prevent interception issues, but I haven't been able to find a similar way of putting SSL key hashes into DNS, which in combination with DNSSEC would be further along the path to ensuring end-to-end security. I'm sure people will find a way around even that however :(
As far as removing from wide-scale Windows deployments goes, you could just push a powershell script to remove it. The one here (In the comments) http://technet.microsoft.com/en-us/library/dd347615.aspx.

Could be modified like this:
# delete certificate
$store = new-object system.security.cryptography.x509certificates.x509Store 'Root', 'LocalMachine'
$store.Open('ReadWrite')
$certs = @(dir cert:\localmachine\root | ? { $_.Subject -like '*diginotar*' })
foreach ($cert in $certs) {$store.Remove($cert)}
$store.close()

Fire that off via advertisement in SCCM every hour or so in case it gets readded before the patch comes out.

Again, this doesn't really help. All it will do is drop the users to the IE warning page, but if we educate users to think before they click, or at least warn them that if they hit it, to be careful, I think we'll be ok.
I've been trying out the CertificatePatrol addon for Firefox, which behaves similarly to OpenSSH's 'known hosts' feature: It presents small notifications when it sees a new certificate, small notifications when it changes for good reasons (i.e. it was about to expire) and big warning dialog box for suspicious changes. It's been ok but I do get the occasional false warning due to what I assume is simply poorly implemented load-balancing. It's definitely not appropriate for end-users, since it's far too technical at the moment, and warnings are generally false alarms.

The other major alternative is the Perspectives firefox addon: http://perspectives-project.org/. It has 'notaries' that view the same site from different locations on the web and check to see if the certificate is the same. I plan to be trying it soon.

In the medium-term, some combination of the two approaches above would work. In the long term the solution is to overhaul SSL in some way. One idea I heard is to allow a certificate to be signed by multiple CAs, indicating different levels of security: Major companies such as banks or Google should be using 3 or more, whereas my random web forum doesn't really need more than one.
Is there a way to write a snort rule around this?
Microsoft has removed the certificate from the list of trusted certs. It will not be re-added once deleted: http://www.microsoft.com/technet/security/advisory/2607712.mspx
"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."


Instead of "deleting" the certificate, disable all usages of the cert / trust of the cert.


Ensure your organization uses group policy to prevent users from bypassing certificate warnings on users' browser.

I too have noticed increase port prob activity from China.
El Reg is noting that this just got a LOT bigger.

"...breach affected Mozilla [addons] and at least four other organizations. Fraudulent certificates for Yahoo.com, the Tor Project, WordPress and the Baladin blogging service"

http://www.theregister.co.uk/2011/08/31/more_site_certificates_forged/

Diary Archives