2008/10/15 Dr Stephen Henson <[EMAIL PROTECTED]>: > Erwann ABALEA wrote: >> 2008/10/15 Dr Stephen Henson <[EMAIL PROTECTED]>: >>> Dirk-Willem van Gulik wrote: >>>> On Aug 28, 2008, at 9:41 PM, Nicob wrote: >> [...] > 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.
As I said, you're right. CRL verification is definitely not done properly by the most widely adopted web server... The threat is also linked to how much trust is put into the CA producing those CRLs. [...] > 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. Mr Patterson told me about these issues, but the URLs given pointed to a "solution" proposed by someone from Microsoft to circumvent the fact that the CAPI doesn't handle it either. The solution was to have both the old and new keys sign the CRL. I'll try to google some informations about this discussion. > 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? No need to do that. The real need is to make sure identical configuration variables will lead to the same behaviour. > 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. CRL doesn't need to be "refreshed" on each connection, of course. It should at least be done on a regular basis. CRLs need to be carefully verified, I don't think you'll disagree with that. And "properly" also means checking up-to date CRLs. Talking big numbers... We operate several CAs, the biggest CRL we produce is a 83MB one, today... This, in itself, is an aberration, but as we say here, "le client est roi" (could be translated to: the customer is king). So this CRL exists, and the webservers this customer operates do check them. In fact, the same customer divided its population into 4 pieces, hence 4 CAs, and the 4 CRLs all together "weigh" 260MB. Refreshing those CRLs on each connection is of course out of question, everybody agrees with that. But it still needs to be refreshed on a periodic basis. Those CRLs are produced at least once a day. Some of them every hour. That's an extreme case, one OpenSSL can't handle properly (the memory needed to parse the CRL is really huge). But the arguments are still valid, for smaller CRLs. > OpenSSL 0.9.9 does have some reload support though. If > CRL processing was delegated to OpenSSL it would be available automatically. What is the decision criteria to reload a CRL? expiration of the "notAfter" date? An application based period would be better. [PKITS tests] > It should be OK. The script pkits-run.pl sets the necessary flags for > each case. It wont verify all such cases by default. Thanks, I played with it, it seems there are new execution paths for me to discover :) All in all, CRL validation performed by mod_ssl exists, that's good, since it was written when OpenSSL didn't provide a "clean" solution. But it has some several flaws, and now OpenSSL is able to do the job, maybe it's time to rewrite the glue between them? -- Erwann.
