Re: svn commit: r1633730 - /httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in
On 27.10.2014 12:55, Jeff Trawick wrote:
Putting SSLUseStapling at global scope makes it easier for the admin, who
may have had trouble getting SSL working in the first place.
I don't see yet how it makes it easier - my point is more that an
admin should consciously enable OCSP stapling when he is configuring a
certificate for a virtual host, i.e., SSLUseStapling should appear after
the SSLCertificateFile in the VirtualHost _default_:443 block. (This
applies even more to cases where people put their VirtualHost configs
into separate files - having a global setting inadvertently apply to
all VirtualHosts is something I would want to avoid.)
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.
If the primary concern is that configuring mod_ssl (getting SSL
working as you put it) is too complex for the typical admin, then
streamlining our current httpd-ssl.conf would probably make more sense -
there's stuff in there which standard https sites almost never need
(SSLCACertificate{Path,File}, SSLCARevocation* etc., making it pretty
hard for an inexperienced admin to identify those directives which
really matter).
(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.)
It is mostly hindered by the release of OpenSSL 1.0.2 anyway, because
currently, there's the issue of not being able to configure
per-certificate chains in OpenSSL up to 1.0.1.
Generally speaking, I consider SSLStaplingForceURL sort of a kludge - it
might be justified for those (very few) high-traffic sites where the
OCSP URI is deliberately omitted from the certificate (and which are
unlikely to deploy httpd/mod_ssl, BTW), but doesn't really help with the
configure a proxy for retrieving to-be-stapled OCSP responses (you
would need an OCSP-aware proxy under the URL pointed to by
SSLStaplingForceURL, a simple HTTP proxy is not sufficient).
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.
As mentioned by Hanno elsewhere, more than a few certificates sounds
rather fuzzy, and it would be more helpful for the reader of this
comment to have some data for typical response sizes. They basically
depend on what option is used for response signing according to section
2.2 of RFC 6960:
All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:
- the CA who issued the certificate in question
- a Trusted Responder whose public key is trusted by the requestor
- a CA Designated Responder (Authorized Responder, defined in
Section 4.2.2.2) who holds a specially marked certificate issued
directly by the CA, indicating that the responder may issue OCSP
responses for that CA
For publicly-trusted certificates (in the sense of the CA/Browser
Forum's Baseline Requirements), it's options 1 and 3 which are of
relevance. Examples can be seen at [1] and [2], respectively, i.e. we
are in the range of 500 to 1600 bytes for the DER encoding, and I would
hardly expect responses with more than 2000 bytes (unless large signing
keys/algorithms are used). I didn't look at how these numbers translate
to our stapling cache, though.
Kaspar
[1]
http://ocsp.usertrust.com/MFEwTzBNMEswSTAJBgUrDgMCGgUABBR8sWZUnKvbRO5iJhat9GV793rVlAQUrb2YejS0Jvf6xCZU7wO94CTLVBoCEEt1V4JpOQyb4y8S7F9tlF4%3D
(Content-Length: 471)
[2]
http://sr.symcd.com/MFEwTzBNMEswSTAJBgUrDgMCGgUABBR0JBRnBp%2F14Jg%2FXj4aa6BlKlQVdQQUAVmr5906C1mmZGPWzyAHV9WR52oCEBrIXreuw1E82A2FOF7P0gg%3D
(Content-Length: 1595)
Re: svn commit: r1633730 - /httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in
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=1633730r1=1633729r2=1633730view=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 SSLSessionCacheshmcb: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 15 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/
Re: svn commit: r1633730 - /httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in
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=1633730r1=1633729r2=1633730view=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 SSLSessionCacheshmcb: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. + +# 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. + +# 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. Kaspar [1] https://cabforum.org/documents/#Baseline-Requirements
