[gnutls-devel] SSL certificate validation bugs in GnuTLS

[Antoine Delignat-Lavaud]

Hi Daniel,

Le 13/02/2014 18:19, Daniel Kahn Gillmor a écrit :
> On 02/13/2014 11:45 AM, Antoine Delignat-Lavaud wrote:
>
>> 1. check all basic constraints and key usage flags properly
>
> 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.

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

>> 2. (depends on 1) enforce critical extensions. According to our
>> measurements, there are only two CA that have issued certificates with
>> non-standard critical extensions in the past 2 years, for a total of 629
>> certificates.
>
> why does this depend on 1?  enforcing criticality of extensions seems
> like it could be done independently.

BC and Key Usage are typically critical extension, it wouldn't make 
sense to accept them if the checks in RFC 5280 are not enforced.

>> 3. enforce extended key usage
>> 4. enforce name constraints
>
> it would be great to clarify which particular name constraints are the
> goal.  DNS does seem like the right direction to start from, clearly,
> though it doesn't make as much sense when thinking about client-side certs.

DNS constraints are the one that are (admittedly, very rarely) used in 
practice.

Best,

ADL


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4270 bytes
Desc: Signature cryptographique S/MIME
URL: </pipermail/attachments/20140213/6ed31225/attachment.bin>