Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tue, Aug 30, 2011 at 10:48:11PM +0200, Mike Hommey wrote:
> On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote:
> > On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote:
> > > On Tuesday 30 August 2011 01:08:29 Yves-Alexis Perez wrote:
> > > > On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote:
> > > > > I understand that they'd have to manually load the lists, but perhaps it
> > > > > would make sense to standardize a location from which they should load
> > > > > them? Does OpenSSL or GnuTLS have any concept of a "revocation store"
> > > > > format, similar to a "certificate store", or would this need some
> > > > > special-purpose custom format?
> > >
> > > AFAIR they only know about CRL (Certificate Revocation List,) which only allows
> > > for one issuer per-file.
> > >
> > > What I can't tell for sure from the documentation is whether OpenSSL and
> > > GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like
> > > they do.
> > > This is relevant if we were to ship them in ca-certificates.
> > >
> > >
> > > > And it'd be nice if nss could share that store...
> > > [...]
> > > >
> > > > By the way, shouldn't this bug be clone to libnss3-1d (and maybe
> > > > iceweasel and icedove if they ship the certificates themselves)?
> > >
> > > Perhaps it's time to start a discussion as to how we can properly deal with
> > > all this mess:
> > > * Multiple packages shipping their own certificates list
> > > * Probably no app except web browsers support CRLs and/or OCSP
> > > * configuration
> > >
> > > Yves, do you know how the CRL stuff is handled in nss?
> > >
> >
> > (my first name is Yves-Alexis :)
> >
> > I have no idea.
> >
> > There's a crlutil
> > (http://www.mozilla.org/projects/security/pki/nss/tools/crlutil.html)
> > but it works on previous database version (bdb, cert8.db and key3.db)
> > while at least evolution now uses the shared sqlite db (cert9.db and
> > key4.db, see https://wiki.mozilla.org/NSS_Shared_DB).
>
> The NSS tools are supposed to work with whatever database version you
> use, since they use NSS ;)
>
> That being said, there is a huge problem with mitigation in basically
> all the SSL libraries. There simply is no way to handle the current
> situation[1] without modifying applications.
>
> Mike
>
> 1. Several fraudulent certificates whose fingerprint is unknown signed
> with several different intermediate certs that are cross-signed by other
> "safe" CAs (aiui).
So, I'll put that on tiredness. That'd be several fraudulent
certificates which fingerprint is unknown (thus even CRL, OCSP and
blacklists can't do anything), and the mitigation involves several
different intermediate certs that are cross-signed, which makes it kind
of hard. Plus, there is the problem that untrusting the DigiNotar root
untrusts a separate PKI used by the Dutch government.
Add to the above that untrusting a root still allows users to override
in applications, and we have no central way to not allow that. Aiui, the
mozilla update is going to block overrides as well, but that involves
the application side. NSS won't deal with that.
Mike
Reply to: