On 28.08.2015 19:27, Jeff Trawick wrote: > 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.
I have some doubts whether "widely accepted" is an accurate summary of today's situation, because this assessment misses the fact that with the current RFC-6066-based implementation, stapling can't fully achieve the goal of obviating OCSP queries for the clients - all publicly trusted CAs use hierarchies with at least two tiers these days, so effectively RFC 6961 support would be needed. And given that the most popular browser only enforces revocation checking for EV certificates (certainly less than 10% of all SSL certs out there), the benefit of turning on stapling for DV/OV certs by default is not so apparent either. What wasn't mentioned in the original RFC [1], and what I'm still wondering about, is the primary motivation for enabling it on trunk? As I wrote in my reply at that time, changing the default in trunk will hardly help in getting broader real-world testing results. If the plan is to propose a backport to 2.4.x soon afterwards, however, then I would certainly oppose unless systematic coverage for OCSP stapling is added to the test framework (enabling a feature by default in a GA release for which there is not a single test is a no go, IMO). > 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. It should be worth mentioning that the OCSP URI in a server cert is to be considered untrusted, as mod_ssl does not validate its own cert at startup. It's also for this reason that I'm not in favor of a global "SSLUseStapling On", it should really be configured on a per-vhost basis. > 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. Are you referring to queries when doing PTR lookups for connecting clients? I think that's one of the very reasons why "HostnameLookups Off" was chosen for extra/httpd-default.conf. > 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? The default configuration should not trigger unsolicited outgoing queries to untrusted systems, for both a) and b), that's how I would put it. Additionally, features enabled by default need to have sufficient coverage in the test framework. > 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.) It's not very common to configure multiple certs for a single vhost, I guess - mainly due to the single-chain-only limitation in OpenSSL up to 1.0.1. I wouldn't put too much effort into making it a per-certificate setting (seems relatively complex to implement, at least at first glance). Kaspar [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201410.mbox/%3CCAKUrXK6k01WGqF8z6F3YBNbanbTaOSHbbzwSi2O3H3u03_mvUw%40mail.gmail.com%3E
