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

[Maxim Dounin]

Hello!

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

> 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
http://nginx.org/en/donation.html