You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Kaspar Brand <ht...@velox.ch> on 2014/10/26 08:18:15 UTC
Re: svn commit: r1633730 - /httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in
On 23.10.2014 02:59, trawick@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.
> +
> +# 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
Re: svn commit: r1633730 - /httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in
Posted by Kaspar Brand <ht...@velox.ch>.
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
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Oct 26, 2014 at 3:18 AM, Kaspar Brand <ht...@velox.ch>
wrote:
> On 23.10.2014 02:59, trawick@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/