Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Thu, Sep 01, 2011 at 02:06:39PM -0500, Raphael Geissert wrote:
> 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?
There is.
> > 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.
Me too. It looks like some part of the blacklisting must be working, and
the blacklisting is responsible for Staat der Nederlanden Root CA being
affected, because their chain of trust involve a cert that happen to
contain DigiNotar in its name. (PKIoverheid) Sorry for the confusion,
this whole thing is such a mess.
> > > 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
AIUI, the DigiNotar Public CA 2025 is cross signed by Entrust.
> > 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.
Latest chromium does it too.
> 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.
The last one should be handled by the removal of the Entrust roots that
signed DigiNoTar intermediate certs.
Entrust actually requested the removal of these roots, as well as
published revocations (which is why OCSP and CRL validation works)
See https://bugzilla.mozilla.org/show_bug.cgi?id=683455
Mike
Reply to: