Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote:
> 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.
See https://bugzilla.mozilla.org/show_bug.cgi?id=682927 which is now
open.
Mike
Reply to: