You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2007/11/29 21:35:11 UTC
mod_ssl OCSP questions
Taking this discussion out of bugzilla. As implemented currently the
OCSP validation is working like this:
1) trusted store T initialized with root certs configured via SSLCA*
2) foreach cert in chain from (root...client certificate):
a) verify cert is signed by trusted cert (or, is transitively so)
b) if so, perform OCSP validation on cert as follows:
i) pick a responder, exchange OCSP messages
ii) verify signature of OCSP response against certs in trusted
store T
I'm not familiar with how OCSP is typically deployed; my questions are:
a) is it acceptable to assume that the same set of trusted certs is used
to verify the signature of the OCSP response as is used to verify the
client cert itself? Or do these need to be separately configurable?
b) does it really make sense to be doing OCSP validation individually on
each cert in the peer's cert chain? Marc mentioned an issue with a
compromised intermediary cert; but I want to be sure I understand this
properly. Can someone explain the exact threat model which checking the
whole chain would be necessary for?
c) Steve mentioned some responders don't accept requests with nonces.
What is a sane default? Send nonces (more secure), or not (better
interop). From reading the RFC it looks like mod_ssl should also be
checking the validity times from the OCSP response, which would help, I
guess.
Regards,
joe
Re: mod_ssl OCSP questions
Posted by Dr Stephen Henson <sh...@oss-institute.org>.
Joe Orton wrote:
> Many thanks for the detailed response! Everything taken on board, with
> one further question:
>
> On Thu, Nov 29, 2007 at 09:35:40PM +0000, Dr Stephen Henson wrote:
> ...
>> OpenSSL supports #1 and #2 directly so these should be automatic if the
>> OpenSSL OCSP API has been used correctly.
>>
>> A limited form of #3 is implemented in OpenSSL. A generalised version
>> might be more appropriate in some circumstances but would need
>> additional configuration options to implement.
>
> Making the responder signature verification configurable in mod_ssl
> would just involve setting up a different set of trusted certs in an
> X509_STORE_CTX and passing that as the context parameter to
> OCSP_basic_verify(), right? (When you say "OpenSSL supports...", I
> wonder if there is something more subtle here)
>
There isn't any need to have a separate store really. A set of root CAs
for different purposes can share a common store with each one given an
appropriate set of trust settings. These can be edited using the OpenSSL
'x509' utility.
The idea here for example is that a root CA can be labeled as trusted
for client authentication or server authentication only.
To retain compatibility with root CAs without trust settings most are on
by default.
OCSP signing is an exception which is off by default.
When a root has OCSP signing trust enabled any chain leading to it can
be used to sign arbitrary OCSP requests. This is a specific case of #3
where a special chain is used as a "global responder" which is trusted
to give status information about any CA.
There's some more info about this at:
http://www.openssl.org/docs/apps/ocsp.html#OCSP_Response_verification_
In some cases that is too wide and restrictions on the set of CAs a
given chain can authorise is more appropriate.
We could in future extend the OpenSSL trust settings to authorise chains
only for specific CAs (e.g. by OCSP IDs). That would probably make the
need for separate per-CA configuration options in mod_ssl unnecessary.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.
Re: mod_ssl OCSP questions
Posted by Joe Orton <jo...@redhat.com>.
Many thanks for the detailed response! Everything taken on board, with
one further question:
On Thu, Nov 29, 2007 at 09:35:40PM +0000, Dr Stephen Henson wrote:
...
> OpenSSL supports #1 and #2 directly so these should be automatic if the
> OpenSSL OCSP API has been used correctly.
>
> A limited form of #3 is implemented in OpenSSL. A generalised version
> might be more appropriate in some circumstances but would need
> additional configuration options to implement.
Making the responder signature verification configurable in mod_ssl
would just involve setting up a different set of trusted certs in an
X509_STORE_CTX and passing that as the context parameter to
OCSP_basic_verify(), right? (When you say "OpenSSL supports...", I
wonder if there is something more subtle here)
joe
Re: mod_ssl OCSP questions
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Nov 30, 2007 at 10:34:28AM +0100, Marc Stern wrote:
> To be generic, we should be able to set some options based on the cert CA,
> because we could use several types of certs (like when dealing with
> national certs from European countries).
Having security policy decided based on a *regex match* against a
textual representation of the issuer DN sounds pretty scary to me!
So the config options that are needed currently seem to be something
like this:
# select whether to validate the whole chain or just the EE cert
SSLOCSPValidateWholeChain <flag>
# set maximum time skew and age for response validity period
SSLOCSPResponseWindow <skew-secs> <max-age-secs>
# set CA certs for response signature verification
SSLOCSPResponseCAFile <file>
SSLOCSPResponseCAPath <directory>
These (and existing config options) could conceivably be wrapped into
issuer-CA-specific containers in the configuration, like:
<SSLOCSPValidationPolicy issuer-cert-file>
SSLOCSPFoo on
</SSLOCSPValidationPolicy>
which does some magic to allow selection of policy based on matching the
EE's issuer DN against the DNs of the certs in the issuer-cert-file; but
that's all blue sky stuff.
joe
Re: mod_ssl OCSP questions
Posted by Dr Stephen Henson <sh...@oss-institute.org>.
Marc Stern wrote:
>
>>> c) Steve mentioned some responders don't accept requests with
>>> nonces. What is a sane default? Send nonces (more secure), or not
>>> (better interop). From reading the RFC it looks like mod_ssl should
>>> also be checking the validity times from the OCSP response, which
>>> would help, I guess
>> I'll check how we are using the API. There are some OCSP helper
>> functions in OpenSSL which check the appropriate times and allow a
>> configurable "skew" for cases where clocks are inaccurately set. How
>> much skew to allow in practice may again depend on local policy.
>>
> I agree.
> If using a nonce, there is no need to check the date. If not, you have
> to specify the time delta to accept
>
Although a nonce supporting responder avoids replay attacks I'd say we
always need to check the date in case a responder fault result in it
producing status information with an invalid date.
I've seen real world examples where stale information was being returned
by a responder.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.
Re: mod_ssl OCSP questions
Posted by Dr Stephen Henson <sh...@oss-institute.org>.
Joe Orton wrote:
> Taking this discussion out of bugzilla. As implemented currently the
> OCSP validation is working like this:
>
> 1) trusted store T initialized with root certs configured via SSLCA*
> 2) foreach cert in chain from (root...client certificate):
> a) verify cert is signed by trusted cert (or, is transitively so)
> b) if so, perform OCSP validation on cert as follows:
> i) pick a responder, exchange OCSP messages
> ii) verify signature of OCSP response against certs in trusted
> store T
>
> I'm not familiar with how OCSP is typically deployed; my questions are:
>
> a) is it acceptable to assume that the same set of trusted certs is used
> to verify the signature of the OCSP response as is used to verify the
> client cert itself? Or do these need to be separately configurable?
>
There are several techniques used.
1. Sign responses using the key from the CA that issued the cert(s)
being checked.
This isn't often done because it would involve the responder having
access to a certificate signing key.
2. Sign responses using a special certificate signed by the CA that
issued the cert(s) being checked.
This is by far the most common. It avoids the problems of 1 and
responses can be verified without additional configuration.
3. Sign responses using a key which is trusted by some out of band means.
This covers cases where (for example) a locate OCSP responder is used to
sign responses for a site or a responder will handle multiple
unconnected CAs.
OpenSSL supports #1 and #2 directly so these should be automatic if the
OpenSSL OCSP API has been used correctly.
A limited form of #3 is implemented in OpenSSL. A generalised version
might be more appropriate in some circumstances but would need
additional configuration options to implement.
> b) does it really make sense to be doing OCSP validation individually on
> each cert in the peer's cert chain? Marc mentioned an issue with a
> compromised intermediary cert; but I want to be sure I understand this
> properly. Can someone explain the exact threat model which checking the
> whole chain would be necessary for?
>
If the CA key is compromised (e.g. used once maliciously) then it can be
used to issue an OCSP responder certificate under #2 above. That could
be used in a bogus responder.
Some security policies don't consider this likely enough to check the
whole chain and just check the EE cert which is much more likely to be
revoked.
I'd say making this configurable would be the best option.
> c) Steve mentioned some responders don't accept requests with nonces.
> What is a sane default? Send nonces (more secure), or not (better
> interop). From reading the RFC it looks like mod_ssl should also be
> checking the validity times from the OCSP response, which would help, I
> guess.
>
I'll check how we are using the API. There are some OCSP helper
functions in OpenSSL which check the appropriate times and allow a
configurable "skew" for cases where clocks are inaccurately set. How
much skew to allow in practice may again depend on local policy.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.