Re: svn commit: r1633730 - /httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in

[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)