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 <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.
>
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/
