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 _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
