Erwann ABALEA wrote: > Hello Mr Henson, > > 2008/10/15 Dr Stephen Henson <[EMAIL PROTECTED]>: >> Dirk-Willem van Gulik wrote: >>> On Aug 28, 2008, at 9:41 PM, Nicob wrote: > [...] >> While I haven't reviewed this specific patch I have a general comment. >> >> There is currently some questionable behaviour in mod_ssl CRL handling. >> For example it ignores critical CRL extensions, whereas OpenSSL either >> processes them (if they are recognised) or rejects the CRL (if they are >> not). This is required by RFC3280 and not doing so raises some security >> issues. > > You're right. The original mod_ssl code doesn't check this, neither > for the CRL extensions, nor for the CRLentries extensions. > It can be added after the signature verification. >
This issue does have some security implications. For example a revoked client certificate could appear valid by substituting a delta CRL for a full CRL. >> IMHO it would be best if mod_ssl delegated CRL handling to OpenSSL by >> setting the necessary verification flags instead of duplicating >> functionality. In the past mod_ssl didn't have much choice but to do >> it's own thing because then OpenSSL CRL handling was either absent or >> broken. > > That was a proposed solution, some months ago, IIRC. Unfortunately, > OpenSSL has the same behaviour as mod_ssl regarding the problem solved > by this patch; it considers that the key used to sign the user > certificate is the same key used to sign the CRL. That assumption is > false in 2 cases (at least): > - a CA using keys+certificates for different usages (certificate > signing and CRL signing) > - a CA renewal (with rekeying) > > I proposed the same kind of patch on the OpenSSL mailing lists some > months ago, and only debated with Mr Patterson about the merits of a > CA renewal with/without rekeying. If you want to contact me privately > to talk about this, feel free to do so. > I'll have a look at that in more detail. There are some security issues with separate CRL and certificate signing keys which were debated on the PKIX lists some time ago. For that reason some of the cases are only permitted when certain verification flags for extended CRL support are set in OpenSSL 0.9.9. > I'm also in favor of letting OpenSSL perform the validation path and > CRL checking, if we can also handle the existing configurations (for > example, a typical Apache configuration has different > SSLCACertificatePath and SSLCARevocationPath directives, and OpenSSL > uses a unified path for both certificates and CRLs). Problems about > CRL refreshing should also be taken into account; killing and > restarting a webserver every hour or every day because we downloaded a > new CRL is not a viable solution in a production environment, and OCSP > is not always a good answer (we're not talking about a sub-minute > revocation status). Multiple paths can be used by OpenSSL but each path can contain both CRLs and certificates. Would there be a need to be able to restrict paths to one or the other? CRL refresh has some performance issues particularly in multi-process servers. For example a CRL might be 500K or more and be reloaded on each new connection. OpenSSL 0.9.9 does have some reload support though. If CRL processing was delegated to OpenSSL it would be available automatically. If there is sufficient demand reload support could be backported to 0.9.8. > >> Things are rather better now. The 0.9.9-dev version of OpenSSL is >> compliant with all the RFC3280 PKITS tests for example. The 0.9.8 >> handling isn't quite so complete though. > > OpenSSL 0.9.9-dev is mostly compliant to PKITS, yes, but not fully. > I'm reading my CVS copy, and based on this reading, Test19 of PKITS > test isn't OK (this is the case with separate certificate and CRL > keys). I'm now reading the check_crl() function, in x509_vfy.c file. > This is also solved by this patch. > It should be OK. The script pkits-run.pl sets the necessary flags for each case. It wont verify all such cases by default. The only one it will fail on is 4.14.30, which various docs say does not need to be run due to a circular dependency. Steve.
