[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA



On Thursday 01 September 2011 01:37:01 Mike Hommey wrote:
> On Wed, Aug 31, 2011 at 11:02:53PM -0500, Raphael Geissert wrote:
> Well, reality is that the Firefox 6.0.1 release, which has a white least
> for Staat der Nederlanden Root CA but not Staat der Nederlanden Root CA
> - G2, effectively prevents from going to a couple of dutch government
> sites.

Do you know if there's any plan to whitelist the G2 CA?

> Considering it has been found that the PSM side blacklist doesn't work,
> that suggests that the root CA removal alone is responsible for the
> situation, but I could be wrong.

That's what I also understood from the bug report, but it puzzles me. How does 
the removal of DigiNotar Root CA affects Staat der Nederlanden Root CA?
I must have missunderstood the message.

> > Action items based on what others are doing:
> > 1. Disable DigiNotar Root CA: done
> > 2. Disable other DigiNotar CAs (derived from Entrust)[4]: not done
> 
> There are 3 of them iirc.
> 
> > 3. Still permit Staat der Nederlanden CA and PKIoverheid: nothing to be
> > done
> > 
> > Item 2 is handled by Mozilla by matching /^DigiNotar/ and marking them as
> > untrusted at the PMS level.
> 
> And that currently doesn't work. It seems reasonable to wait for a more
> correct fix there before uploading ice*. There may be another nss round
> before that, though, for the Entrust certs. Please also note that Kai
> Engert is going to work on a NSS patch to handle the whole think at NSS
> level which would port what PSM does for SSL to S/MIME and other uses of
> NSS. I'm not sure this will be easily backportable, though.


On Thursday 01 September 2011 04:12:44 Mike Hommey wrote:
> I did some actual testing. With the DigiNoTar Root CA removal, we
> don't block Staat der Nederlanden Root CA and Staat der Nederlanden Root
> CA - G2. We also don't block (obviously) the ones with intermediate
> certs signed by Entrust, and if I followed the story correctly, this
> means we're effectively *not* preventing the *.google.com,
> addons.mozilla.org, *.yahoo.com, etc. fraudulent certificates from being
> used.

Unless other certificates were signed with another CA, at least the 
*.google.com one should fail now. The chain of the the public *.google.com 
cert is:

Issuer: C=NL, O=DigiNotar, CN=DigiNotar Root CA
Subject: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025

Issuer: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025
Subject: C=US, O=Google Inc, L=Mountain View/serialNumber=PK000229200002, 
CN=*.google.com

> A few urls to test:
> https://www.diginotar.nl should be blocked, and is -> OK
> https://sha2.diginotar.nl should not be blocked, and isn't -> OK
> https://zga-tag.zorggroep-almere.nl should be blocked, and isn't -> BAD

The last one is atm only blocked if the user has a CRL-enabled system (KDE + 
kleopatra, or similar,) or OCSP validation enabled.

I have an idea, but I need to test a few things first. It is too simple, so I 
guess I must be missing something, otherwise people would have already done 
it.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



Reply to: