Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
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
> 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 without modifying applications.
1. Several fraudulent certificates whose fingerprint is unknown signed
with several different intermediate certs that are cross-signed by other
"safe" CAs (aiui).