httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Date Sat, 11 Jul 2015 18:55:28 GMT
We can have a dialog about the best behavior of our default config.

On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand <>

> On 01.07.2015 14:27, Ben Laurie wrote:
> > On 1 November 2014 at 09:05, Kaspar Brand <>
> 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
sublicense, and distribute" the work and its derivatives, and the
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
the proxy module requests.  And in forwarding requests to https proxy
(another side effect) verifying the OCSP identity of the connected server
hardly an unexpected side effect, it's a characteristic of the protocol
backend *server* advertised OCSP validation - stapled or indirect, and that
the *user* configured the certificate for OCSP validation).  Third party
validation is so problematic that OCSP stapling is a blindly obvious
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 - 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
change and this would move the dialog along to a conclusion.

Contrawise, httpd project can do the 'right thing' from our perspective,
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
config shouldn't reflect the ability to efficiently handle OCSP by
stapling, here
I think we would disagree.

View raw message