httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Date Fri, 28 Aug 2015 17:27:42 GMT
On Mon, Jul 13, 2015 at 3:08 AM, Ruediger Pluem <> 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.)


Born in Roswell... married an alien...

View raw message