[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 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).



Reply to: