On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote: > > >> -----Ursprüngliche Nachricht----- >> Von: Rob Stradling [mailto:rob.stradl...@comodo.com] >> Gesendet: Freitag, 3. Juli 2015 12:01 >> An: dev@httpd.apache.org >> Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk >> >> On 02/07/15 19:03, Ruediger Pluem wrote: >> <snip> >>> Just to be sure I don't miss anything. This is not about disabling >> OCSP, its about disabling OCSP stapling by default. >>> Maybe I have a wrong understanding of OCSP stapling, but to me >> stapling only provides performance improvements, not >>> security improvements for the client as the client still could connect >> to the OCSP URL given in the cert directly and >>> get the answer from there. If the response is stabled it does not need >> to (with the same level of security) and saves >>> itself a roundtrip to the OCSP server of the CA and the OCSP server of >> the CA a request to process. >> >> Yes, the client _could_ connect to the OCSP URL given in the cert >> directly and get the answer from there. However, at least one major >> browser (Chrome) no longer does this, but it does process stapled OCSP >> responses. >> >> Even if we could ignore Chrome... >> There will always be some clients that cannot reach the CA's OCSP >> responder directly (due to connectivity issues at the client side), >> whereas the TLS servers that those clients connect to may well have >> better connectivity (and thus be able to staple OCSP responses that the >> client cannot obtain by any other means). >> >> Also, this isn't just about performance. If a client contacts an OCSP >> responder directly, it reveals to the CA that it is interested in a >> particular certificate. That's a far worse privacy leak than a TLS >> server contacting a CA's OCSP responder and revealing that it's >> interested in the status of its own certificate!! > > 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. Index: trunk/docs/conf/extra/httpd-ssl.conf.in =================================================================== --- trunk/docs/conf/extra/httpd-ssl.conf.in (revision 1700039) +++ trunk/docs/conf/extra/httpd-ssl.conf.in (working copy) @@ -114,6 +114,11 @@ # Seconds before invalid OCSP responses are expired from the cache #SSLStaplingErrorCacheTimeout 600 +# This directive overrides the URI of an OCSP responder as obtained +# from the authorityInfoAccess (AIA) extension of the certificate. +# One potential use is when a proxy is used for retrieving OCSP queries. +#SSLStaplingForceURL http://internal.proxy.local + ## ## SSL Virtual Host Context ##
