[RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick <tr...@gmail.com>]

IMO the present concerns with OCSP Stapling are:

* not so clear that it has seen enough real-world testing; commented out
sample configs and better documentation will help, as will enabling by
default in trunk (just a little?)
* related bugs 57121 and 57131

A simple way to help with the broader issue raised in 57131, as well as fix
57121, is to not hold the global mutex while communicating with a
responder, with other handshakes completing with the existing response in
the cache as long as it is valid, or with the appropriate
communication-error response otherwise (some details omitted ;) ).

There are a few other bugs currently open for less severe issues.

TIA for your comments!

Index: docs/conf/extra/httpd-ssl.conf.in
===================================================================
--- docs/conf/extra/httpd-ssl.conf.in (revision 1635504)
+++ docs/conf/extra/httpd-ssl.conf.in (working copy)
@@ -9,7 +9,7 @@
 # consult the online docs. You have been warned.
 #
 # Required modules: mod_log_config, mod_setenvif, mod_ssl,
-#          socache_shmcb_module (for default value of SSLSessionCache)
+#          socache_shmcb_module (default SSLSessionCache and
SSLStaplingCache)

 #
 # Pseudo Random Number Generator (PRNG):
@@ -81,13 +81,13 @@
 #   How-To for more information.
 #
 #   Enable stapling for all SSL-enabled servers:
-#SSLUseStapling On
+SSLUseStapling On

 #   Define a relatively small cache for OCSP Stapling using
 #   the same mechanism that is used for the SSL session cache
 #   above.  If stapling is used with more than a few certificates,
 #   the size may need to be increased.  (AH01929 will be logged.)
-#SSLStaplingCache "shmcb:ssl_stapling(32768)"
+SSLStaplingCache "shmcb:ssl_stapling(32768)"

 #   Seconds before valid OCSP responses are expired from the cache
 #SSLStaplingStandardCacheTimeout 3600

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr <wr...@rowe-clan.net>]

On Jul 3, 2015 9:37 AM, "Rob Stradling" <ro...@comodo.com> wrote:
>
> On 03/07/15 11:13, Plüm, Rüdiger, Vodafone Group wrote:
> <snip>
>
>> Thanks for the detailed explanation. So yes OCSP stapling is really
beneficial
>> if it is possible for the server admin to set it up. But it likely
requires additional
>> configuration steps outside of httpd to make the OCSP responder
reachable (like firewall clearances)
>> and leads to otherwise strange "slow" responses if this is not prepared.
>> Another obstacle with the current stapling code is that the connection
to the OCSP responder of the
>> CA needs to happen directly and cannot be done via a proxy.
>> Hence I agree with Kaspar that it should be off by default.
>
>
> Given the current stapling code, that's fair enough.
>
> Is it feasible to engineer around these issues so that stapling could be
enabled by default in some future httpd release?  If not, what's the
showstopper?

This was Ben's suggestion, top post.

At this project, the trunk of svn is the next major or minor version, e g
3.0 or 2.6 eventually, that would be after a 2.5 beta cycle to hash out the
kinks.

I'm strongly in favor of enabling this by default as a down-the-road
opportunity, and current concerns can be better addressed if everyone who
is touching that future 2.5.0+ version is looking at all issues that arise.

httpd 2.6/3.0 may well disable plaintext out-of-the-box, with a default tls
listener, sni named vhosts and http/2 enabled by default.  Ignoring
stapling due to enterprises that have no other reason to start supporting
ocsp and other modern validation and verification tools should not be a
primary goal, from the forward looking convention.

If it can't be solved with code, then it can always be changed back to
default of disabled before GA.

Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk

[Rob Stradling <ro...@comodo.com>]

On 03/07/15 11:13, Plüm, Rüdiger, Vodafone Group wrote:
<snip>
> Thanks for the detailed explanation. So yes OCSP stapling is really beneficial
> if it is possible for the server admin to set it up. But it likely requires additional
> configuration steps outside of httpd to make the OCSP responder reachable (like firewall clearances)
> and leads to otherwise strange "slow" responses if this is not prepared.
> Another obstacle with the current stapling code is that the connection to the OCSP responder of the
> CA needs to happen directly and cannot be done via a proxy.
> Hence I agree with Kaspar that it should be off by default.

Given the current stapling code, that's fair enough.

Is it feasible to engineer around these issues so that stapling could be 
enabled by default in some future httpd release?  If not, what's the 
showstopper?

Thanks.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand <ht...@velox.ch>]

On 29.08.2015 17:56, olli hauer wrote:
> On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote:
>> Thanks for the detailed explanation. So yes OCSP stapling is really
>> beneficial if it is possible for the server admin to set it up. But
>> it likely requires additional configuration steps outside of httpd
>> to make the OCSP responder reachable (like firewall clearances) and
>> leads to otherwise strange "slow" responses if this is not
>> prepared. Another obstacle with the current stapling code is that
>> the connection to the OCSP responder of the CA needs to happen
>> directly and cannot be done via a proxy. Hence I agree with Kaspar
>> that it should be off by default.
>> 
> 
> Not tested, but looking at the mod_ssl doc it seems
> SSLStaplingForceURL can be used to proxy requests to the OCSP
> responder(s)
> 
> http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingforceurl
>
> In case SSLStaplingForceURL can be used to force OCSP requests via
> proxy it would be nice to add something like the following patch
> before enabling OCSP stapling as default.

It can't be used like this, as pointed out in [1]. Its main use is for
certs which do not include an OCSP URI at all, so configuring
SSLStaplingForceURL at the global level doesn't make much sense - you
would have to run a "transparent OCSP proxy" at that URL (mod_ssl will
just send plain OCSP requests to this address).

Kaspar

[1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201411.mbox/%3C5454A1FE.6060204%40velox.ch%3E

Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk

[olli hauer <oh...@gmx.de>]

On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote:
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Rob Stradling [mailto:rob.stradling@comodo.com]
>> Gesendet: Freitag, 3. Juli 2015 12:01
>> An: dev@httpd.apache.org
>> Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
>>
>> On 02/07/15 19:03, Ruediger Pluem wrote:
>> <snip>
>>> Just to be sure I don't miss anything. This is not about disabling
>> OCSP, its about disabling OCSP stapling by default.
>>> Maybe I have a wrong understanding of OCSP stapling, but to me
>> stapling only provides performance improvements, not
>>> security improvements for the client as the client still could connect
>> to the OCSP URL given in the cert directly and
>>> get the answer from there. If the response is stabled it does not need
>> to (with the same level of security) and saves
>>> itself a roundtrip to the OCSP server of the CA and the OCSP server of
>> the CA a request to process.
>>
>> Yes, the client _could_ connect to the OCSP URL given in the cert
>> directly and get the answer from there.  However, at least one major
>> browser (Chrome) no longer does this, but it does process stapled OCSP
>> responses.
>>
>> Even if we could ignore Chrome...
>> There will always be some clients that cannot reach the CA's OCSP
>> responder directly (due to connectivity issues at the client side),
>> whereas the TLS servers that those clients connect to may well have
>> better connectivity (and thus be able to staple OCSP responses that the
>> client cannot obtain by any other means).
>>
>> Also, this isn't just about performance.  If a client contacts an OCSP
>> responder directly, it reveals to the CA that it is interested in a
>> particular certificate.  That's a far worse privacy leak than a TLS
>> server contacting a CA's OCSP responder and revealing that it's
>> interested in the status of its own certificate!!
> 
> Thanks for the detailed explanation. So yes OCSP stapling is really beneficial
> if it is possible for the server admin to set it up. But it likely requires additional
> configuration steps outside of httpd to make the OCSP responder reachable (like firewall clearances)
> and leads to otherwise strange "slow" responses if this is not prepared.
> Another obstacle with the current stapling code is that the connection to the OCSP responder of the
> CA needs to happen directly and cannot be done via a proxy.
> Hence I agree with Kaspar that it should be off by default.
> 

Not tested, but looking at the mod_ssl doc it seems SSLStaplingForceURL can be used to proxy requests to the OCSP responder(s)

http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingforceurl

In case SSLStaplingForceURL can be used to force OCSP requests via proxy it would be nice to add something like the following patch before enabling OCSP stapling as default.

Index: trunk/docs/conf/extra/httpd-ssl.conf.in
===================================================================
--- trunk/docs/conf/extra/httpd-ssl.conf.in     (revision 1700039)
+++ trunk/docs/conf/extra/httpd-ssl.conf.in     (working copy)
@@ -114,6 +114,11 @@
 #   Seconds before invalid OCSP responses are expired from the cache
 #SSLStaplingErrorCacheTimeout 600

+#   This directive overrides the URI of an OCSP responder as obtained
+#   from the authorityInfoAccess (AIA) extension of the certificate.
+#   One potential use is when a proxy is used for retrieving OCSP queries.
+#SSLStaplingForceURL http://internal.proxy.local
+
 ##
 ## SSL Virtual Host Context
 ##

AW: [RFC] Enable OCSP Stapling by default in httpd trunk

[Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>]

> -----Ursprüngliche Nachricht-----
> Von: Rob Stradling [mailto:rob.stradling@comodo.com]
> Gesendet: Freitag, 3. Juli 2015 12:01
> An: dev@httpd.apache.org
> Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
> 
> On 02/07/15 19:03, Ruediger Pluem wrote:
> <snip>
> > Just to be sure I don't miss anything. This is not about disabling
> OCSP, its about disabling OCSP stapling by default.
> > Maybe I have a wrong understanding of OCSP stapling, but to me
> stapling only provides performance improvements, not
> > security improvements for the client as the client still could connect
> to the OCSP URL given in the cert directly and
> > get the answer from there. If the response is stabled it does not need
> to (with the same level of security) and saves
> > itself a roundtrip to the OCSP server of the CA and the OCSP server of
> the CA a request to process.
> 
> Yes, the client _could_ connect to the OCSP URL given in the cert
> directly and get the answer from there.  However, at least one major
> browser (Chrome) no longer does this, but it does process stapled OCSP
> responses.
> 
> Even if we could ignore Chrome...
> There will always be some clients that cannot reach the CA's OCSP
> responder directly (due to connectivity issues at the client side),
> whereas the TLS servers that those clients connect to may well have
> better connectivity (and thus be able to staple OCSP responses that the
> client cannot obtain by any other means).
> 
> Also, this isn't just about performance.  If a client contacts an OCSP
> responder directly, it reveals to the CA that it is interested in a
> particular certificate.  That's a far worse privacy leak than a TLS
> server contacting a CA's OCSP responder and revealing that it's
> interested in the status of its own certificate!!

Thanks for the detailed explanation. So yes OCSP stapling is really beneficial
if it is possible for the server admin to set it up. But it likely requires additional
configuration steps outside of httpd to make the OCSP responder reachable (like firewall clearances)
and leads to otherwise strange "slow" responses if this is not prepared.
Another obstacle with the current stapling code is that the connection to the OCSP responder of the
CA needs to happen directly and cannot be done via a proxy.
Hence I agree with Kaspar that it should be off by default.

Regards

Rüdiger

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Rob Stradling <ro...@comodo.com>]

On 02/07/15 19:03, Ruediger Pluem wrote:
<snip>
> Just to be sure I don't miss anything. This is not about disabling OCSP, its about disabling OCSP stapling by default.
> Maybe I have a wrong understanding of OCSP stapling, but to me stapling only provides performance improvements, not
> security improvements for the client as the client still could connect to the OCSP URL given in the cert directly and
> get the answer from there. If the response is stabled it does not need to (with the same level of security) and saves
> itself a roundtrip to the OCSP server of the CA and the OCSP server of the CA a request to process.

Yes, the client _could_ connect to the OCSP URL given in the cert 
directly and get the answer from there.  However, at least one major 
browser (Chrome) no longer does this, but it does process stapled OCSP 
responses.

Even if we could ignore Chrome...
There will always be some clients that cannot reach the CA's OCSP 
responder directly (due to connectivity issues at the client side), 
whereas the TLS servers that those clients connect to may well have 
better connectivity (and thus be able to staple OCSP responses that the 
client cannot obtain by any other means).

Also, this isn't just about performance.  If a client contacts an OCSP 
responder directly, it reveals to the CA that it is interested in a 
particular certificate.  That's a far worse privacy leak than a TLS 
server contacting a CA's OCSP responder and revealing that it's 
interested in the status of its own certificate!!

>> These are the same organization whose management are often those targeted by malware anyways.  It's on them if they
>> choose to ignore what few security measures are available to the less savvy end user.
>
> Again I don't get what this has to do with malware attacks on these organizations, but maybe my understanding of OCSP
> stapling is entirely wrong.
>
> Regards
>
> Rüdiger

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Ruediger Pluem <rp...@apache.org>]

On 07/02/2015 07:10 PM, William A Rowe Jr wrote:
> On Wed, Jul 1, 2015 at 8:54 AM, Plüm, Rüdiger, Vodafone Group <ruediger.pluem@vodafone.com
> <ma...@vodafone.com>> wrote:
> 
> 
>     > -----Ursprüngliche Nachricht-----
>     > Von: benlaurie@gmail.com <ma...@gmail.com> [mailto:benlaurie@gmail.com <ma...@gmail.com>] Im
>     Auftrag von
>     > Ben Laurie
>     > Gesendet: Mittwoch, 1. Juli 2015 14:27
>     > An: dev@httpd.apache.org <ma...@httpd.apache.org>
>     > Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
>     >
>     > On 1 November 2014 at 09:05, Kaspar Brand <httpd-dev.2014@velox.ch <ma...@velox.ch>>
>     > wrote:
>     > > On 30.10.2014 15:51, Jeff Trawick wrote:
>     > >> IMO the present concerns with OCSP Stapling are:
>     > >>
>     > >> * not so clear that it has seen enough real-world testing; commented
>     > out
>     > >> sample configs and better documentation will help, as will enabling
>     > by
>     > >> default in trunk (just a little?)
>     > >> * related bugs 57121 and 57131
>     > >>
>     > >> A simple way to help with the broader issue raised in 57131, as well
>     > as fix
>     > >> 57121, is to not hold the global mutex while communicating with a
>     > >> responder, with other handshakes completing with the existing
>     > response in
>     > >> the cache as long as it is valid, or with the appropriate
>     > >> communication-error response otherwise (some details omitted ;) ).
>     > >>
>     > >> There are a few other bugs currently open for less severe issues.
>     > >>
>     > >> TIA for your comments!
>     > >
>     > > I'm -1 on this, under the assumption that 2.4.x would eventually also
>     > > turn it on by default (yes, I'm aware of PR 50740, and CABF trying to
>     > > push this).
>     > >
>     > > While enabling it by default on trunk probably doesn't change much
>     > (in
>     > > my experience, very, very few people really compile and run trunk, I
>     > > would even claim that this applies to http devs, too), I feel that
>     > the
>     > > approach of "let's turn it on by default and see how many people run
>     > > into problems" (and bring them up on httpd-users etc.) isn't right.
>     > > Those interested in achieving a more widespread use should
>     > specifically
>     > > test OCSP stapling with mod_ssl, report their findings, file PRs on
>     > > Bugzilla (and if possible, also submit suitable patches).
>     > >
>     > > The fundamental objection I have to enabling stapling by default in
>     > our
>     > > GA releases is that it would enable a "phoning home" feature (to the
>     > > CA's OCSP responders) as a side effect of configuring a certificate.
>     > > This is a setting I consider unacceptable for software published by
>     > the
>     > > Apache HTTP Server project - the default must be opt-in, not opt-out.
>     >
>     > I've just become aware of this objection and would like to understand
>     > the thinking behind it. Firstly, it seems strange to call this
>     > "phoning home", a term that _usually_ means connecting to the vendor
>     > of the s/w.
>     >
>     > But more importantly, what harm is there in a server connecting to the
>     > OCSP responders for the certificates it is serving? Why is this
>     > "unacceptable"?
> 
>     Because in many organizations it can't because of network / firewall restrictions.
>     If it tries nevertheless by default this causes the following issues with a default configuration:
> 
>     1. As the network components / firewalls likely simply drop the packages the TCP connect to the OCSP server needs to
>     run into TCP connection timeout which can take quite a while blocking the response back to the client of the
>     webserver. Finding this out can be troublesome.
> 
>     2. As the webserver will try to connect to the OCSP server quite often and is denied this likely triggers intrusion
>     detection systems and starts all kind of security processes in an organization that thinks that a hacked server
>     tries to connect to the outside world.
> 
> 
> Although we are talking about large organizations... if they choose to disable OCSP to their organization, isn't it
> equally upon them to configure the server to ignore OCSP?

Just to be sure I don't miss anything. This is not about disabling OCSP, its about disabling OCSP stapling by default.
Maybe I have a wrong understanding of OCSP stapling, but to me stapling only provides performance improvements, not
security improvements for the client as the client still could connect to the OCSP URL given in the cert directly and
get the answer from there. If the response is stabled it does not need to (with the same level of security) and saves
itself a roundtrip to the OCSP server of the CA and the OCSP server of the CA a request to process.

> 
> These are the same organization whose management are often those targeted by malware anyways.  It's on them if they
> choose to ignore what few security measures are available to the less savvy end user.

Again I don't get what this has to do with malware attacks on these organizations, but maybe my understanding of OCSP
stapling is entirely wrong.

Regards

Rüdiger

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr <wr...@rowe-clan.net>]

On Wed, Jul 1, 2015 at 8:54 AM, Plüm, Rüdiger, Vodafone Group <
ruediger.pluem@vodafone.com> wrote:

>
> > -----Ursprüngliche Nachricht-----
> > Von: benlaurie@gmail.com [mailto:benlaurie@gmail.com] Im Auftrag von
> > Ben Laurie
> > Gesendet: Mittwoch, 1. Juli 2015 14:27
> > An: dev@httpd.apache.org
> > Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
> >
> > On 1 November 2014 at 09:05, Kaspar Brand <ht...@velox.ch>
> > wrote:
> > > On 30.10.2014 15:51, Jeff Trawick wrote:
> > >> IMO the present concerns with OCSP Stapling are:
> > >>
> > >> * not so clear that it has seen enough real-world testing; commented
> > out
> > >> sample configs and better documentation will help, as will enabling
> > by
> > >> default in trunk (just a little?)
> > >> * related bugs 57121 and 57131
> > >>
> > >> A simple way to help with the broader issue raised in 57131, as well
> > as fix
> > >> 57121, is to not hold the global mutex while communicating with a
> > >> responder, with other handshakes completing with the existing
> > response in
> > >> the cache as long as it is valid, or with the appropriate
> > >> communication-error response otherwise (some details omitted ;) ).
> > >>
> > >> There are a few other bugs currently open for less severe issues.
> > >>
> > >> TIA for your comments!
> > >
> > > I'm -1 on this, under the assumption that 2.4.x would eventually also
> > > turn it on by default (yes, I'm aware of PR 50740, and CABF trying to
> > > push this).
> > >
> > > While enabling it by default on trunk probably doesn't change much
> > (in
> > > my experience, very, very few people really compile and run trunk, I
> > > would even claim that this applies to http devs, too), I feel that
> > the
> > > approach of "let's turn it on by default and see how many people run
> > > into problems" (and bring them up on httpd-users etc.) isn't right.
> > > Those interested in achieving a more widespread use should
> > specifically
> > > test OCSP stapling with mod_ssl, report their findings, file PRs on
> > > Bugzilla (and if possible, also submit suitable patches).
> > >
> > > The fundamental objection I have to enabling stapling by default in
> > our
> > > GA releases is that it would enable a "phoning home" feature (to the
> > > CA's OCSP responders) as a side effect of configuring a certificate.
> > > This is a setting I consider unacceptable for software published by
> > the
> > > Apache HTTP Server project - the default must be opt-in, not opt-out.
> >
> > I've just become aware of this objection and would like to understand
> > the thinking behind it. Firstly, it seems strange to call this
> > "phoning home", a term that _usually_ means connecting to the vendor
> > of the s/w.
> >
> > But more importantly, what harm is there in a server connecting to the
> > OCSP responders for the certificates it is serving? Why is this
> > "unacceptable"?
>
> Because in many organizations it can't because of network / firewall
> restrictions.
> If it tries nevertheless by default this causes the following issues with
> a default configuration:
>
> 1. As the network components / firewalls likely simply drop the packages
> the TCP connect to the OCSP server needs to run into TCP connection timeout
> which can take quite a while blocking the response back to the client of
> the webserver. Finding this out can be troublesome.
>
> 2. As the webserver will try to connect to the OCSP server quite often and
> is denied this likely triggers intrusion detection systems and starts all
> kind of security processes in an organization that thinks that a hacked
> server tries to connect to the outside world.
>

Although we are talking about large organizations... if they choose to
disable OCSP to their organization, isn't it equally upon them to configure
the server to ignore OCSP?

These are the same organization whose management are often those targeted
by malware anyways.  It's on them if they choose to ignore what few
security measures are available to the less savvy end user.

AW: [RFC] Enable OCSP Stapling by default in httpd trunk

[Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>]

> -----Ursprüngliche Nachricht-----
> Von: benlaurie@gmail.com [mailto:benlaurie@gmail.com] Im Auftrag von
> Ben Laurie
> Gesendet: Mittwoch, 1. Juli 2015 14:27
> An: dev@httpd.apache.org
> Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
> 
> On 1 November 2014 at 09:05, Kaspar Brand <ht...@velox.ch>
> wrote:
> > On 30.10.2014 15:51, Jeff Trawick wrote:
> >> IMO the present concerns with OCSP Stapling are:
> >>
> >> * not so clear that it has seen enough real-world testing; commented
> out
> >> sample configs and better documentation will help, as will enabling
> by
> >> default in trunk (just a little?)
> >> * related bugs 57121 and 57131
> >>
> >> A simple way to help with the broader issue raised in 57131, as well
> as fix
> >> 57121, is to not hold the global mutex while communicating with a
> >> responder, with other handshakes completing with the existing
> response in
> >> the cache as long as it is valid, or with the appropriate
> >> communication-error response otherwise (some details omitted ;) ).
> >>
> >> There are a few other bugs currently open for less severe issues.
> >>
> >> TIA for your comments!
> >
> > I'm -1 on this, under the assumption that 2.4.x would eventually also
> > turn it on by default (yes, I'm aware of PR 50740, and CABF trying to
> > push this).
> >
> > While enabling it by default on trunk probably doesn't change much
> (in
> > my experience, very, very few people really compile and run trunk, I
> > would even claim that this applies to http devs, too), I feel that
> the
> > approach of "let's turn it on by default and see how many people run
> > into problems" (and bring them up on httpd-users etc.) isn't right.
> > Those interested in achieving a more widespread use should
> specifically
> > test OCSP stapling with mod_ssl, report their findings, file PRs on
> > Bugzilla (and if possible, also submit suitable patches).
> >
> > The fundamental objection I have to enabling stapling by default in
> our
> > GA releases is that it would enable a "phoning home" feature (to the
> > CA's OCSP responders) as a side effect of configuring a certificate.
> > This is a setting I consider unacceptable for software published by
> the
> > Apache HTTP Server project - the default must be opt-in, not opt-out.
> 
> I've just become aware of this objection and would like to understand
> the thinking behind it. Firstly, it seems strange to call this
> "phoning home", a term that _usually_ means connecting to the vendor
> of the s/w.
> 
> But more importantly, what harm is there in a server connecting to the
> OCSP responders for the certificates it is serving? Why is this
> "unacceptable"?

Because in many organizations it can't because of network / firewall restrictions.
If it tries nevertheless by default this causes the following issues with a default configuration:

1. As the network components / firewalls likely simply drop the packages the TCP connect to the OCSP server needs to run into TCP connection timeout which can take quite a while blocking the response back to the client of the webserver. Finding this out can be troublesome.

2. As the webserver will try to connect to the OCSP server quite often and is denied this likely triggers intrusion detection systems and starts all kind of security processes in an organization that thinks that a hacked server tries to connect to the outside world.


Regards

Rüdiger

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick <tr...@gmail.com>]

On Sat, Jul 11, 2015 at 2:55 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> We can have a dialog about the best behavior of our default config.
> However...
>
> On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand <ht...@velox.ch>
> wrote:
>
>> On 01.07.2015 14:27, Ben Laurie wrote:
>> > On 1 November 2014 at 09:05, Kaspar Brand <ht...@velox.ch>
>> wrote:
>> >> The fundamental objection I have to enabling stapling by default in our
>> >> GA releases is that it would enable a "phoning home" feature (to the
>> >> CA's OCSP responders) as a side effect of configuring a certificate.
>> >> This is a setting I consider unacceptable for software published by the
>> >> Apache HTTP Server project - the default must be opt-in, not opt-out.
>> >
>> > I've just become aware of this objection and would like to understand
>> > the thinking behind it. Firstly, it seems strange to call this
>> > "phoning home", a term that _usually_ means connecting to the vendor
>> > of the s/w.
>> >
>> > But more importantly, what harm is there in a server connecting to the
>> > OCSP responders for the certificates it is serving? Why is this
>> > "unacceptable"?
>>
>> It's unacceptable for at least two reasons: a) by default, an HTTP
>> server is supposed to process *incoming* requests, not make accidental
>> outgoing connections in addition (at least not unless it's explicitly
>> instructed to do so); b) there's no statement in our license with an
>> explicit caveat on such a side effect ("when relying on our default
>> settings, configuring a site with an SSL server certificate may result
>> in unsolicited outgoing HTTP requests" - and no, I do not want to see
>> our license amended by things like that).
>>
>
> Our License says nothing about accepting requests, either.  Licenses
> don't express these mechanics.  They define the terms for users to
> "reproduce, prepare Derivative Works of, publicly display, publicly
> perform,
> sublicense, and distribute" the work and its derivatives, and the
> corresponding
> patent rights as well.
>
> A number of ASF works are servers.  A number are clients.  A number are
> both clients and servers.  OCSP is hardly an accidental request, any more
> than
> the proxy module requests.  And in forwarding requests to https proxy
> servers,
> (another side effect) verifying the OCSP identity of the connected server
> is
> hardly an unexpected side effect, it's a characteristic of the protocol
> (that
> backend *server* advertised OCSP validation - stapled or indirect, and that
> the *user* configured the certificate for OCSP validation).  Third party
> OCSP
> validation is so problematic that OCSP stapling is a blindly obvious
> enhancement
> that will far offset the routing configuration issues it also inspires
>
> So your premise above is, well, outright silly.
>
>
>> I maintain my objection to uncommenting "#SSLUseStapling On" in our
>> default config in httpd-ssl.conf.in - and for the record, also to
>> changing code, be that in ssl_engine_config.c:modssl_ctx_init() or
>> elsewhere. Those keen on enabling it by default on behalf of the users
>> ("because we know what is good for you") are free to lobby with the OS
>> vendors to have their package defaults changed.
>>
>
> You are welcome to object, and I think Ben's reply here to your thoughts
> and observations, particularly your early one, since he is advocating for
> this
> change and this would move the dialog along to a conclusion.
>
> Contrawise, httpd project can do the 'right thing' from our perspective,
> and
> the downstream distributors can correspondingly disable it.
>
> Moreso, any enterprise so affected already is configuring httpd to their
> own
> organization's standards and policies.
>
> If you are suggesting we shouldn't change the compiled-in default, I can
> agree, POLS (Principal Of Least Surprise).  If you are suggesting the
> default
> config shouldn't reflect the ability to efficiently handle OCSP by
> stapling, here
> I think we would disagree.
>

Not to anyone in particular:

Contacting the OCSP responder may indeed be a surprise, and it might not
even work due to to firewall rules being effectively surprised.  (DNS was
too once upon a time.)  It does require education on the part of some
administrators.  But:

No changes discussed actually change the behavior for any non-hypothetical
configuration, since SSL is not configured by default and no existing
configurations will magically start contacting the responder.  (The more
nuanced wording of "OCSP stapling by default" is "IFF you're using the
latest httpd default configuration files, an OCSP responder pointed to in a
certificate you configure will be utilized, unless you say otherwise.").

The config change does move the key decision point regarding this new
concept to the basic enablement of SSL.  In retrospect, it might have been
wise to enable/disable stapling on the SSLCertificateFile directive, both
for the more granular control as well as making the admin see the setting
when performing that required bit of configuration.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Brian Smith <br...@briansmith.org>]

Kaspar Brand <ht...@velox.ch> wrote:

> On 28.08.2015 19:27, Jeff Trawick wrote:
> > For one, it is appropriate for the default config is there to enable
> > practices which are reasonable in most situations, and OCSP Stapling is
> > widely accepted as an appropriate feature for HTTP servers to enable.
>
> I have some doubts whether "widely accepted" is an accurate summary of
> today's situation, because this assessment misses the fact that with the
> current RFC-6066-based implementation, stapling can't fully achieve the
> goal of obviating OCSP queries for the clients - all publicly trusted
> CAs use hierarchies with at least two tiers these days, so effectively
> RFC 6961 support would be needed.


This is not true. In the case of Firefox, and I believe Chrome, it was
decided that the website is responsible for delivering the OCSP response
(via stapling) for the end-entity, and the browser is responsible for
getting the revocation info for the intermediates *in some unspecified
way*. In practice, that way is CRLSets. I think MSIE is or has also started
moving to that model.

In particular, browser makers aren't interested in RFC 6961 because of it
is a poor performance trade-off and also never implemented.



> And given that the most popular
> browser only enforces revocation checking for EV certificates (certainly
> less than 10% of all SSL certs out there), the benefit of turning on
> stapling for DV/OV certs by default is not so apparent either.
>

This is a chicken-and-egg problem. The proposed Must-Staple feature makes
OCSP useful. Obviously Must-Staple only works if the server staples the
response. Conversely, without Must-Staple, OCSP is useless in browsers.


> What wasn't mentioned in the original RFC [1], and what I'm still
> wondering about, is the primary motivation for enabling it on trunk?


The main motivation for OCSP stapling is to demonstrate that OCSP stapling
works in a widespread way, so that browsers can start implementing the
Must-Staple feature and gather useful metrics about the effects, including
any possible negative side effects.


> As I wrote in my reply at that time, changing the default in trunk will
> hardly help in getting broader real-world testing results.


It has to be changed on Trunk before it can be changed anywhere else, right?



> If the
> plan is to propose a backport to 2.4.x soon afterwards, however, then I
> would certainly oppose unless systematic coverage for OCSP stapling is
> added to the test framework (enabling a feature by default in a GA
> release for which there is not a single test is a no go, IMO).
>

I agree.

And, to be perfectly honest, there are a lot of things that can go wrong
with OCSP stapling and I've yet to see an implementation without a serious
flaw.


> It should be worth mentioning that the OCSP URI in a server cert is to
> be considered untrusted, as mod_ssl does not validate its own cert at
> startup.
>

Using that argument, it isn't safe to use the server's end-entity
certificate either, because it hasn't been checked for validity. In
particular, it hasn't been checked for revocation! The Heartbleed
vulnerability had such a huge impact partially because there was no
**effective** and easy-to-use way for servers to revoke certificates. We
need to find a solution to revocation and I think that Apache enabling OCSP
stapling by default is the next step towards a solution.


> The default configuration should not trigger unsolicited outgoing
> queries to untrusted systems, for both a) and b), that's how I would
> put it.


Look at IIS, which has been doing OCSP stapling by default, without
significant problems, for many years now. Has anybody really been harmed by
IIS's default? I don't think so. I think this is an instance of the perfect
being the enemy of the good.


> Additionally, features enabled by default need to have sufficient
> coverage in the test framework.
>

Again, I agree.

In case it would be helpful: When I was at Mozilla, my team created a new
certificate verification library for Firefox. That includes a complete
implementation of OCSP verification. It also includes a small test suite
for OCSP verification. We intentionally licensed it under the Apache 2.0
license so that Apache could use the code, if Apache wants to use it. If
nothing else, the OCSP tests [3] might be a useful model for Apache's tests.

After I left Mozilla, I separated out the implementation from Firefox's
repository and made it available on GitHub: [1]. I spent some time making
that code work with OpenSSL in a branch [2].

[1] https://github.com/briansmith/mozillapkix
[2] https://github.com/briansmith/mozillapkix/tree/feature/openssl
[3]
https://github.com/briansmith/mozillapkix/blob/master/test/gtest/pkixocsp_VerifyEncodedOCSPResponse.cpp

Cheers,
Brian
-- 
https://briansmith.org/

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr <wr...@rowe-clan.net>]

On Sep 6, 2015 8:09 AM, "Kaspar Brand" <ht...@velox.ch> wrote:
>
> On 05.09.2015 13:06, Tim Bannister wrote:
> > It's not just conventional browsers. I think automated / embedded
> > HTTP clients will also benefit from stapling, either because
> > networking filters would block a conversation between the client and
> > the CA's OCSP responder, or the extra latency from using conventional
> > OCSP is a problem.
>
> That hope is mostly futile:

Kaspar,

It might help to pause here and ask what your hope or aspiration is, here.
I am reading a lot of 'no, not that' in your messages, but very little
'this instead would improve the status quo.'. Please share so we aren't
talking past one another

Yours,

Bill

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand <ht...@velox.ch>]

On 05.09.2015 13:06, Tim Bannister wrote:
> It's not just conventional browsers. I think automated / embedded
> HTTP clients will also benefit from stapling, either because
> networking filters would block a conversation between the client and
> the CA's OCSP responder, or the extra latency from using conventional
> OCSP is a problem.

That hope is mostly futile: OpenSSL e.g., presumably quite popular
for implementing such clients, does not include any readily available
support for enabling OCSP checking in client mode. And even if a library
has some sort of knob for turning it on (Sun^WOracle's CertPath provider
e.g.), you'll mostly find that they don't handle stapled responses.
Consider yourself happy if a client at least does some sort of hostname
verification (see https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf for
further background, the situation didn't change fundamentally since then).

> For another example of a non-interactive application implementing
> OCSP, look at the Exim mail transfer agent (which can be both client
> and server).

SMTP with STARTTLS isn't a useful example, sorry... it's opportunistic
encryption only in the best case, and for MTA communications, DANE-EE
(https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/) looks
like a more promising approach.

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Tim Bannister <is...@c8h10n4o2.org.uk>]

On 5 Sep 2015, at 11:53, Ben Laurie <be...@links.org> wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <ht...@velox.ch> wrote:
>> On 04.09.2015 17:54, Rob Stradling wrote:
>>> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling enabled.  Browsers aren't likely to start hard-failing by default until that % is a lot higher.
> 
> …the reason browsers don't hard fail is because OCSP (or any out of band communication) is unreliable. So that either means you fail for sites that are actually perfectly OK, or you allow an attacker to override revocation (by blocking OCSP).
…
> Blocking stapling (and presumably you will also object to CT for similar reasons) is hurting security.
> 
> You've argued that there's no point switching on stapling because browsers won't pay attention to OCSP anyway. That is not true. They don't pay attention to OCSP because it is unreliable. If stapling were widely deployed, then it would be possible to switch on hard fail.

It's not just conventional browsers. I think automated / embedded HTTP clients will also benefit from stapling, either because  networking filters would block a conversation between the client and the CA's OCSP responder, or the extra latency from using conventional OCSP is a problem.

For another example of a non-interactive application implementing OCSP, look at the Exim mail transfer agent (which can be both client and server).

-- 
Tim Bannister – isoma@c8h10n4o2.org.uk

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Reindl Harald <h....@thelounge.net>]

Am 06.09.2015 um 15:06 schrieb Kaspar Brand:
> Taking into account that OCSP responders from the big players are
> running on fairly robust infrastructure these days (cf. the sr.symcd.com
> example, aka ocsp.verisign.net, aka ocsp.ws.symantec.com.edgekey.net),
> I'm not buying the "OCSP is unreliable" statement in this wholesale form.

"fairly robust" don't change the fact that they would be a perfect DDOS 
target and so an attacker would point one botnet to your server and the 
other to the matching OCSP responder - not to forget how many sites you 
can DDOS in case of clients would enforce OCSP and hard-fail

currently they are not a target for such attacks

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand <ht...@velox.ch>]

On 05.09.2015 12:53, Ben Laurie wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <ht...@velox.ch> wrote:
>> I'm also very sceptical that a higher percentage of handshakes with
>> stapled responses (how much exactly?) will lead browser vendors to
>> switch to hard fail - as the test-sspev.verisign.com example from my
>> previous message shows, they could do this for EV today already (even
>> Chrome tries querying the OCSP responder in this case). But none of them
>> does, often due to the fear of losing market share when being too strict
>> in enforcing TLS security (cf. the case of RC4 banning).
>>
> 
> I don't know why you think your example shows that - the reason browsers
> don't hard fail is because OCSP (or any out of band communication) is
> unreliable.

Unreliable in what sense, or for what reason? Due to OCSP responders
being unreachable, being unable to handle the load, serving flawed
responses (like the recent hiccup mentioned in
https://twitter.com/GSSystemAlerts/status/634418637835669504), or...?
Only the second point can be addressed by stapling, as it simply
switches to another method for transmitting the response to the client.

> So that either means you fail for sites that are actually
> perfectly OK, or you allow an attacker to override revocation (by blocking
> OCSP).
> 
>  This is why browsers are pushing for OCSP stapling, not because of speed.

Taking into account that OCSP responders from the big players are
running on fairly robust infrastructure these days (cf. the sr.symcd.com
example, aka ocsp.verisign.net, aka ocsp.ws.symantec.com.edgekey.net),
I'm not buying the "OCSP is unreliable" statement in this wholesale form.

Even assuming that, say, 90% of all handshakes would include stapled
responses one day, I'm pretty sure that browsers would come up with
other arguments as to why they can't enforce hard-fail. Or perhaps in
one or two years, they want everybody to switch to using short-lived
certs without OCSP (because "revocation doesn't work" anyway), at which
point the "let's get OCSP stapling universally deployed" exercise would
become moot.

> Certificate Transparency faces the same problem, which is why it only
> exists as an in-band mechanism.
> 
> Blocking stapling (and presumably you will also object to CT for similar
> reasons) is hurting security.

CT is a completely separate topic, but for the sake of completeness:
yes, I would object to enabling such a feature in httpd by default, as
long as it triggers outgoing connections on the server. That isn't the
case for being able to serve SCTs, however: all it takes is
httpd/mod_ssl 2.4.8 or later compiled against OpenSSL 1.0.2a or later,
an appropriate "BEGIN SERVERINFO FOR..." file and an "SSLOpenSSLConfCmd
ServerInfoFile ..." directive in the config (no outgoing connectivity on
the server needed, neither permanently nor temporarily).

> You've argued that there's no point switching on stapling because browsers
> won't pay attention to OCSP anyway. That is not true. They don't pay
> attention to OCSP because it is unreliable. If stapling were widely
> deployed, then it would be possible to switch on hard fail.

Again, the "OCSP is unreliable" statement is just your current claim
(unless you can provide real-world measurements showing things like "30%
of all OCSP queries fail due to timeouts", "50% of all OCSP checks take
more than 3 seconds" or similar). Having used Firefox with
security.OCSP.require=true for extended periods of time, I do not agree
with the overall assessment of OCSP being unreliable.

> Leaving it to admins makes no sense to me - most admins are not acquainted
> with the detailed reasons for/against stapling, and are not in a position
> to make an informed decision.

That's what our documentation is for. Just asserting that admins
are too dumb to understand and instead decide on their behalf is an
attitude I strongly dislike. Apache httpd is not the same sort of
software like browsers for the big (and probably often clueless) masses,
where that approach might have its justification.

> Someone has to choose the default, and IMO
> the ASF should always default to "more secure".

Pretty muddy ground - "more secure" in what sense exactly? A server not
being dependent on outgoing connectivity for its day-to-day operations
is typically more secure than one which regularly needs to fetch data
from the outside world.

And if stapling is really making servers "more secure", why are
www.google.com, mail.google.com or drive.google.com still not providing
stapled responses as of today? (same is true for other high-traffic
sites like Twitter or FB, JFTR)

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Ben Laurie <be...@links.org>]

On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <ht...@velox.ch> wrote:

> On 04.09.2015 17:54, Rob Stradling wrote:
> > Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
> > enabled.  Browsers aren't likely to start hard-failing by default until
> > that % is a lot higher.
> >
> > The vast majority of the servers that have OCSP stapling enabled are
> > running IIS.  I claim that this is due to the fact that IIS enables OCSP
> > stapling by default.
>
> The relevant metric is the percentage of (initial) TLS handshakes with
> stapled responses, not so much the percentage of servers with stapling
> enabled. Judging from Mozilla's telemetry data for Firefox 39 and 40,
> that percentage is still below 15%, and enabling stapling in an httpd
> config file which gets used by a very small number of Apache httpd admins
> (as opposed to those settings which go out to the world via [1] or [2])
> doesn't look like a very effective way of achieving the goal of making
> that percentage "a lot higher".
>
> I'm also very sceptical that a higher percentage of handshakes with
> stapled responses (how much exactly?) will lead browser vendors to
> switch to hard fail - as the test-sspev.verisign.com example from my
> previous message shows, they could do this for EV today already (even
> Chrome tries querying the OCSP responder in this case). But none of them
> does, often due to the fear of losing market share when being too strict
> in enforcing TLS security (cf. the case of RC4 banning).
>

I don't know why you think your example shows that - the reason browsers
don't hard fail is because OCSP (or any out of band communication) is
unreliable. So that either means you fail for sites that are actually
perfectly OK, or you allow an attacker to override revocation (by blocking
OCSP).

 This is why browsers are pushing for OCSP stapling, not because of speed.

Certificate Transparency faces the same problem, which is why it only
exists as an in-band mechanism.

Blocking stapling (and presumably you will also object to CT for similar
reasons) is hurting security.

You've argued that there's no point switching on stapling because browsers
won't pay attention to OCSP anyway. That is not true. They don't pay
attention to OCSP because it is unreliable. If stapling were widely
deployed, then it would be possible to switch on hard fail.

Leaving it to admins makes no sense to me - most admins are not acquainted
with the detailed reasons for/against stapling, and are not in a position
to make an informed decision. Someone has to choose the default, and IMO
the ASF should always default to "more secure".


> > I think you've misunderstood the "speed, speed, speed" argument.
> >
> > If an OCSP response is delivered via stapling, then there's no need for
> > the browser to block the TLS handshake whilst it obtains an OCSP
> > response directly from the CA's OCSP responder.
>
> No, I didn't misunderstand. That's very much the essence of the "speed,
> speed, speed" argument - "our browser must be able to complete every TLS
> handshake in under 100 ms"... even if for a specific server, it's just
> one TLS handshake per day where it really matters.
>
> > Stapling provides a noticeable speedup even if the browser never caches
> > OCSP responses.
>
> Fairly hypothetical point - I'm not aware of any common browser which
> would use a cert validation library without an OCSP cache.
>
> Kaspar
>
>
> [1] https://git.centos.org/blob/rpms!httpd.git/c7/SOURCES!ssl.conf
>
> [2]
> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apache2/trusty/view/head:/debian/config-dir/sites-available/default-ssl
>

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand <ht...@velox.ch>]

On 04.09.2015 17:54, Rob Stradling wrote:
> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
> enabled.  Browsers aren't likely to start hard-failing by default until
> that % is a lot higher.
> 
> The vast majority of the servers that have OCSP stapling enabled are
> running IIS.  I claim that this is due to the fact that IIS enables OCSP
> stapling by default.

The relevant metric is the percentage of (initial) TLS handshakes with
stapled responses, not so much the percentage of servers with stapling
enabled. Judging from Mozilla's telemetry data for Firefox 39 and 40,
that percentage is still below 15%, and enabling stapling in an httpd
config file which gets used by a very small number of Apache httpd admins
(as opposed to those settings which go out to the world via [1] or [2])
doesn't look like a very effective way of achieving the goal of making
that percentage "a lot higher".

I'm also very sceptical that a higher percentage of handshakes with
stapled responses (how much exactly?) will lead browser vendors to
switch to hard fail - as the test-sspev.verisign.com example from my
previous message shows, they could do this for EV today already (even
Chrome tries querying the OCSP responder in this case). But none of them
does, often due to the fear of losing market share when being too strict
in enforcing TLS security (cf. the case of RC4 banning).

> I think you've misunderstood the "speed, speed, speed" argument.
> 
> If an OCSP response is delivered via stapling, then there's no need for
> the browser to block the TLS handshake whilst it obtains an OCSP
> response directly from the CA's OCSP responder.

No, I didn't misunderstand. That's very much the essence of the "speed,
speed, speed" argument - "our browser must be able to complete every TLS
handshake in under 100 ms"... even if for a specific server, it's just
one TLS handshake per day where it really matters.

> Stapling provides a noticeable speedup even if the browser never caches
> OCSP responses.

Fairly hypothetical point - I'm not aware of any common browser which
would use a cert validation library without an OCSP cache.

Kaspar


[1] https://git.centos.org/blob/rpms!httpd.git/c7/SOURCES!ssl.conf

[2] https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apache2/trusty/view/head:/debian/config-dir/sites-available/default-ssl

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Rob Stradling <ro...@comodo.com>]

On 04/09/15 15:59, Kaspar Brand wrote:
> On 02.09.2015 01:54, Jeff Trawick wrote:
>> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>>> today's situation, because this assessment misses the fact that with the
>>> current RFC-6066-based implementation, stapling can't fully achieve the
>>> goal of obviating OCSP queries for the clients - all publicly trusted
>>> CAs use hierarchies with at least two tiers these days, so effectively
>>> RFC 6961 support would be needed.
>> I plead ignorance, but I don't see that "can't fully achieve" is a blocker.
> 
> It's not a blocker, sure, but on the other hand, the benefit of enabling
> stapling by default isn't that big either - as long as browsers don't
> hard-fail when OCSP information isn't available.

Kaspar,

Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
enabled.  Browsers aren't likely to start hard-failing by default until
that % is a lot higher.

The vast majority of the servers that have OCSP stapling enabled are
running IIS.  I claim that this is due to the fact that IIS enables OCSP
stapling by default.

If we don't enable OCSP stapling by default in httpd, how are we going
to increase that % ?

> The "speed, speed,
> speed" argument (coming mostly from the browser vendors) isn't too
> convincing to me neither, as OCSP replies are usually cached for one
> or two days, and the typical user doesn't connect to thousands of
> new/different SSL sites per day.

I think you've misunderstood the "speed, speed, speed" argument.

If an OCSP response is delivered via stapling, then there's no need for
the browser to block the TLS handshake whilst it obtains an OCSP
response directly from the CA's OCSP responder.

Stapling provides a noticeable speedup even if the browser never caches
OCSP responses.

>> Is there a synopsis of which browsers support it for which types of 
>> certificates?
> 
> I don't think so, and it's probably also kind of a moving target. Chrome
> "supports" it for DV and OV as well - it will include a status_request
> extension in the TLS handshake by default -, but what I meant with
> "enforces" is that it won't care if there's no stapled response
> (Google's ceterum censeo used to be "Revocation doesn't work", which in
> 2012 lead to their implementation of CRL sets where the code is public,
> but "the process by which they are generated is not",
> https://dev.chromium.org/Home/chromium-security/crlsets).
> 
> For EV certs, the browser behavior is more uniform, though strict hard
> fail enforcement still isn't happening - for testing purposes, try
> this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
> and point the browser to
> https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
> With strict revocation checking enforced, no browser should ever render
> any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
> Test Page" (but most do when revocation information is not available,
> although some at least show warnings or downgrade the UI to non-EV).
> 
>> The motivation for putting it in trunk is so that the next release has 
>> stapling enabled in the default configurations, which essentially means 
>> that in some number of years (2-3?  I dunno) there will be a 
>> faster-growing number of httpd instances that have OCSP stapling enabled.
> 
> Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
> several years, I assume. What I don't like with this approach in any
> case, however, is that we as the devs decide on behalf of the admins,
> instead of letting them make an informed decision. I' really arguing
> in favor of something like this in httpd-ssl.conf.in:
> 
> --- snip ---
> #   SSL Engine Switch:
> #   Enable/Disable SSL for this virtual host.
> SSLEngine on
> 
> #  Server Certificate and Private Key:
> #  ...
> SSLCertificateFile "conf/server.crt"
> SSLCertificateKeyFile "conf/server.key"
> 
> #  OCSP Stapling:
> #  For SSL certificates which include an OCSP responder URI, mod_ssl
> #  can include revocation status information for the server's own
> #  certificate in the TLS handshake. Enabling this option requires
> #  outgoing connectivity to the CA's OCSP responder (usually running
> #  running on port 80, use "openssl x509 -in server.crt -text" to
> #  determine the exact URI), so this option is not enabled by default.
> #  The responder will be queried with the interval configured
> #  via SSLStaplingStandardCacheTimeout. For EV SSL certificates
> #  in particular, enabling this option is recommended/useful.
> #SSLUseStapling On
> --- snip ---
> 
> (i.e., move the SSLUseStapling directive closer to the cert settings,
> and make people aware of the outgoing connections this will trigger)
> 
>> Part of what makes the 2.4.x tangent is confusing is that sometimes your 
>> objections seem to be qualified on the assumption that 2.4.x would be 
>> updated.  Can we please drop 2.4.x from this conversation?
> 
> Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the
> basic question remains, though: is it acceptable that configuring an SSL
> certificate potentially triggers outgoing OCSP requests in mod_ssl,
> without having been explicitly instructed to do so by an admin? My view
> is still the same as in November 2014: admins should opt in for this
> feature, not be forced to opt out.
> 
>>>   It's also for this reason that I'm not in favor of a global
>>> "SSLUseStapling On", it should really be configured on a per-vhost basis.
>>
>> I don't follow.  What does that help?  With which attack vector does 
>> that improve the situation?
> 
> The point I was trying to make is that stapling is a per-certificate
> feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so
> it would be best if the admin becomes aware of it when configuring the cert.
> 
>>>> While I find the "not make accidental outgoing connections" argument
>>>> compelling (though perhaps with a different word than "accidental") the
>>>> server already takes actions that cause outgoing connections to services
>>>> not explicitly configured (DNS), and these occasionally cause problems.
>>> Are you referring to queries when doing PTR lookups for connecting
>>> clients? I think that's one of the very reasons why "HostnameLookups
>>> Off" was chosen for extra/httpd-default.conf.
>>
>> Not HostnameLookups; resolving ServerName at startup (configured or 
>> defaulted).
> 
> Ok, but I wouldn't consider DNS as being implicitly configured - after
> all, the resolvers are specified when network access on the OS level is
> configured (and DNS queries are sent to nameservers which are hopefully
> authoritative for lookups of hosts in the local net).
> 
>>>> Is there a principle at stake which could be followed consistently across
>>>> disparate features in how the server behaves a) with compiled in defaults
>>>> and minimal config, or b) with default/recommended config?
>>> The default configuration should not trigger unsolicited outgoing
>>> queries to untrusted systems, for both a) and b), that's how I would
>>> put it.
>>
>> Admin configures a certificate that has a domain name of attacker in the 
>> responder URI?  DNS entry for domain name in responder URI is taken over 
>> to point to attacker?
> 
> I was primarily trying to come up with a generic principle "which could
> be followed consistently across disparate features", so I'm not sure if
> considering specific attacks for the stapling case is the right way to
> continue the discussion... as another example, take the "Version check
> idea" thread from April 2015 [1] - even though there might not be an
> immediate threat if it were enabled by default, I really hope that httpd
> doesn't move into the direction of automatically enabling features
> requiring outgoing connectivity (without the admin's explicit
> instruction and consent).
> 
>> So forgetting 2.4.x, are you vetoing changing the trunk default config 
>> to enable stapling, and are the criteria of the veto both
>>
>> 1. The default configuration should not trigger unsolicited outgoing 
>> queries to untrusted systems, for both a) and b), that's how I would put it.
>> 2. Additionally, features enabled by default need to have sufficient 
>> coverage in the test framework.
> 
> For GA releases, my position is that both criteria apply, yes. If it's
> enabled in trunk, an alpha or a beta for getting broader testing exposure,
> then the docs and release notes/announcement should prominently say so
> (not only for OCSP stapling specifically, but in general for those
> features which may trigger unsolicited outgoing connections).
> 
> Kaspar
> 
> 
> [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3C7C89CDBA-B463-415F-82DA-DDD6AD88C38E@jaguNET.com%3E
> 

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand <ht...@velox.ch>]

On 05.09.2015 14:23, Jeff Trawick wrote:
> On 09/04/2015 10:59 AM, Kaspar Brand wrote:
>>> 1. The default configuration should not trigger unsolicited outgoing
>>> queries to untrusted systems, for both a) and b), that's how I would put it.
> 
> Re: "unsolicited":
> 
> Key words/phrases from the other end of the continuum: "unexpected by 
> many", "responder obtained from explicitly configured certificate"

The other end of the continuum would be "explicitly requested", in my
view. "unsolicited" = "not explicitly requested", that's what I intended
to say (and "explicitly" referring to something like "manually enabling
a directive").

> The unexpected aspect could be helped by a [notice] message at startup 
> indicating that an OCSP responder will be contacted for N certificates 
> due to the directive.  (If there is only one, an alternate message could 
> be displayed with the actual responder URL; we couldn't do that for 
> arbitrary numbers.)

IMO, not a sufficient method for justifying a "default on" setting
(configuring a Base64 encoded certificate blob through
SSLCertificateFile doesn't amount to explicitly configuring a responder
URI).

> Re: "untrusted":
> 
> The certificate and its content are untrusted in general?

Technically speaking, as long as mod_ssl doesn't validate the cert file
against a set of (locally configured) trust anchors, the complete file
is to be considered untrusted. An admin could have received a "fake
reply" for his CSR, where the public key perfectly matches the private
key, but the contents are bogus otherwise. Sure, he would most likely
realize this quite soon after having configured the cert and trying to
connect to his own server, but essentially, I wouldn't consider the
contents pointed to by an SSLCertificateFile directive as trusted.

> The content 
> is trusted but the responder URL is not what/who it seems? (I wasn't 
> sure where you were leading when you alluded to this in prior 
> correspondence.)

X.509v3 certs can have all sorts of "useful" extensions, and I wouldn't
consider all this information automatically trusted just because it's
signed by the CA (take the OU field in the subject DN as an example:
most CAs will have disclaimers stating that these fields are basically
"unverified").

With the OCSP URI in particular, an additional aspect of "untrusted" is
that resolving its IP address(es) relies on the DNS, i.e. a component
which can't be considered trusted when it is queried for records of
third-party domains.

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick <tr...@gmail.com>]

On 09/04/2015 10:59 AM, Kaspar Brand wrote:
> On 02.09.2015 01:54, Jeff Trawick wrote:
>> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>>> today's situation, because this assessment misses the fact that with the
>>> current RFC-6066-based implementation, stapling can't fully achieve the
>>> goal of obviating OCSP queries for the clients - all publicly trusted
>>> CAs use hierarchies with at least two tiers these days, so effectively
>>> RFC 6961 support would be needed.
>> I plead ignorance, but I don't see that "can't fully achieve" is a blocker.
> It's not a blocker, sure, but on the other hand, the benefit of enabling
> stapling by default isn't that big either - as long as browsers don't
> hard-fail when OCSP information isn't available. The "speed, speed,
> speed" argument (coming mostly from the browser vendors) isn't too
> convincing to me neither, as OCSP replies are usually cached for one
> or two days, and the typical user doesn't connect to thousands of
> new/different SSL sites per day.
>
>> Is there a synopsis of which browsers support it for which types of
>> certificates?
> I don't think so, and it's probably also kind of a moving target. Chrome
> "supports" it for DV and OV as well - it will include a status_request
> extension in the TLS handshake by default -, but what I meant with
> "enforces" is that it won't care if there's no stapled response
> (Google's ceterum censeo used to be "Revocation doesn't work", which in
> 2012 lead to their implementation of CRL sets where the code is public,
> but "the process by which they are generated is not",
> https://dev.chromium.org/Home/chromium-security/crlsets).
>
> For EV certs, the browser behavior is more uniform, though strict hard
> fail enforcement still isn't happening - for testing purposes, try
> this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
> and point the browser to
> https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
> With strict revocation checking enforced, no browser should ever render
> any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
> Test Page" (but most do when revocation information is not available,
> although some at least show warnings or downgrade the UI to non-EV).
>
>> The motivation for putting it in trunk is so that the next release has
>> stapling enabled in the default configurations, which essentially means
>> that in some number of years (2-3?  I dunno) there will be a
>> faster-growing number of httpd instances that have OCSP stapling enabled.
> Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
> several years, I assume. What I don't like with this approach in any
> case, however, is that we as the devs decide on behalf of the admins,
> instead of letting them make an informed decision. I' really arguing
> in favor of something like this in httpd-ssl.conf.in:
>
> --- snip ---
> #   SSL Engine Switch:
> #   Enable/Disable SSL for this virtual host.
> SSLEngine on
>
> #  Server Certificate and Private Key:
> #  ...
> SSLCertificateFile "conf/server.crt"
> SSLCertificateKeyFile "conf/server.key"
>
> #  OCSP Stapling:
> #  For SSL certificates which include an OCSP responder URI, mod_ssl
> #  can include revocation status information for the server's own
> #  certificate in the TLS handshake. Enabling this option requires
> #  outgoing connectivity to the CA's OCSP responder (usually running
> #  running on port 80, use "openssl x509 -in server.crt -text" to
> #  determine the exact URI), so this option is not enabled by default.
> #  The responder will be queried with the interval configured
> #  via SSLStaplingStandardCacheTimeout. For EV SSL certificates
> #  in particular, enabling this option is recommended/useful.
> #SSLUseStapling On
> --- snip ---
>
> (i.e., move the SSLUseStapling directive closer to the cert settings,
> and make people aware of the outgoing connections this will trigger)
>
>> Part of what makes the 2.4.x tangent is confusing is that sometimes your
>> objections seem to be qualified on the assumption that 2.4.x would be
>> updated.  Can we please drop 2.4.x from this conversation?
> Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the
> basic question remains, though: is it acceptable that configuring an SSL
> certificate potentially triggers outgoing OCSP requests in mod_ssl,
> without having been explicitly instructed to do so by an admin? My view
> is still the same as in November 2014: admins should opt in for this
> feature, not be forced to opt out.
>
>>>    It's also for this reason that I'm not in favor of a global
>>> "SSLUseStapling On", it should really be configured on a per-vhost basis.
>> I don't follow.  What does that help?  With which attack vector does
>> that improve the situation?
> The point I was trying to make is that stapling is a per-certificate
> feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so
> it would be best if the admin becomes aware of it when configuring the cert.
>
>>>> While I find the "not make accidental outgoing connections" argument
>>>> compelling (though perhaps with a different word than "accidental") the
>>>> server already takes actions that cause outgoing connections to services
>>>> not explicitly configured (DNS), and these occasionally cause problems.
>>> Are you referring to queries when doing PTR lookups for connecting
>>> clients? I think that's one of the very reasons why "HostnameLookups
>>> Off" was chosen for extra/httpd-default.conf.
>> Not HostnameLookups; resolving ServerName at startup (configured or
>> defaulted).
> Ok, but I wouldn't consider DNS as being implicitly configured - after
> all, the resolvers are specified when network access on the OS level is
> configured (and DNS queries are sent to nameservers which are hopefully
> authoritative for lookups of hosts in the local net).
>
>>>> Is there a principle at stake which could be followed consistently across
>>>> disparate features in how the server behaves a) with compiled in defaults
>>>> and minimal config, or b) with default/recommended config?
>>> The default configuration should not trigger unsolicited outgoing
>>> queries to untrusted systems, for both a) and b), that's how I would
>>> put it.
>> Admin configures a certificate that has a domain name of attacker in the
>> responder URI?  DNS entry for domain name in responder URI is taken over
>> to point to attacker?
> I was primarily trying to come up with a generic principle "which could
> be followed consistently across disparate features", so I'm not sure if
> considering specific attacks for the stapling case is the right way to
> continue the discussion... as another example, take the "Version check
> idea" thread from April 2015 [1] - even though there might not be an
> immediate threat if it were enabled by default, I really hope that httpd
> doesn't move into the direction of automatically enabling features
> requiring outgoing connectivity (without the admin's explicit
> instruction and consent).
>
>> So forgetting 2.4.x, are you vetoing changing the trunk default config
>> to enable stapling, and are the criteria of the veto both
>>
>> 1. The default configuration should not trigger unsolicited outgoing
>> queries to untrusted systems, for both a) and b), that's how I would put it.

Re: "unsolicited":

Key words/phrases from the other end of the continuum: "unexpected by 
many", "responder obtained from explicitly configured certificate"

The unexpected aspect could be helped by a [notice] message at startup 
indicating that an OCSP responder will be contacted for N certificates 
due to the directive.  (If there is only one, an alternate message could 
be displayed with the actual responder URL; we couldn't do that for 
arbitrary numbers.)

Re: "untrusted":

The certificate and its content are untrusted in general?  The content 
is trusted but the responder URL is not what/who it seems? (I wasn't 
sure where you were leading when you alluded to this in prior 
correspondence.)

>> 2. Additionally, features enabled by default need to have sufficient
>> coverage in the test framework.
> For GA releases, my position is that both criteria apply, yes. If it's
> enabled in trunk, an alpha or a beta for getting broader testing exposure,
> then the docs and release notes/announcement should prominently say so
> (not only for OCSP stapling specifically, but in general for those
> features which may trigger unsolicited outgoing connections).
>
> Kaspar
>
>
> [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3C7C89CDBA-B463-415F-82DA-DDD6AD88C38E@jaguNET.com%3E

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand <ht...@velox.ch>]

On 02.09.2015 01:54, Jeff Trawick wrote:
> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>> today's situation, because this assessment misses the fact that with the
>> current RFC-6066-based implementation, stapling can't fully achieve the
>> goal of obviating OCSP queries for the clients - all publicly trusted
>> CAs use hierarchies with at least two tiers these days, so effectively
>> RFC 6961 support would be needed.
> I plead ignorance, but I don't see that "can't fully achieve" is a blocker.

It's not a blocker, sure, but on the other hand, the benefit of enabling
stapling by default isn't that big either - as long as browsers don't
hard-fail when OCSP information isn't available. The "speed, speed,
speed" argument (coming mostly from the browser vendors) isn't too
convincing to me neither, as OCSP replies are usually cached for one
or two days, and the typical user doesn't connect to thousands of
new/different SSL sites per day.

> Is there a synopsis of which browsers support it for which types of 
> certificates?

I don't think so, and it's probably also kind of a moving target. Chrome
"supports" it for DV and OV as well - it will include a status_request
extension in the TLS handshake by default -, but what I meant with
"enforces" is that it won't care if there's no stapled response
(Google's ceterum censeo used to be "Revocation doesn't work", which in
2012 lead to their implementation of CRL sets where the code is public,
but "the process by which they are generated is not",
https://dev.chromium.org/Home/chromium-security/crlsets).

For EV certs, the browser behavior is more uniform, though strict hard
fail enforcement still isn't happening - for testing purposes, try
this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
and point the browser to
https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
With strict revocation checking enforced, no browser should ever render
any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
Test Page" (but most do when revocation information is not available,
although some at least show warnings or downgrade the UI to non-EV).

> The motivation for putting it in trunk is so that the next release has 
> stapling enabled in the default configurations, which essentially means 
> that in some number of years (2-3?  I dunno) there will be a 
> faster-growing number of httpd instances that have OCSP stapling enabled.

Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
several years, I assume. What I don't like with this approach in any
case, however, is that we as the devs decide on behalf of the admins,
instead of letting them make an informed decision. I' really arguing
in favor of something like this in httpd-ssl.conf.in:

--- snip ---
#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#  Server Certificate and Private Key:
#  ...
SSLCertificateFile "conf/server.crt"
SSLCertificateKeyFile "conf/server.key"

#  OCSP Stapling:
#  For SSL certificates which include an OCSP responder URI, mod_ssl
#  can include revocation status information for the server's own
#  certificate in the TLS handshake. Enabling this option requires
#  outgoing connectivity to the CA's OCSP responder (usually running
#  running on port 80, use "openssl x509 -in server.crt -text" to
#  determine the exact URI), so this option is not enabled by default.
#  The responder will be queried with the interval configured
#  via SSLStaplingStandardCacheTimeout. For EV SSL certificates
#  in particular, enabling this option is recommended/useful.
#SSLUseStapling On
--- snip ---

(i.e., move the SSLUseStapling directive closer to the cert settings,
and make people aware of the outgoing connections this will trigger)

> Part of what makes the 2.4.x tangent is confusing is that sometimes your 
> objections seem to be qualified on the assumption that 2.4.x would be 
> updated.  Can we please drop 2.4.x from this conversation?

Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the
basic question remains, though: is it acceptable that configuring an SSL
certificate potentially triggers outgoing OCSP requests in mod_ssl,
without having been explicitly instructed to do so by an admin? My view
is still the same as in November 2014: admins should opt in for this
feature, not be forced to opt out.

>>   It's also for this reason that I'm not in favor of a global
>> "SSLUseStapling On", it should really be configured on a per-vhost basis.
> 
> I don't follow.  What does that help?  With which attack vector does 
> that improve the situation?

The point I was trying to make is that stapling is a per-certificate
feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so
it would be best if the admin becomes aware of it when configuring the cert.

>>> While I find the "not make accidental outgoing connections" argument
>>> compelling (though perhaps with a different word than "accidental") the
>>> server already takes actions that cause outgoing connections to services
>>> not explicitly configured (DNS), and these occasionally cause problems.
>> Are you referring to queries when doing PTR lookups for connecting
>> clients? I think that's one of the very reasons why "HostnameLookups
>> Off" was chosen for extra/httpd-default.conf.
> 
> Not HostnameLookups; resolving ServerName at startup (configured or 
> defaulted).

Ok, but I wouldn't consider DNS as being implicitly configured - after
all, the resolvers are specified when network access on the OS level is
configured (and DNS queries are sent to nameservers which are hopefully
authoritative for lookups of hosts in the local net).

>>> Is there a principle at stake which could be followed consistently across
>>> disparate features in how the server behaves a) with compiled in defaults
>>> and minimal config, or b) with default/recommended config?
>> The default configuration should not trigger unsolicited outgoing
>> queries to untrusted systems, for both a) and b), that's how I would
>> put it.
> 
> Admin configures a certificate that has a domain name of attacker in the 
> responder URI?  DNS entry for domain name in responder URI is taken over 
> to point to attacker?

I was primarily trying to come up with a generic principle "which could
be followed consistently across disparate features", so I'm not sure if
considering specific attacks for the stapling case is the right way to
continue the discussion... as another example, take the "Version check
idea" thread from April 2015 [1] - even though there might not be an
immediate threat if it were enabled by default, I really hope that httpd
doesn't move into the direction of automatically enabling features
requiring outgoing connectivity (without the admin's explicit
instruction and consent).

> So forgetting 2.4.x, are you vetoing changing the trunk default config 
> to enable stapling, and are the criteria of the veto both
> 
> 1. The default configuration should not trigger unsolicited outgoing 
> queries to untrusted systems, for both a) and b), that's how I would put it.
> 2. Additionally, features enabled by default need to have sufficient 
> coverage in the test framework.

For GA releases, my position is that both criteria apply, yes. If it's
enabled in trunk, an alpha or a beta for getting broader testing exposure,
then the docs and release notes/announcement should prominently say so
(not only for OCSP stapling specifically, but in general for those
features which may trigger unsolicited outgoing connections).

Kaspar


[1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3C7C89CDBA-B463-415F-82DA-DDD6AD88C38E@jaguNET.com%3E

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick <tr...@gmail.com>]

On 08/30/2015 02:30 AM, Kaspar Brand wrote:
> On 28.08.2015 19:27, Jeff Trawick wrote:
>> For one, it is appropriate for the default config is there to enable
>> practices which are reasonable in most situations, and OCSP Stapling is
>> widely accepted as an appropriate feature for HTTP servers to enable.
> I have some doubts whether "widely accepted" is an accurate summary of
> today's situation, because this assessment misses the fact that with the
> current RFC-6066-based implementation, stapling can't fully achieve the
> goal of obviating OCSP queries for the clients - all publicly trusted
> CAs use hierarchies with at least two tiers these days, so effectively
> RFC 6961 support would be needed.
I plead ignorance, but I don't see that "can't fully achieve" is a blocker.

>   And given that the most popular
> browser only enforces revocation checking for EV certificates (certainly
> less than 10% of all SSL certs out there), the benefit of turning on
> stapling for DV/OV certs by default is not so apparent either.

Is there a synopsis of which browsers support it for which types of 
certificates?

>
> What wasn't mentioned in the original RFC [1], and what I'm still
> wondering about, is the primary motivation for enabling it on trunk?

The motivation for putting it in trunk is so that the next release has 
stapling enabled in the default configurations, which essentially means 
that in some number of years (2-3?  I dunno) there will be a 
faster-growing number of httpd instances that have OCSP stapling enabled.

Admins can of course enable it now, but people don't bother until 
something like SSLLabs starts dinging configurations that don't have it on.

>   As
> I wrote in my reply at that time, changing the default in trunk will
> hardly help in getting broader real-world testing results.

For now, it hardly helps.  As we approach a release and start talking 
about it and having alphas and betas, it helps a lot more because more 
than the same 20 people are trying it out.

>   If the
> plan is to propose a backport to 2.4.x soon afterwards, however, then I
> would certainly oppose unless systematic coverage for OCSP stapling is
> added to the test framework (enabling a feature by default in a GA
> release for which there is not a single test is a no go, IMO).

The point about adding tests is good.

I find this 2.4.x tangent disorienting, but maybe that's just me. (And 
even if 2.4.x default configs were changed, it would affect hardly 
anyone.  The people who build from source and just start using the 
latest configs every time probably aren't in control of many aspects of 
their system anyway.  Building and installing the normal way leaves you 
with the same configuration.)

Part of what makes the 2.4.x tangent is confusing is that sometimes your 
objections seem to be qualified on the assumption that 2.4.x would be 
updated.  Can we please drop 2.4.x from this conversation?

>
>> Also, strictly speaking, the default config does not have SSL enabled
>> anyway, and after manually enabling it OCSP responses won't be fetched
>> unless a certificate is configured which references an OCSP responder.
> It should be worth mentioning that the OCSP URI in a server cert is to
> be considered untrusted, as mod_ssl does not validate its own cert at
> startup.

I would think that the problem is if the hostname doesn't point where it 
is supposed to point, so the I/O can't be allowed to stall and mod_ssl 
and OpenSSL have to avoid assuming the data is well-formed.  Besides 
that, the admin and the browser own the rest.

>   It's also for this reason that I'm not in favor of a global
> "SSLUseStapling On", it should really be configured on a per-vhost basis.

I don't follow.  What does that help?  With which attack vector does 
that improve the situation?

>
>> While I find the "not make accidental outgoing connections" argument
>> compelling (though perhaps with a different word than "accidental") the
>> server already takes actions that cause outgoing connections to services
>> not explicitly configured (DNS), and these occasionally cause problems.
> Are you referring to queries when doing PTR lookups for connecting
> clients? I think that's one of the very reasons why "HostnameLookups
> Off" was chosen for extra/httpd-default.conf.

Not HostnameLookups; resolving ServerName at startup (configured or 
defaulted).
>
>> Is there a principle at stake which could be followed consistently across
>> disparate features in how the server behaves a) with compiled in defaults
>> and minimal config, or b) with default/recommended config?
> The default configuration should not trigger unsolicited outgoing
> queries to untrusted systems, for both a) and b), that's how I would
> put it.

Admin configures a certificate that has a domain name of attacker in the 
responder URI?  DNS entry for domain name in responder URI is taken over 
to point to attacker?

>   Additionally, features enabled by default need to have sufficient
> coverage in the test framework.

Coverage in the test framework is obviously a very good thing.

Is it your understanding that this high bar to enabling behavior in 
trunk without explicit configuration is currently followed for most such 
changes?

So forgetting 2.4.x, are you vetoing changing the trunk default config 
to enable stapling, and are the criteria of the veto both

1. The default configuration should not trigger unsolicited outgoing 
queries to untrusted systems, for both a) and b), that's how I would put it.
2. Additionally, features enabled by default need to have sufficient 
coverage in the test framework.

>
>> If enabling stapling were more closely tied in the configuration language
>> to configuring a certificate, which with "SSLUseStapling On" is the user
>> action that makes mod_ssl talk to a responder, would that help the end
>> user?  (Controlling stapling parameters on a per-certificate basis is
>> valuable anyway since you can have multiple certificates per vhost,
>> possibly with different responders.)
> It's not very common to configure multiple certs for a single vhost, I
> guess - mainly due to the single-chain-only limitation in OpenSSL up to
> 1.0.1. I wouldn't put too much effort into making it a per-certificate
> setting (seems relatively complex to implement, at least at first glance).
>
> Kaspar
>
> [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201410.mbox/%3CCAKUrXK6k01WGqF8z6F3YBNbanbTaOSHbbzwSi2O3H3u03_mvUw%40mail.gmail.com%3E

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand <ht...@velox.ch>]

On 28.08.2015 19:27, Jeff Trawick wrote:
> For one, it is appropriate for the default config is there to enable
> practices which are reasonable in most situations, and OCSP Stapling is
> widely accepted as an appropriate feature for HTTP servers to enable.

I have some doubts whether "widely accepted" is an accurate summary of
today's situation, because this assessment misses the fact that with the
current RFC-6066-based implementation, stapling can't fully achieve the
goal of obviating OCSP queries for the clients - all publicly trusted
CAs use hierarchies with at least two tiers these days, so effectively
RFC 6961 support would be needed. And given that the most popular
browser only enforces revocation checking for EV certificates (certainly
less than 10% of all SSL certs out there), the benefit of turning on
stapling for DV/OV certs by default is not so apparent either.

What wasn't mentioned in the original RFC [1], and what I'm still
wondering about, is the primary motivation for enabling it on trunk? As
I wrote in my reply at that time, changing the default in trunk will
hardly help in getting broader real-world testing results. If the
plan is to propose a backport to 2.4.x soon afterwards, however, then I
would certainly oppose unless systematic coverage for OCSP stapling is
added to the test framework (enabling a feature by default in a GA
release for which there is not a single test is a no go, IMO).

> Also, strictly speaking, the default config does not have SSL enabled
> anyway, and after manually enabling it OCSP responses won't be fetched
> unless a certificate is configured which references an OCSP responder.

It should be worth mentioning that the OCSP URI in a server cert is to
be considered untrusted, as mod_ssl does not validate its own cert at
startup. It's also for this reason that I'm not in favor of a global
"SSLUseStapling On", it should really be configured on a per-vhost basis.

> While I find the "not make accidental outgoing connections" argument
> compelling (though perhaps with a different word than "accidental") the
> server already takes actions that cause outgoing connections to services
> not explicitly configured (DNS), and these occasionally cause problems.

Are you referring to queries when doing PTR lookups for connecting
clients? I think that's one of the very reasons why "HostnameLookups
Off" was chosen for extra/httpd-default.conf.

> Is there a principle at stake which could be followed consistently across
> disparate features in how the server behaves a) with compiled in defaults
> and minimal config, or b) with default/recommended config?

The default configuration should not trigger unsolicited outgoing
queries to untrusted systems, for both a) and b), that's how I would
put it. Additionally, features enabled by default need to have sufficient
coverage in the test framework.

> If enabling stapling were more closely tied in the configuration language
> to configuring a certificate, which with "SSLUseStapling On" is the user
> action that makes mod_ssl talk to a responder, would that help the end
> user?  (Controlling stapling parameters on a per-certificate basis is
> valuable anyway since you can have multiple certificates per vhost,
> possibly with different responders.)

It's not very common to configure multiple certs for a single vhost, I
guess - mainly due to the single-chain-only limitation in OpenSSL up to
1.0.1. I wouldn't put too much effort into making it a per-certificate
setting (seems relatively complex to implement, at least at first glance).

Kaspar

[1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201410.mbox/%3CCAKUrXK6k01WGqF8z6F3YBNbanbTaOSHbbzwSi2O3H3u03_mvUw%40mail.gmail.com%3E

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick <tr...@gmail.com>]

On 08/29/2015 08:10 PM, William A Rowe Jr wrote:
>
> On Aug 29, 2015 1:49 PM, "Jeff Trawick" <trawick@gmail.com 
> <ma...@gmail.com>> wrote:
> >
> > On 08/28/2015 04:17 PM, Tim Bannister wrote:
> >>
> >> Jeff Trawick <trawick@gmail.com <ma...@gmail.com>> wrote:
> >>>
> >>>
> >>> As of now there's still a veto on my suggestion of enabling 
> stapling by
> >>> default in the httpd trunk config.
> >>
> >> Would that default need to be backported to 2.4.x?
> >
> >
> > "need"?  No; 2.4.x is a separate consideration.
> >
> >
> >> If it can be on by default for trunk/2.5.x, and off by default in 
> earlier releases, this should surprise very few users.
> >>
> >> People upgrading from an older release could get a mild surprise, 
> but at the same time if you upgrade from 2.4.x to 2.5.x then surprises 
> aren't all that surprising.
> >>
> >> Overall I think the big question mark is around backport to 2.4.x 
> rather than the change to httpd trunk.
>
> I thought this question was largely resolved, that we wouldn't want 
> subversion updates to break a users config unexpectedly.  POLS.
>
You know this, but just for completeness: 
Subversion-update-breaks-users-config is when compiled-in default 
behavior changes, which could affect configurations with no stapling 
directive, which wasn't proposed even for trunk.

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr <wr...@rowe-clan.net>]

On Aug 29, 2015 1:49 PM, "Jeff Trawick" <tr...@gmail.com> wrote:
>
> On 08/28/2015 04:17 PM, Tim Bannister wrote:
>>
>> Jeff Trawick <tr...@gmail.com> wrote:
>>>
>>>
>>> As of now there's still a veto on my suggestion of enabling stapling by
>>> default in the httpd trunk config.
>>
>> Would that default need to be backported to 2.4.x?
>
>
> "need"?  No; 2.4.x is a separate consideration.
>
>
>> If it can be on by default for trunk/2.5.x, and off by default in
earlier releases, this should surprise very few users.
>>
>> People upgrading from an older release could get a mild surprise, but at
the same time if you upgrade from 2.4.x to 2.5.x then surprises aren't all
that surprising.
>>
>> Overall I think the big question mark is around backport to 2.4.x rather
than the change to httpd trunk.

I thought this question was largely resolved, that we wouldn't want
subversion updates to break a users config unexpectedly.  POLS.

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick <tr...@gmail.com>]

On 08/28/2015 04:17 PM, Tim Bannister wrote:
> Jeff Trawick <tr...@gmail.com> wrote:
>>
>> As of now there's still a veto on my suggestion of enabling stapling by
>> default in the httpd trunk config.
> Would that default need to be backported to 2.4.x?

"need"?  No; 2.4.x is a separate consideration.

> If it can be on by default for trunk/2.5.x, and off by default in earlier releases, this should surprise very few users.
>
> People upgrading from an older release could get a mild surprise, but at the same time if you upgrade from 2.4.x to 2.5.x then surprises aren't all that surprising.
>
> Overall I think the big question mark is around backport to 2.4.x rather than the change to httpd trunk.
>
> Tim

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Tim Bannister <is...@c8h10n4o2.org.uk>]

Jeff Trawick <tr...@gmail.com> wrote:
>
>
>As of now there's still a veto on my suggestion of enabling stapling by
>default in the httpd trunk config.

Would that default need to be backported to 2.4.x?
If it can be on by default for trunk/2.5.x, and off by default in earlier releases, this should surprise very few users.

People upgrading from an older release could get a mild surprise, but at the same time if you upgrade from 2.4.x to 2.5.x then surprises aren't all that surprising.

Overall I think the big question mark is around backport to 2.4.x rather than the change to httpd trunk.

Tim
-- 
Tim Bannister – isoma@c8h10n4o2.org.uk

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick <tr...@gmail.com>]

On Mon, Jul 13, 2015 at 3:08 AM, Ruediger Pluem <rp...@apache.org> wrote:

>
>
> On 07/11/2015 08:55 PM, William A Rowe Jr wrote:
>
> > If you are suggesting we shouldn't change the compiled-in default, I can
> > agree, POLS (Principal Of Least Surprise).  If you are suggesting the
> default
> > config shouldn't reflect the ability to efficiently handle OCSP by
> stapling, here
> > I think we would disagree.
>
> This something I can agree with: Leave the default compiled in to off and
> in the configuration distributed by us have it
> set to on.
>
> Regards
>
> Rüdiger
>
>
As of now there's still a veto on my suggestion of enabling stapling by
default in the httpd trunk config.  Of Kaspar's justifications, I think
this is the text that remains of his clarifying post on July 11, ignoring
the license reference:

"a) by default, an HTTP server is supposed to process *incoming* requests,
not make accidental outgoing connections in addition (at least not unless
it's explicitly instructed to do so);"

(I sincerely hope I haven't misconstrued the situation or missed anything
Kaspar intended.)

Those of us in favor of enabling stapling by default for those using the
default configs wouldn't have any trouble finding opposite justifications.
For one, it is appropriate for the default config is there to enable
practices which are reasonable in most situations, and OCSP Stapling is
widely accepted as an appropriate feature for HTTP servers to enable.
Also, strictly speaking, the default config does not have SSL enabled
anyway, and after manually enabling it OCSP responses won't be fetched
unless a certificate is configured which references an OCSP responder.

While I find the "not make accidental outgoing connections" argument
compelling (though perhaps with a different word than "accidental") the
server already takes actions that cause outgoing connections to services
not explicitly configured (DNS), and these occasionally cause problems.
Looking up the values of the User and Group directives can possibly invoke
one of multiple different network services depending on the system
configuration.  But I admit that's just fishing for a counter argument.

Any suggestions for breaking the apparent impasse?

Is there a principle at stake which could be followed consistently across
disparate features in how the server behaves a) with compiled in defaults
and minimal config, or b) with default/recommended config?

If enabling stapling were more closely tied in the configuration language
to configuring a certificate, which with "SSLUseStapling On" is the user
action that makes mod_ssl talk to a responder, would that help the end
user?  (Controlling stapling parameters on a per-certificate basis is
valuable anyway since you can have multiple certificates per vhost,
possibly with different responders.)

Thanks,

Jeff
-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Ruediger Pluem <rp...@apache.org>]

On 07/11/2015 08:55 PM, William A Rowe Jr wrote:

> If you are suggesting we shouldn't change the compiled-in default, I can
> agree, POLS (Principal Of Least Surprise).  If you are suggesting the default 
> config shouldn't reflect the ability to efficiently handle OCSP by stapling, here 
> I think we would disagree.

This something I can agree with: Leave the default compiled in to off and in the configuration distributed by us have it
set to on.

Regards

Rüdiger

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr <wr...@rowe-clan.net>]

We can have a dialog about the best behavior of our default config.
However...

On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand <ht...@velox.ch>
wrote:

> On 01.07.2015 14:27, Ben Laurie wrote:
> > On 1 November 2014 at 09:05, Kaspar Brand <ht...@velox.ch>
> wrote:
> >> The fundamental objection I have to enabling stapling by default in our
> >> GA releases is that it would enable a "phoning home" feature (to the
> >> CA's OCSP responders) as a side effect of configuring a certificate.
> >> This is a setting I consider unacceptable for software published by the
> >> Apache HTTP Server project - the default must be opt-in, not opt-out.
> >
> > I've just become aware of this objection and would like to understand
> > the thinking behind it. Firstly, it seems strange to call this
> > "phoning home", a term that _usually_ means connecting to the vendor
> > of the s/w.
> >
> > But more importantly, what harm is there in a server connecting to the
> > OCSP responders for the certificates it is serving? Why is this
> > "unacceptable"?
>
> It's unacceptable for at least two reasons: a) by default, an HTTP
> server is supposed to process *incoming* requests, not make accidental
> outgoing connections in addition (at least not unless it's explicitly
> instructed to do so); b) there's no statement in our license with an
> explicit caveat on such a side effect ("when relying on our default
> settings, configuring a site with an SSL server certificate may result
> in unsolicited outgoing HTTP requests" - and no, I do not want to see
> our license amended by things like that).
>

Our License says nothing about accepting requests, either.  Licenses
don't express these mechanics.  They define the terms for users to
"reproduce, prepare Derivative Works of, publicly display, publicly
perform,
sublicense, and distribute" the work and its derivatives, and the
corresponding
patent rights as well.

A number of ASF works are servers.  A number are clients.  A number are
both clients and servers.  OCSP is hardly an accidental request, any more
than
the proxy module requests.  And in forwarding requests to https proxy
servers,
(another side effect) verifying the OCSP identity of the connected server
is
hardly an unexpected side effect, it's a characteristic of the protocol
(that
backend *server* advertised OCSP validation - stapled or indirect, and that
the *user* configured the certificate for OCSP validation).  Third party
OCSP
validation is so problematic that OCSP stapling is a blindly obvious
enhancement
that will far offset the routing configuration issues it also inspires

So your premise above is, well, outright silly.


> I maintain my objection to uncommenting "#SSLUseStapling On" in our
> default config in httpd-ssl.conf.in - and for the record, also to
> changing code, be that in ssl_engine_config.c:modssl_ctx_init() or
> elsewhere. Those keen on enabling it by default on behalf of the users
> ("because we know what is good for you") are free to lobby with the OS
> vendors to have their package defaults changed.
>

You are welcome to object, and I think Ben's reply here to your thoughts
and observations, particularly your early one, since he is advocating for
this
change and this would move the dialog along to a conclusion.

Contrawise, httpd project can do the 'right thing' from our perspective,
and
the downstream distributors can correspondingly disable it.

Moreso, any enterprise so affected already is configuring httpd to their own
organization's standards and policies.

If you are suggesting we shouldn't change the compiled-in default, I can
agree, POLS (Principal Of Least Surprise).  If you are suggesting the
default
config shouldn't reflect the ability to efficiently handle OCSP by
stapling, here
I think we would disagree.

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand <ht...@velox.ch>]

On 01.07.2015 14:27, Ben Laurie wrote:
> On 1 November 2014 at 09:05, Kaspar Brand <ht...@velox.ch> wrote:
>> The fundamental objection I have to enabling stapling by default in our
>> GA releases is that it would enable a "phoning home" feature (to the
>> CA's OCSP responders) as a side effect of configuring a certificate.
>> This is a setting I consider unacceptable for software published by the
>> Apache HTTP Server project - the default must be opt-in, not opt-out.
> 
> I've just become aware of this objection and would like to understand
> the thinking behind it. Firstly, it seems strange to call this
> "phoning home", a term that _usually_ means connecting to the vendor
> of the s/w.
> 
> But more importantly, what harm is there in a server connecting to the
> OCSP responders for the certificates it is serving? Why is this
> "unacceptable"?

It's unacceptable for at least two reasons: a) by default, an HTTP
server is supposed to process *incoming* requests, not make accidental
outgoing connections in addition (at least not unless it's explicitly
instructed to do so); b) there's no statement in our license with an
explicit caveat on such a side effect ("when relying on our default
settings, configuring a site with an SSL server certificate may result
in unsolicited outgoing HTTP requests" - and no, I do not want to see
our license amended by things like that).

I maintain my objection to uncommenting "#SSLUseStapling On" in our
default config in httpd-ssl.conf.in - and for the record, also to
changing code, be that in ssl_engine_config.c:modssl_ctx_init() or
elsewhere. Those keen on enabling it by default on behalf of the users
("because we know what is good for you") are free to lobby with the OS
vendors to have their package defaults changed.

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Ben Laurie <be...@links.org>]

On 1 November 2014 at 09:05, Kaspar Brand <ht...@velox.ch> wrote:
> On 30.10.2014 15:51, Jeff Trawick wrote:
>> IMO the present concerns with OCSP Stapling are:
>>
>> * not so clear that it has seen enough real-world testing; commented out
>> sample configs and better documentation will help, as will enabling by
>> default in trunk (just a little?)
>> * related bugs 57121 and 57131
>>
>> A simple way to help with the broader issue raised in 57131, as well as fix
>> 57121, is to not hold the global mutex while communicating with a
>> responder, with other handshakes completing with the existing response in
>> the cache as long as it is valid, or with the appropriate
>> communication-error response otherwise (some details omitted ;) ).
>>
>> There are a few other bugs currently open for less severe issues.
>>
>> TIA for your comments!
>
> I'm -1 on this, under the assumption that 2.4.x would eventually also
> turn it on by default (yes, I'm aware of PR 50740, and CABF trying to
> push this).
>
> While enabling it by default on trunk probably doesn't change much (in
> my experience, very, very few people really compile and run trunk, I
> would even claim that this applies to http devs, too), I feel that the
> approach of "let's turn it on by default and see how many people run
> into problems" (and bring them up on httpd-users etc.) isn't right.
> Those interested in achieving a more widespread use should specifically
> test OCSP stapling with mod_ssl, report their findings, file PRs on
> Bugzilla (and if possible, also submit suitable patches).
>
> The fundamental objection I have to enabling stapling by default in our
> GA releases is that it would enable a "phoning home" feature (to the
> CA's OCSP responders) as a side effect of configuring a certificate.
> This is a setting I consider unacceptable for software published by the
> Apache HTTP Server project - the default must be opt-in, not opt-out.

I've just become aware of this objection and would like to understand
the thinking behind it. Firstly, it seems strange to call this
"phoning home", a term that _usually_ means connecting to the vendor
of the s/w.

But more importantly, what harm is there in a server connecting to the
OCSP responders for the certificates it is serving? Why is this
"unacceptable"?

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand <ht...@velox.ch>]

On 30.10.2014 15:51, Jeff Trawick wrote:
> IMO the present concerns with OCSP Stapling are:
> 
> * not so clear that it has seen enough real-world testing; commented out
> sample configs and better documentation will help, as will enabling by
> default in trunk (just a little?)
> * related bugs 57121 and 57131
> 
> A simple way to help with the broader issue raised in 57131, as well as fix
> 57121, is to not hold the global mutex while communicating with a
> responder, with other handshakes completing with the existing response in
> the cache as long as it is valid, or with the appropriate
> communication-error response otherwise (some details omitted ;) ).
> 
> There are a few other bugs currently open for less severe issues.
> 
> TIA for your comments!

I'm -1 on this, under the assumption that 2.4.x would eventually also
turn it on by default (yes, I'm aware of PR 50740, and CABF trying to
push this).

While enabling it by default on trunk probably doesn't change much (in
my experience, very, very few people really compile and run trunk, I
would even claim that this applies to http devs, too), I feel that the
approach of "let's turn it on by default and see how many people run
into problems" (and bring them up on httpd-users etc.) isn't right.
Those interested in achieving a more widespread use should specifically
test OCSP stapling with mod_ssl, report their findings, file PRs on
Bugzilla (and if possible, also submit suitable patches).

The fundamental objection I have to enabling stapling by default in our
GA releases is that it would enable a "phoning home" feature (to the
CA's OCSP responders) as a side effect of configuring a certificate.
This is a setting I consider unacceptable for software published by the
Apache HTTP Server project - the default must be opt-in, not opt-out.

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick <tr...@gmail.com>]

On Thu, Oct 30, 2014 at 4:54 PM, Hanno Böck <ha...@hboeck.de> wrote:

> Am Thu, 30 Oct 2014 10:51:15 -0400
> schrieb Jeff Trawick <tr...@gmail.com>:
>
> >  #   Define a relatively small cache for OCSP Stapling using
> >  #   the same mechanism that is used for the SSL session cache
> >  #   above.  If stapling is used with more than a few certificates,
> >  #   the size may need to be increased.  (AH01929 will be logged.)
>
> Could this be made a bit more precise?
> What's "more than a few certificates"? Preferrably there should be some
> rough calculation (certs*Xkb) that gives a safe margin for the space.
>

I don't know if a tighter language will actually help.

* The 32K and "few" roughly matches the largest per-certificate responses
that mod_ssl can handle.  So that's the "safe margin".
* I have read that the responses can vary from a few hundred bytes to a few
K bytes, and I have seen a few in the 500-600 byte range, so I expect that
for most cases there will actually be a "huge margin" with the default
config.

With LogLevel TraceN you can see the cache stores for the responses.




>
> --
> Hanno Böck
> http://hboeck.de/
>
> mail/jabber: hanno@hboeck.de
> GPG: BBB51E42
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Hanno Böck <ha...@hboeck.de>]

Am Thu, 30 Oct 2014 10:51:15 -0400
schrieb Jeff Trawick <tr...@gmail.com>:

>  #   Define a relatively small cache for OCSP Stapling using
>  #   the same mechanism that is used for the SSL session cache
>  #   above.  If stapling is used with more than a few certificates,
>  #   the size may need to be increased.  (AH01929 will be logged.)

Could this be made a bit more precise?
What's "more than a few certificates"? Preferrably there should be some
rough calculation (certs*Xkb) that gives a safe margin for the space.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42