httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erwann ABALEA" <eaba...@gmail.com>
Subject Re: CRL verification in mod_ssl
Date Sun, 19 Oct 2008 22:20:21 GMT
2008/10/15 Dr Stephen Henson <steve@openssl.org>:
> Erwann ABALEA wrote:
>> 2008/10/15 Dr Stephen Henson <steve@openssl.org>:
>>> 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.

Mime
View raw message