On Mon, Jul 13, 2015 at 3:08 AM, Ruediger Pluem <rpl...@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/
