[gnutls-devel] SSL certificate validation bugs in GnuTLS

Nikos Mavrogiannopoulos nmav at gnutls.org
Thu Feb 13 20:14:31 CET 2014


On 02/13/2014 07:58 PM, Antoine Delignat-Lavaud wrote:

>> I think this should be split into two pieces: basic constraints and key
>> usage flags.
>> Do we have evidence that other TLS stacks are actually checking key
>> usage flags and acting on the results?  Nikos' concern that users or
>> devs will think "GnuTLS is broken for site X" is a legitimate concern,
>> unfortunately.
> I ran some tests with Ilya Mironov at MSR, and we found that browsers do
> in fact enforce the CertSign bit on CA certs. When a server certificate
> is used to sign the parameters in DH and ECDH ciphers, it is widely
> accepted that it requires the Signature bit, and this bit is in fact in
> all certificates issued recently. We tried to connect with an invalid
> certificate on Firefox, Chrome and IE, which indeed triggered errors.
> The consensus for RSA is to require the keyEncipherment bit, which is a
> bit controversial (the PMS is not a key, so it could fall under
> dataEncipherment or keyAgreement as well). In any case, the CA/B
> requires digitalSignature and keyEncipherment, and this is what is
> (almost) always found in certificates today.
> Enabling this check shouldn't break any recently issued publicly trusted
> certificate. We only found one instance of a server certificate that had
> the decipherOnly bit accidentally set.

What we can do based on Daniel's suggestions is to have an additional
verification flag STRICT_RFC5280 or so, that will incorporate the
additional checks initially. Gradually we can move some of these tests
to the default setting.

It is important though, that when you add a new check to add two tests
for it in chainverify.c for it (one that should succeed, and one that
should violate the condition).

>> It looks like key usage violations used to be permitted only when
>> %COMPAT was specified in the priority string, and then commit id
>> 16d365ab359436651deb35a8ec6cdc0e76c077d9 that was changed to be
>> tolerated by default.  Perhaps this behavior could be added back in a
>> way that could be controlled by a more specific priority string (i'm not
>> sure what the default would be).
>> In addition to knowing what other TLS libraries do, a survey of sites
>> that are willing to offer ECDHE or DHE key exchange mechanisms without a
>> digital signature key usage flag would be helpful in making an argument
>> about what the default should be.
> I will double check this but as far as I remember I don't think there
> was any certificate issued without the DigitalSignature flag recently,
> at least on the public PKI.

You may want to check the SSL obvervatory's 2010 data (I couldn't find a
later version). There you'll notice a whole madness with certificates. I
even remember DSA certificates marked for key encipherment.

>>> 4. enforce name constraints

That would be nice to be enabled by default anyway. I have had hard time
to find a CA that uses that though. Anyway I'm working on an API to get
and set this extension's data so you could use that (not committed yet).

regards,
Nikos




More information about the Gnutls-devel mailing list