[gnutls-devel] SSL certificate validation bugs in GnuTLS

[Nikos Mavrogiannopoulos]

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