Re: SSL Bump Certificate Blacklist

From: Fabian Hugelshofer <fh_at_open.ch>
Date: Tue, 20 Sep 2011 13:46:02 +0200

On 09/16/2011 04:35 PM, Alex Rousskov wrote:
> On 09/16/2011 12:55 AM, Fabian Hugelshofer wrote:
>
>> manually issuing CRLs
>> for a certain CA is not possible because the CRL has to be singed by the
>> CA that issued the certificates.
>
> Wow, that is a major SSL limitation indeed! If this is true, we either
> must implement a custom black list functionality in Squid or customize
> OpenSSL to allow any trusted CA to revoke any certificate. Since there
> are too many OpenSSL versions, the former is probably more practical.

The requirements are not as strict as I initially thought. According to
RFC5280 section 5.1.1.3, the key used to issue certificates does not
have to be identical ot the one that is used to sign the CRL. Still, an
arbitrary trusted CA does not seem to be allowed to revoke certificates
of another one. At least OpenSSL does not allow this.

check_crl_chain() in crypto/x509/x509_vfy.c has the following comment:
"/* RFC3280 says nothing about the relationship between CRL path
  * and certificate path, which could lead to situations where a
  * certificate could be revoked or validated by a CA not authorised
  * to do so. RFC5280 is more strict and states that the two paths must
  * end in the same trust anchor, though some discussions remain...
  * until this is resolved we use the RFC5280 version
  */"

Like you say, there is need for a custom certificate blacklist.
Optimally, this blacklist is generic and can be configured through an ACL.

>>>> What would you use to identify the certificates?
>>>> - Serial number?
>>>> - Serial number and common name?
>>>> - Serial number and issuer?
>>>> - Fingerprint (might not be available in each case)?
>>>
>>>
>>> I hope somebody already answered these important questions in general
>>> CRL context!
>>
>> CRLs use the serial number in combination with the issuer.

The issuer name and the serial are probably not sufficient as there can
be multiple CAs with the same name (certificates with different
validity, different trust chains, ...).

> If we implement a custom black list, we can be flexible and support all
> of the above. To start with, I guess we should block all certificates
> with DigiNotar in the chain.

What are the next steps, would you like me to open a Squid Bug?

Regards,

Fabian
Received on Tue Sep 20 2011 - 11:46:05 MDT

This archive was generated by hypermail 2.2.0 : Tue Sep 20 2011 - 12:00:04 MDT