Does anyone plan to develop the feature of openssl' OCSP stapling?
rob.stradling at comodo.com
Fri Jun 17 14:52:24 MSD 2011
On Thursday 16 Jun 2011 17:15:38 Arnaud GRANAL wrote:
> On Thu, Jun 16, 2011 at 6:41 PM, Rob Stradling <rob.stradling at comodo.com>
> > On Thursday 16 Jun 2011 16:02:12 Igor Sysoev wrote:
> >> As to OCSP, I'm going to implement it in the next 2.0 version.
> > I'm glad to hear that OCSP Stapling is on your radar.
> As an user, I would prefer it disabled and available as an optional
> module and not part as core.
Hi Arnaud. Thanks for your thoughts.
An nginx implementation of OCSP Stapling for HTTPS would need to have access
to the SSL context (ngx_http_ssl_srv_conf_t->ssl.ctx in ngx_http_ssl_module)
in order to call OpenSSL's SSL_CTX_set_tlsext_status_cb() function, which
registers a callback function to run whenever a Certificate Status Request TLS
Extension is encountered.
ngx_http_ssl_module already contains a call to
SSL_CTX_set_tlsext_servername_callback(), which serves a similar purpose: it
registers a callback function that will run whenever a Server Name Indication
TLS Extension is encountered.
Therefore, rather than create a separate module, surely ngx_http_ssl_module is
where (at least some of) the OCSP Stapling code should be placed?
> As of Apache 2.3 OSCP Stapling is disabled by default too.
Which I want to change. See...
I understand that IIS 7.x enables OCSP Stapling by default for every site
certificate that contains an OCSP Responder URL in the Authority Information
Access extension. I'm not aware of any way to disable this behaviour within
IIS itself (although I suppose you could block the outbound OCSP Requests on
your firewall, or add a duff "hosts" entry for the OCSP Responder's domain name,
> I don't really get why use an high-performance web server to handle
> queries only saving money to certification authorities.
If saving money for CAs was the only benefit of OCSP Stapling, nobody would
implement it, and I wouldn't be writing this message.
End-users benefit from OCSP Stapling:
- Improved Privacy: The CA's OCSP Responder can't track which IP Addresses
visit which sites.
- Faster Page Loads: The Browser doesn't have to retrieve an OCSP Response
from the OCSP Responder before rendering any content.
- Improved Reliability: When OCSP Stapling is enabled by both the Client and
Server, OCSP Responses are delivered 100% of the time. Without OCSP Stapling,
the availability of the CA's OCSP Responder comes into play. This isn't a
huge issue with today's browsers that soft-fail when they can't contact an
OCSP Responder, but a number of CAs and Browsers would like to switch to hard-
fail in the future if it's possible to do so without "breaking the 'Net".
There's no direct benefit on the server side, as you've observed.
> So we pay like $100/200 for the SSL certificate, and then we pay again
> server and bandwidth fees to answer OSCP ?
I take your point. If your primary/only concern is saving bandwidth, then you
shouldn't be forced to use OCSP Stapling. But I would much prefer to have
OCSP Stapling on-by-default with an option to disable it.
> Clients have time to wait OSCP answer from CA
See the above list of benefits of OCSP Stapling to End-users.
> and in the other side, nginx server is already very busy so it is probably
> not a good idea to load it with bonus features.
You've got me thinking...
In the Apache httpd implementation, mod_ssl contains code which regularly
downloads and caches OCSP Responses in shared memory so that they're ready to
It occurs to me that the same result could be achieved without having to put
the downloading/caching code inside the webserver. A cronjob could run a
shell script that...
- runs the OpenSSL command-line tool to download the appropriate OCSP
Responses, saving them to the hard disk.
- signals the webserver to reload its config file.
With this cronjob-based approach, the webserver would only require a small
amount of new code:
- a new config directive for specifying the filename of an OCSP Response (or
perhaps the code could just look for <certificate_filename>.ors: if present, use
it for Stapling; if absent, Stapling is disabled).
- code to read the OCSP Response file.
- a call to SSL_CTX_set_tlsext_status_cb().
- some sanity checks on the OCSP Response (e.g. is it still time-valid?)
- a call to SSL_set_tlsext_status_ocsp_resp() to actually staple the OCSP
This cronjob-based approach should perform better than Apache/mod_ssl's
approach, because it would avoid the use of a mutexed shared-memory cache.
A related issue:
Over at nginx at nginx.org, somebody just asked if there are any plans for nginx
to support OCSP verification of Client Authentication certificates. If
implemented, this feature would surely require internal nginx code for
downloading OCSP Responses from an OCSP Responder.
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the nginx-devel