On Jul 3, 2015 9:37 AM, "Rob Stradling" <rob.stradl...@comodo.com> wrote: > > On 03/07/15 11:13, Plüm, Rüdiger, Vodafone Group wrote: > <snip> > >> Thanks for the detailed explanation. So yes OCSP stapling is really beneficial >> if it is possible for the server admin to set it up. But it likely requires additional >> configuration steps outside of httpd to make the OCSP responder reachable (like firewall clearances) >> and leads to otherwise strange "slow" responses if this is not prepared. >> Another obstacle with the current stapling code is that the connection to the OCSP responder of the >> CA needs to happen directly and cannot be done via a proxy. >> Hence I agree with Kaspar that it should be off by default. > > > Given the current stapling code, that's fair enough. > > Is it feasible to engineer around these issues so that stapling could be enabled by default in some future httpd release? If not, what's the showstopper?
This was Ben's suggestion, top post. At this project, the trunk of svn is the next major or minor version, e g 3.0 or 2.6 eventually, that would be after a 2.5 beta cycle to hash out the kinks. I'm strongly in favor of enabling this by default as a down-the-road opportunity, and current concerns can be better addressed if everyone who is touching that future 2.5.0+ version is looking at all issues that arise. httpd 2.6/3.0 may well disable plaintext out-of-the-box, with a default tls listener, sni named vhosts and http/2 enabled by default. Ignoring stapling due to enterprises that have no other reason to start supporting ocsp and other modern validation and verification tools should not be a primary goal, from the forward looking convention. If it can't be solved with code, then it can always be changed back to default of disabled before GA.
