OCSP stapling limitations (was Re: [PATCH 0 of 4] OCSP stapling)

Maxim Dounin mdounin at mdounin.ru
Sun Oct 6 10:14:10 UTC 2013


On Fri, Oct 04, 2013 at 01:25:25PM +0100, Rob Stradling wrote:

> On 05/09/12 12:14, Maxim Dounin wrote:
> >Hello!
> >
> >Here are patches for OCSP stapling support.  Testing and
> >review appreciated.
> <snip>
> >Known limitations:
> >
> >- Unless externally set OCSP response is used (via the "ssl_stapling_file"
> >   directive), stapled response won't be sent in a first connection.  This
> >   is due to the fact that OCSP responders are currently queried by nginx
> >   once it receives connection with certificate_status extension in ClientHello,
> >   and due to limitations in OpenSSL API (certificate status callback is
> >   blocking).
> Hi Maxim.  This limitation is turning out to be a problem, for
> several reasons:
> 1. In some situations, the limitation appears to be amplified -
> there are more "first connections" than you might expect.  Netcraft
> reported [1] that:
>   "Fewer than 50% of the CloudFlare IP addresses responded with an
> OCSP response stapled on the first non-discarded connection attempt.
> Even after 20 requests, the response rate is not consistent, some IP
> addresses still fail to staple an OCSP response on each and every
> SSL connection. This inconsistent behaviour may be down to a number
> of separate machines responding to the same IP address either in
> different locations, or behind a load balancer."

It's believed to be related to a number of hosts CloudFlare uses 
for each https domain and the fact that domains checked by 
Netcraft are mostly unused.  Piotr Sikora may be able to provide 
more info.

I don't think this is a problem for ordinary uses of OCSP 
stapling, as for unused domains optimization provided by OCSP 
stapling doesn't really matter.

If it turns out to be a real problem - an obvious way to improve 
things is to provide a cache for OCSP responses shared between 
worker processes.

> 2. The CA/Browser Forum are defining a "must staple" certificate
> extension [2], which we anticipate that browsers (e.g. [3]) will
> recognize and enforce, by aborting the TLS handshake if a stapled
> OCSP response was not sent.

I believe it was said more than once that this changes OCSP 
stapling quite significantly.  As of now it's an optimization 
technology, while with "must staple" it will become a required  
part of a certificate.  There is no surprise such change requires 
quite a different coding aproach.

BTW, the draft in question was already expired.

> 3. Google are planning [4] to require the use of Certificate
> Transparency (CT) [5], and this plan expects OCSP Stapling to work
> reliably.

It looks like there is more than one way to include signed 
certificate timestamp, and OCSP stapling is just one of them.  And 
I'm not sure it's a good way - the X509v3 certificate extension 
should be better, as long as it's a required part of a 

> What work needs to be done to enable Nginx to send a stapled OCSP
> response every time (without having to use the "ssl_stapling_file"
> directive)?

I tend to think that ssl_stapling_file is a good way to provide an 
OCSP response if it's required for some reason.

> Could you work around the fact that the OpenSSL certificate status
> callback is blocking?  Or would you absolutely require a
> non-blocking alternative to be available?
> (Ben Laurie, who is on both the OpenSSL and CT teams, told me
> recently: "If there's changes needed to OpenSSL, it'd be helpful to
> know sooner
> rather than later.")

I don't think changing OpenSSL to support non-blocking callbacks 
is feasible.  While it's something we would like to have (just couple 
of weeks ago we've discussed here that non-blocking callbacks are 
required to support external session store), it looks like too 
major change for OpenSSL.  It will also take several years to be 
actually usable.

Maxim Dounin

More information about the nginx-devel mailing list