On 04/09/15 15:59, Kaspar Brand wrote: > On 02.09.2015 01:54, Jeff Trawick wrote: >> On 08/30/2015 02:30 AM, Kaspar Brand wrote: >>> 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. >> I plead ignorance, but I don't see that "can't fully achieve" is a blocker. > > It's not a blocker, sure, but on the other hand, the benefit of enabling > stapling by default isn't that big either - as long as browsers don't > hard-fail when OCSP information isn't available.
Kaspar, Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling enabled. Browsers aren't likely to start hard-failing by default until that % is a lot higher. The vast majority of the servers that have OCSP stapling enabled are running IIS. I claim that this is due to the fact that IIS enables OCSP stapling by default. If we don't enable OCSP stapling by default in httpd, how are we going to increase that % ? > The "speed, speed, > speed" argument (coming mostly from the browser vendors) isn't too > convincing to me neither, as OCSP replies are usually cached for one > or two days, and the typical user doesn't connect to thousands of > new/different SSL sites per day. I think you've misunderstood the "speed, speed, speed" argument. If an OCSP response is delivered via stapling, then there's no need for the browser to block the TLS handshake whilst it obtains an OCSP response directly from the CA's OCSP responder. Stapling provides a noticeable speedup even if the browser never caches OCSP responses. >> Is there a synopsis of which browsers support it for which types of >> certificates? > > I don't think so, and it's probably also kind of a moving target. Chrome > "supports" it for DV and OV as well - it will include a status_request > extension in the TLS handshake by default -, but what I meant with > "enforces" is that it won't care if there's no stapled response > (Google's ceterum censeo used to be "Revocation doesn't work", which in > 2012 lead to their implementation of CRL sets where the code is public, > but "the process by which they are generated is not", > https://dev.chromium.org/Home/chromium-security/crlsets). > > For EV certs, the browser behavior is more uniform, though strict hard > fail enforcement still isn't happening - for testing purposes, try > this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80, > and point the browser to > https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html. > With strict revocation checking enforced, no browser should ever render > any content of the "Revoked VeriSign Secure Site Pro with EV Certificate > Test Page" (but most do when revocation information is not available, > although some at least show warnings or downgrade the UI to non-EV). > >> The motivation for putting it in trunk is so that the next release has >> stapling enabled in the default configurations, which essentially means >> that in some number of years (2-3? I dunno) there will be a >> faster-growing number of httpd instances that have OCSP stapling enabled. > > Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of > several years, I assume. What I don't like with this approach in any > case, however, is that we as the devs decide on behalf of the admins, > instead of letting them make an informed decision. I' really arguing > in favor of something like this in httpd-ssl.conf.in: > > --- snip --- > # SSL Engine Switch: > # Enable/Disable SSL for this virtual host. > SSLEngine on > > # Server Certificate and Private Key: > # ... > SSLCertificateFile "conf/server.crt" > SSLCertificateKeyFile "conf/server.key" > > # OCSP Stapling: > # For SSL certificates which include an OCSP responder URI, mod_ssl > # can include revocation status information for the server's own > # certificate in the TLS handshake. Enabling this option requires > # outgoing connectivity to the CA's OCSP responder (usually running > # running on port 80, use "openssl x509 -in server.crt -text" to > # determine the exact URI), so this option is not enabled by default. > # The responder will be queried with the interval configured > # via SSLStaplingStandardCacheTimeout. For EV SSL certificates > # in particular, enabling this option is recommended/useful. > #SSLUseStapling On > --- snip --- > > (i.e., move the SSLUseStapling directive closer to the cert settings, > and make people aware of the outgoing connections this will trigger) > >> Part of what makes the 2.4.x tangent is confusing is that sometimes your >> objections seem to be qualified on the assumption that 2.4.x would be >> updated. Can we please drop 2.4.x from this conversation? > > Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the > basic question remains, though: is it acceptable that configuring an SSL > certificate potentially triggers outgoing OCSP requests in mod_ssl, > without having been explicitly instructed to do so by an admin? My view > is still the same as in November 2014: admins should opt in for this > feature, not be forced to opt out. > >>> 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. >> >> I don't follow. What does that help? With which attack vector does >> that improve the situation? > > The point I was trying to make is that stapling is a per-certificate > feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so > it would be best if the admin becomes aware of it when configuring the cert. > >>>> 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. >> >> Not HostnameLookups; resolving ServerName at startup (configured or >> defaulted). > > Ok, but I wouldn't consider DNS as being implicitly configured - after > all, the resolvers are specified when network access on the OS level is > configured (and DNS queries are sent to nameservers which are hopefully > authoritative for lookups of hosts in the local net). > >>>> 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. >> >> Admin configures a certificate that has a domain name of attacker in the >> responder URI? DNS entry for domain name in responder URI is taken over >> to point to attacker? > > I was primarily trying to come up with a generic principle "which could > be followed consistently across disparate features", so I'm not sure if > considering specific attacks for the stapling case is the right way to > continue the discussion... as another example, take the "Version check > idea" thread from April 2015 [1] - even though there might not be an > immediate threat if it were enabled by default, I really hope that httpd > doesn't move into the direction of automatically enabling features > requiring outgoing connectivity (without the admin's explicit > instruction and consent). > >> So forgetting 2.4.x, are you vetoing changing the trunk default config >> to enable stapling, and are the criteria of the veto both >> >> 1. The default configuration should not trigger unsolicited outgoing >> queries to untrusted systems, for both a) and b), that's how I would put it. >> 2. Additionally, features enabled by default need to have sufficient >> coverage in the test framework. > > For GA releases, my position is that both criteria apply, yes. If it's > enabled in trunk, an alpha or a beta for getting broader testing exposure, > then the docs and release notes/announcement should prominently say so > (not only for OCSP stapling specifically, but in general for those > features which may trigger unsolicited outgoing connections). > > Kaspar > > > [1] > https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3c7c89cdba-b463-415f-82da-ddd6ad88c...@jagunet.com%3E > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online
