Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Wed, Sep 07, 2011 at 10:57:51AM -0500, Raphael Geissert wrote:
> [Kurt, please CC me on your replies. The BTS' -subscribe functionality doesn't
> seem to be working]
> [CC'ing ubuntu sec, in case Kees or Jamie or whoever is taking care of the
> issue is also working on something to completely block DigiNotar]
>
> On Monday 05 September 2011 14:55:50 Kurt Roeckx wrote:
> > On Mon, Sep 05, 2011 at 02:15:31PM -0500, Raphael Geissert wrote:
> > > The only currently supported methods are OCSP and CRL, but none would do
> > > the trick in this case.
> >
> > I guess OCSP/CRL is only called for the top most certificate, and all
> > the CAs in the chain aren't checked in most applications. I thought
> > I read Entrust revoked their signature, and in theory that should
> > be enough.
>
> As long as the client becomes aware of that revocation, yes.
> DigiNotar's PKIOverheid CA also needs to be blocked. I don't remember reading
> any report of the gov already revoking it.
There was a new update of firefox today that removed an other
certificate. It also seems the government started using the new
one?
> > At least the openssl "verify" util has a "-crl_check", and
> > "-crl_check_all", but it doesn't do OCSP.
>
> Yes, there's X509_V_FLAG_CRL_CHECK and X509_V_FLAG_CRL_CHECK_ALL.
> OCSP can be checked with openssl ocsp, IIRC.
There is an ocsp util that you can use to generate and
validate ocsp requests. But it's not something you can
for instance check in something like s_client. s_client
does support CRLs however, but you need to make sure
they're downloaded and updated.
Looking at different client software, it seems to me that
nothing is actually checking CRL. And webbrowsers are
probably the only one doing OCSP, and only OCSP.
So the only solution I currently see is doing this in the
part that verifies the chain, and there making sure
know bad certificates generate a verify failure.
> > > I was thinking about hard-coding a check for CN=* DigiNotar * most likely
> > > in libcrypto's X.509 support, but so far my lack of knowledge of
> > > OpenSSL's internals has me a bit lost.
> > > Hard-coding it is suboptimal, but I think it is the only reasonable
> > > solution for the time being. We can't wait weeks or months for a better
> > > solution.
> > >
> > > What do you think about making such change?
> >
> > So you're basicly saying that X509_verify_cert() should give an
> > error in case it finds DigiNotar somewhere in the chain?
> >
> > I'm not opposed to such a change, but would like to see a better
> > option in the future.
>
> Yes. I will try to spend some time with a debugger later today to find the
> right place to implement such check. Or do you have any hint? (the cn
> validation functions didn't seem to be executed in one case I tried)
I have no real idea.
Kurt
Reply to: