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 <httpd-dev.2...@velox.ch>
wrote:
> On 01.07.2015 14:27, Ben Laurie wrote:
> > On 1 November 2014 at 09:05, Kaspar Brand <httpd-dev.2...@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.
