OCSP stapling limitations (was Re: [PATCH 0 of 4] OCSP stapling)
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:
> >Here are patches for OCSP stapling support. Testing and
> >review appreciated.
> >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  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
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
> 2. The CA/Browser Forum are defining a "must staple" certificate
> extension , which we anticipate that browsers (e.g. ) 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  to require the use of Certificate
> Transparency (CT) , and this plan expects OCSP Stapling to work
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"
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
More information about the nginx-devel