Re: [RFC] Enable OCSP Stapling by default in httpd trunk
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
Bug report for Apache httpd-2 [2015/08/30]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 7483|Ass|Enh|2002-03-26|Add FileAction directive to assign a cgi interpret| | 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity| | 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |11294|New|Enh|2002-07-30|desired vhost_alias option| |11580|Opn|Enh|2002-08-09|generate Content-Location headers | |12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long| |12680|New|Enh|2002-09-16|Digest authentication with integrity protection | |13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences| |13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation | |14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR| |14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst| |14922|Inf|Enh|2002-11-28|target is currently hardcoded to 'apache2' | |15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne| |16761|Inf|Nor|2003-02-04|CustomLog with pipe spawns process during config | |16802|New|Enh|2003-02-05|Additional AllowOverride directive Restrict | |16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.| |17107|New|Min|2003-02-16|Windows should not install printenv | |17114|New|Enh|2003-02-17|Please add strip and install-strip targets to Make| |17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi| |17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header| |18325|New|Enh|2003-03-25|PAM support for suEXEC| |18334|Inf|Cri|2003-03-25|Server crashes when authenticating users against L| |18497|New|Min|2003-03-30|configure --help gives wrong default for sysconfdi| |19043|New|Min|2003-04-15|Interesting interaction between cern_meta module a| |19670|New|Enh|2003-05-05|content type header supplied upon PUT is thrown aw| |20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment | |21253|New|Nor|2003-07-01|Mime magic doesn't continue if type is specifed fo| |21260|New|Nor|2003-07-02|CacheMaxExpire directive not enforced ! | |21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut| |22138|Inf|Cri|2003-08-05|Webdav is not preccessing special chars right.| |22237|New|Enh|2003-08-08|option to disable ServerSignature on index pages | |22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down| |22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7| |22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header | |23167|Inf|Cri|2003-09-14|--enable-layout never goes to apr apr-util| |23181|New|Nor|2003-09-15|Status 304 (Not modified) and chunking leads to an| |23238|New|Cri|2003-09-18|non-async-signal-safe operations from signal handl| |23330|New|Enh|2003-09-22|Enhance ApacheMonitor to view and control Tomcat s| |23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54| |24031|New|Enh|2003-10-23|Passphrase protected private key in SSLProxyMachin| |24095|Opn|Cri|2003-10-24|ERROR Parent: child process exited with status 32| |24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact| |24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g| |25014|New|Enh|2003-11-26|A flexible interface for mod_log_config | |25201|New|Enh|2003-12-04|Provide Cache Purge operation | |25240|Inf|Enh|2003-12-05|SSL Library Error: 336105671 logged as information| |25435|New|Enh|2003-12-11|sethandler and directoryindex not playing nice| |25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files | |25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP | |25543|Inf|Nor|2003-12-15|mod_proxy_ajp overwrites existing response headers|
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
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/
Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk
On 29.08.2015 17:56, olli hauer wrote: On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote: 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. Not tested, but looking at the mod_ssl doc it seems SSLStaplingForceURL can be used to proxy requests to the OCSP responder(s) http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingforceurl In case SSLStaplingForceURL can be used to force OCSP requests via proxy it would be nice to add something like the following patch before enabling OCSP stapling as default. It can't be used like this, as pointed out in [1]. Its main use is for certs which do not include an OCSP URI at all, so configuring SSLStaplingForceURL at the global level doesn't make much sense - you would have to run a transparent OCSP proxy at that URL (mod_ssl will just send plain OCSP requests to this address). Kaspar [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201411.mbox/%3C5454A1FE.6060204%40velox.ch%3E
