On Sun, Oct 26, 2014 at 3:18 AM, Kaspar Brand <httpd-dev.2...@velox.ch> wrote:
> On 23.10.2014 02:59, traw...@apache.org wrote: > > Author: trawick > > Date: Thu Oct 23 00:59:40 2014 > > New Revision: 1633730 > > > > URL: http://svn.apache.org/r1633730 > > Log: > > add OCSP Stapling configuration, disabled by default > > > > Modified: > > httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in > > > > Modified: httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in > > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in?rev=1633730&r1=1633729&r2=1633730&view=diff > > > ============================================================================== > > --- httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in (original) > > +++ httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in Thu Oct 23 > 00:59:40 2014 > > @@ -73,6 +73,31 @@ SSLPassPhraseDialog builtin > > SSLSessionCache "shmcb:ssl_scache(512000)" > > SSLSessionCacheTimeout 300 > > > > +# OCSP Stapling (requires OpenSSL 0.9.8h or later) > > +# > > +# This feature is disabled by default and requires at least > > +# the two directives SSLUseStapling and SSLStaplingCache. > > +# Refer to the documentation on OCSP Stapling in the SSL/TLS > > +# How-To for more information. > > +# > > +# Enable stapling for all SSL-enabled servers: > > +#SSLUseStapling On > > OCSP stapling is primarily a per-certificate feature - so my suggestion > would be to only have the cache related directives (SSLStaplingCache, > SSLStaplingStandardCacheTimeout, SSLStaplingErrorCacheTimeout) at the > global level, and put the other ones into the default <VirtualHost> block. > Putting SSLUseStapling at global scope makes it easier for the admin, who may have had trouble getting SSL working in the first place. I'm not aware of any real drawbacks. Messages will be logged if stapling can't be performed for a particular certificate (missing certificate chain, no responder URL in certificate or in configuration), but that may be a good thing. And the server will start up normally. (Without disagreeing with your "per-certificate" comment, it is worth noting that we have no per-certificate stapling configuration -- only per-vhost. I have no idea how many configurations that affects, but I guess that the number is increasing based on effort put into mod_ssl in the last year or so.) Other thoughts out there? > > + > > +# Define a relatively small cache for OCSP Stapling using > > +# the same mechanism that is used for the SSL session cache > > +# above. If stapling is used with more than a few certificates, > > +# the size may need to be increased. (AH01929 will be logged.) > > +#SSLStaplingCache "shmcb:ssl_stapling(32768)" > > Shouldn't we make it a bit larger by default? Memory is so cheap these > days that I'm not sure it's worth to keep it that small. > Factoring in 50% management overhead/fragmentation, I could fit responses for 28+ certificates in 32768 bytes if they were like the ones I have already. The current number seems very conservative for the sort of configuration for which we can't expect enough configuration skills to review the comments in the sample before putting in production. On the one hand I agree with "memory is so cheap" but on the other hand I see sample configs for SSLStaplingCache on the www with "150000" or more bytes, so I guess there is a lack of any clue about what the number, or even the cache itself, is actually for. I like it being a bit closer to reality. Other thoughts out there? > > > + > > +# Override the OCSP responder URL specified in the certificate > > +#SSLStaplingForceURL http://ocsp.example.com/ > > I suggest to omit this in the sample configuration, as certificates > issued by publicly-trusted CAs which lack an OCSP URI (based on section > 13.2.1 in the CA/Browser Forum's Baseline Requirements [1] that the URI > may be omitted for a "high-traffic FQDN" when stapling is contractually > or technically enforced) do 1) not exist as of today and 2) are > definitely not what a typical deployment with mod_ssl entails. Having > SSLStaplingForceURL in the sample configuration (especially as a global > directive) does more harm than good, IMO. > I will pull it out; FWIW, I think the most common reason for override would be to implement a responder proxy, whether to meet infrastructure requirements in the web tier or to have a more flexible way to deal with responder glitches than what can be configured in mod_ssl. Thanks a bunch for your review, and I hope others will look at it. > Kaspar > > > [1] https://cabforum.org/documents/#Baseline-Requirements > -- Born in Roswell... married an alien... http://emptyhammock.com/
