Kaspar Brand <httpd-dev.2...@velox.ch> wrote: > 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.
This is not true. In the case of Firefox, and I believe Chrome, it was decided that the website is responsible for delivering the OCSP response (via stapling) for the end-entity, and the browser is responsible for getting the revocation info for the intermediates *in some unspecified way*. In practice, that way is CRLSets. I think MSIE is or has also started moving to that model. In particular, browser makers aren't interested in RFC 6961 because of it is a poor performance trade-off and also never implemented. > 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. > This is a chicken-and-egg problem. The proposed Must-Staple feature makes OCSP useful. Obviously Must-Staple only works if the server staples the response. Conversely, without Must-Staple, OCSP is useless in browsers. > 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? The main motivation for OCSP stapling is to demonstrate that OCSP stapling works in a widespread way, so that browsers can start implementing the Must-Staple feature and gather useful metrics about the effects, including any possible negative side effects. > As I wrote in my reply at that time, changing the default in trunk will > hardly help in getting broader real-world testing results. It has to be changed on Trunk before it can be changed anywhere else, right? > 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). > I agree. And, to be perfectly honest, there are a lot of things that can go wrong with OCSP stapling and I've yet to see an implementation without a serious flaw. > 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. > Using that argument, it isn't safe to use the server's end-entity certificate either, because it hasn't been checked for validity. In particular, it hasn't been checked for revocation! The Heartbleed vulnerability had such a huge impact partially because there was no **effective** and easy-to-use way for servers to revoke certificates. We need to find a solution to revocation and I think that Apache enabling OCSP stapling by default is the next step towards a solution. > The default configuration should not trigger unsolicited outgoing > queries to untrusted systems, for both a) and b), that's how I would > put it. Look at IIS, which has been doing OCSP stapling by default, without significant problems, for many years now. Has anybody really been harmed by IIS's default? I don't think so. I think this is an instance of the perfect being the enemy of the good. > Additionally, features enabled by default need to have sufficient > coverage in the test framework. > Again, I agree. In case it would be helpful: When I was at Mozilla, my team created a new certificate verification library for Firefox. That includes a complete implementation of OCSP verification. It also includes a small test suite for OCSP verification. We intentionally licensed it under the Apache 2.0 license so that Apache could use the code, if Apache wants to use it. If nothing else, the OCSP tests [3] might be a useful model for Apache's tests. After I left Mozilla, I separated out the implementation from Firefox's repository and made it available on GitHub: [1]. I spent some time making that code work with OpenSSL in a branch [2]. [1] https://github.com/briansmith/mozillapkix [2] https://github.com/briansmith/mozillapkix/tree/feature/openssl [3] https://github.com/briansmith/mozillapkix/blob/master/test/gtest/pkixocsp_VerifyEncodedOCSPResponse.cpp Cheers, Brian -- https://briansmith.org/
