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

[Maxim Dounin]

Hello!

On Mon, Oct 07, 2013 at 11:29:00AM +0100, Rob Stradling wrote:

> On 06/10/13 11:14, Maxim Dounin wrote:
> <snip>
> >>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,
> 
> Yes, but it's an optimization technology that seems to work reliably
> in httpd and IIS.  ;-)

The "seems" is a key word here, it seems.  :)

[...]

> >>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.
> 
> It works, but doesn't it require the user to regularly download a
> newer OCSP Response for each certificate, update the contents of
> their stapling file(s), and reload Nginx?
> IMHO, this needs to be fully automated, just as it is in httpd and IIS.
> 
> Are you saying that there's zero chance of this ever happening?

Automatic download doesn't make OCSP responses magically available 
in all cases.  But if an OCSP response is required for a server to 
work - a server should refuse to start if it's missing and can't 
be downloaded.  And this is not something httpd and/or IIS do now, 
AFAIK.

On the other hand, ssl_stapling_file allows this to be done if 
needed.  If it is actually needed.

[...]

-- 
Maxim Dounin
http://nginx.org/en/donation.html