Does anyone plan to develop the feature of openssl' OCSP stapling?

[Rob Stradling]

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> 
wrote:
> > On Thursday 16 Jun 2011 16:02:12 Igor Sysoev wrote:
<snip>
> >> 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.
<snip>
> 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...
https://issues.apache.org/bugzilla/show_bug.cgi?id=50740

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, 
etc).

> 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.
>
> A.

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 
be Stapled.

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 
Response.

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.

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online