You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Kaspar Brand <ht...@velox.ch> on 2010/12/12 10:28:58 UTC
mod_ssl OCSP tuning (Re: T&R of 2.3.10)
On 11.12.2010 20:27, Jim Jagielski wrote:
> I've heard no objections, so on monday (12/13) I'll start
> the T&R.
Is there any chance that the attached patch might make it into
2.3.10? It includes two OCSP related changes for mod_ssl:
- addresses https://issues.apache.org/bugzilla/show_bug.cgi?id=49784
by adding two config directives (SSLOCSPResponseTimeSkew and
SSLOCSPResponseMaxAge) and defining new default values
- prevents mod_ssl from doing unnecessary OCSP checks
(valid self-issued certs, i.e. trust anchors configured through
SSLCACertificate{File,Path})
Note that mod_ssl's current hardcoded OCSP defaults for the time skew
(60 seconds) and the max age (360 seconds) are quite aggressive -
especially the latter one. As PR 49784 illustrates, real-world OCSP
responses often have a validity of one or more days, and are not updated
at 5-minute intervals. I therefore suggest to default to -1 for the max
age, and to 300 seconds for the time skew - this also matches the
defaults which are currently applied in mod_ssl's OCSP stapling code.
Kaspar
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
Posted by Steve Marquess <ma...@opensslfoundation.com>.
Joe Orton wrote:
> ...
> w.r.t. the change to skip OCSP validation for valid self-signed certs, I
> brought this up a while back:
>
> http://www.mail-archive.com/dev@httpd.apache.org/msg38849.html
>
> and Stephen said it probably be configurable. Has common practice
> evolved here such that hard-coding the less strict behaviour is
> reasonable?
>
Are you referring to support for responders which sign responses using a
key which is trusted by some out of band means (such as with a
self-signed cert)?
The main OCSP responders in the U.S. DoD have been signing with a
self-signed cert for some time (an *expired* self-signed cert, no
less!). Just recently I was checking an OCSP problem and noted that I
was getting responses signed by an intermediate (to the CA) certificate,
but since there any many such responders I can't be sure they are all
now doing that.
So, I'd like to see support for out-of-band responder keys. As it is
I've had to hack in a fix to ignore the expired self-signed cert.
-Steve M.
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877-673-6775
marquess@opensslfoundation.com
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
Posted by Kaspar Brand <ht...@velox.ch>.
On 17.01.2011 15:27, Dr Stephen Henson wrote:
> On 17/01/2011 13:39, Joe Orton wrote:
>> w.r.t. the change to skip OCSP validation for valid self-signed certs, I
>> brought this up a while back:
>>
>> http://www.mail-archive.com/dev@httpd.apache.org/msg38849.html
>>
>> and Stephen said it probably be configurable. Has common practice
>> evolved here such that hard-coding the less strict behaviour is
>> reasonable?
The only case where checking self-signed, self-issued certs really makes
sense is the one mentioned by Steve - when an OCSP responder with an
explicitly trusted public key is used (case #3 in Steve's mail, in RFC
2560 section 2.2 it's called "Trusted Responder"). Certainly not a
common configuration for "In_ter_net" deployments, but maybe of use for
corporate/In_tra_net environments.
> I still believe it should be configurable.
>
> A root CA can be revoked for a number of reasons although key compromise has
> security issues if the responder certificate is part of the chain (i.e. cases #1
> and #2 in that message).
Remember such a root cert (trust anchor) will previously have been
configured through SSLCACertificateFile/SSLCACertificatePath anyway, so
the only "advantage" of OCSP checks for these would actually be that it
amounts to some kind of "alerting" feature for the admin - making him
aware of invalid root certs in his trust store. Once realized, he would
then certainly be better off with completely removing these roots from
the httpd config.
> Apache OCSP AFAIK currently doesn't handle case #3 at all (trusting responders
> with keys trusted by some out of band means).
>
> There is a fix/enhancement for this (which also addresses the issue Steve
> Marquess brought up) in PR46037.
I don't mind adding support for trusted responders, but until that
happens, I consider hard-coding mod_ssl to skip OCSP checks for valid
self-signed certs a sensible choice. Even when support for trusted
responder is added, I don't think it needs to be configurable - it can
be enabled/disabled based on the existence of trusted responders in the
config (relying on the absence/presence of the OCSP_TRUSTOTHER verify
flag, effectively).
For convenience, I'm attaching the snippet which hasn't been committed yet.
Another small patch to mod_ssl, which I consider low-hanging fruit, is
attached to PR 48215
(https://issues.apache.org/bugzilla/attachment.cgi?id=24583).
Kaspar
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
Posted by Dr Stephen Henson <sh...@oss-institute.org>.
On 17/01/2011 13:39, Joe Orton wrote:
> On Sun, Jan 16, 2011 at 11:34:29AM +0100, Kaspar Brand wrote:
>> On 13.12.2010 15:24, Jim Jagielski wrote:
>>> At this late in the game, I would prefer to do this post-2.3.10...
>>> safer that way.
>>
>> Polite reminder, according to [1]... :-) I feel it's important because
>> it addresses PR 49784 and a few additional improvements for the OCSP
>> checking code (for client auth).
>>
>> Patch v2 from December is attached again, for the sake of easier reference.
>
> Thanks a lot for the patch & the prod...
>
> I've merged the config options changes with some minor tweaks (OpenSSL
> seems to stomp on the OCSP_* namespace so I renamed the macros):
>
> http://svn.apache.org/viewvc?rev=1059917&view=rev
>
> w.r.t. the change to skip OCSP validation for valid self-signed certs, I
> brought this up a while back:
>
> http://www.mail-archive.com/dev@httpd.apache.org/msg38849.html
>
> and Stephen said it probably be configurable. Has common practice
> evolved here such that hard-coding the less strict behaviour is
> reasonable?
>
I still believe it should be configurable.
A root CA can be revoked for a number of reasons although key compromise has
security issues if the responder certificate is part of the chain (i.e. cases #1
and #2 in that message).
Apache OCSP AFAIK currently doesn't handle case #3 at all (trusting responders
with keys trusted by some out of band means).
There is a fix/enhancement for this (which also addresses the issue Steve
Marquess brought up) in PR46037.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
Posted by Joe Orton <jo...@redhat.com>.
On Sun, Jan 16, 2011 at 11:34:29AM +0100, Kaspar Brand wrote:
> On 13.12.2010 15:24, Jim Jagielski wrote:
> > At this late in the game, I would prefer to do this post-2.3.10...
> > safer that way.
>
> Polite reminder, according to [1]... :-) I feel it's important because
> it addresses PR 49784 and a few additional improvements for the OCSP
> checking code (for client auth).
>
> Patch v2 from December is attached again, for the sake of easier reference.
Thanks a lot for the patch & the prod...
I've merged the config options changes with some minor tweaks (OpenSSL
seems to stomp on the OCSP_* namespace so I renamed the macros):
http://svn.apache.org/viewvc?rev=1059917&view=rev
w.r.t. the change to skip OCSP validation for valid self-signed certs, I
brought this up a while back:
http://www.mail-archive.com/dev@httpd.apache.org/msg38849.html
and Stephen said it probably be configurable. Has common practice
evolved here such that hard-coding the less strict behaviour is
reasonable?
Regards, Joe
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
Posted by Kaspar Brand <ht...@velox.ch>.
On 13.12.2010 15:24, Jim Jagielski wrote:
> At this late in the game, I would prefer to do this post-2.3.10...
> safer that way.
Polite reminder, according to [1]... :-) I feel it's important because
it addresses PR 49784 and a few additional improvements for the OCSP
checking code (for client auth).
Patch v2 from December is attached again, for the sake of easier reference.
Thanks,
Kaspar
[1] http://httpd.apache.org/dev/patches.html#ignored
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
Posted by Jim Jagielski <ji...@jaguNET.com>.
At this late in the game, I would prefer to do this post-2.3.10...
safer that way.
On Dec 13, 2010, at 1:09 AM, Kaspar Brand wrote:
> On 12.12.2010 13:05, Dr Stephen Henson wrote:
>> It also makes sense to add a directive to make the OCSP timeout configurable.
>> This can be done in the OCSP stapling code but not the OCSP code itself. The
>> current default is (I think) the same as the http request timeout which is way
>> too long in practice: if an OCSP responder doesn't respond in a few seconds it
>> isn't likely to respond at all.
>
> Agreed, attached is v2 of the patch. It adds an SSLOCSPResponderTimeout
> directive, which defaults to 10 seconds. I also added the cfgMergeInt
> statements in ssl_engine_config.c, which I forgot in v1 by mistake.
>
> There are actually additional improvements I would like to see with the
> OCSP (clientauth) checking - in particular, having a cache (possibly
> reusing code from the stapling code)... but I was hoping that we could
> get the proposed fixes in for 2.3.10, at least. Reviews and/or commits
> are much appreciated - thanks!
>
> Kaspar
> <mod_ssl-ocsp-v2.patch>
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
Posted by Kaspar Brand <ht...@velox.ch>.
On 12.12.2010 13:05, Dr Stephen Henson wrote:
> It also makes sense to add a directive to make the OCSP timeout configurable.
> This can be done in the OCSP stapling code but not the OCSP code itself. The
> current default is (I think) the same as the http request timeout which is way
> too long in practice: if an OCSP responder doesn't respond in a few seconds it
> isn't likely to respond at all.
Agreed, attached is v2 of the patch. It adds an SSLOCSPResponderTimeout
directive, which defaults to 10 seconds. I also added the cfgMergeInt
statements in ssl_engine_config.c, which I forgot in v1 by mistake.
There are actually additional improvements I would like to see with the
OCSP (clientauth) checking - in particular, having a cache (possibly
reusing code from the stapling code)... but I was hoping that we could
get the proposed fixes in for 2.3.10, at least. Reviews and/or commits
are much appreciated - thanks!
Kaspar
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
Posted by Dr Stephen Henson <sh...@oss-institute.org>.
On 12/12/2010 09:28, Kaspar Brand wrote:
> On 11.12.2010 20:27, Jim Jagielski wrote:
>> I've heard no objections, so on monday (12/13) I'll start
>> the T&R.
>
> Is there any chance that the attached patch might make it into
> 2.3.10? It includes two OCSP related changes for mod_ssl:
>
> - addresses https://issues.apache.org/bugzilla/show_bug.cgi?id=49784
> by adding two config directives (SSLOCSPResponseTimeSkew and
> SSLOCSPResponseMaxAge) and defining new default values
>
> - prevents mod_ssl from doing unnecessary OCSP checks
> (valid self-issued certs, i.e. trust anchors configured through
> SSLCACertificate{File,Path})
>
> Note that mod_ssl's current hardcoded OCSP defaults for the time skew
> (60 seconds) and the max age (360 seconds) are quite aggressive -
> especially the latter one. As PR 49784 illustrates, real-world OCSP
> responses often have a validity of one or more days, and are not updated
> at 5-minute intervals. I therefore suggest to default to -1 for the max
> age, and to 300 seconds for the time skew - this also matches the
> defaults which are currently applied in mod_ssl's OCSP stapling code.
>
It also makes sense to add a directive to make the OCSP timeout configurable.
This can be done in the OCSP stapling code but not the OCSP code itself. The
current default is (I think) the same as the http request timeout which is way
too long in practice: if an OCSP responder doesn't respond in a few seconds it
isn't likely to respond at all.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org