[PATCH 2 of 2] Proxy: add support for OCSP stapling verification from upstream

[Alessandro Ghedini]

On Fri, Jan 22, 2016 at 09:46:01pm +0300, Maxim Dounin wrote:
> Hello!
> 
> On Fri, Jan 22, 2016 at 06:02:14PM +0000, Alessandro Ghedini wrote:
> 
> > On Fri, Jan 22, 2016 at 08:49:26pm +0300, Maxim Dounin wrote:
> > > Hello!
> > > 
> > > On Fri, Jan 22, 2016 at 05:38:06PM +0000, Alessandro Ghedini wrote:
> > > 
> > > > # HG changeset patch
> > > > # User Alessandro Ghedini <alessandro at cloudflare.com>
> > > > # Date 1453481233 0
> > > > #      Fri Jan 22 16:47:13 2016 +0000
> > > > # Node ID c6668c14a2d168307bcfade0cc2e01c92c31312a
> > > > # Parent  a8c4f65236ad90138863d5295ca059a3d37da37e
> > > > Proxy: add support for OCSP stapling verification from upstream
> > > > 
> > > > This patch adds the "proxy_ssl_stapling_verify" option that controls OCSP
> > > > stapling verification from an upstream server.
> > > > 
> > > > The option allows three values:
> > > > 
> > > >  - "off" (default): disable OCSP stapling completely.
> > > >  - "on": request OCSP stapling from upstream and verify response if
> > > >          provided.
> > > >  - "full": same as "on", but fail also when no response is received.
> > > 
> > > The "on" seems to be no different from "off" and hardly make 
> > > sense, as an attacker can easily avoid returning stapled OCSP 
> > > response.
> > 
> > Yes, of course. This is what browsers currently do, and is IMO better than
> > doing nothing. Once Must-Staple (aka "TLS Feature" x509 extension) starts
> > to be used in the wild this can be updated.
> 
> What browsers do is quite different: they use OCSP, and use OCSP 
> Stapling as an optimization.  And even if they can't obtain a 
> response, they show this visually to users.

Firefox shows an error message only if the OCSP responder actually returns a
negative response. If the connection to the responder fails Firefox just
ignores the problem ("soft-fail") and continues like nothing happened, You can
enable hard-fail mode through about:config but it's not on by default.

Chrome/Chromium doesn't even implement full OCSP anymore IIRC (it used to do
it, in soft-fail mode by default as well) and replaced it with its own CRLSet
mechanism (basically it tries OCSP stapling first, and then falls back to
checking the CRL sets).

So, no, in the default configuration most browsers behave like my patch does,
except that they may try a full OCSP request before giving up or try another
method that is even more error-prone (e.g. if the CRL/CRLset is out-of-date).

But if this is a really critical issue for you, I'd be okay with dropping the
soft-fail mode if that meant getting this functionality merged.

> > > The "full" in turn doesn't seem to be correct feature, as stapled 
> > > OCSP response may be legitimately absent for multiple reasons.
> > 
> > If you control the upstream servers than I don't see any reason why you
> > couldn't just enable OCSP stapling unconditionally and enforce this on
> > the downstream with the "full" option. Maybe I'm missing something?
> 
> Much like any other arbitrary requirement, this one of course can 
> be enforced as well.  The question is how this is different from 
> other arbitrary requirements we don't provide options for.

nginx's proxy module already supports checking CRLs, which are an even bigger
pain to deal with, and full OCSP has so many problems that it's not really a
viable option in practice (see above). As far as certificate revocation goes
that's it, there aren't any more "arbitrary requirements" as far as I know. so
it seems to me that upstreadm OCSP stapling checking would be a fairly nice and
useful improvement over the current status and while my patches aren't exactly
simple they are not that compilcated either.

One possible improvement over my current implementation is, if the user
configures both stapling and CRL checking, nginx could try stapling first and
if thet doesn't return any answer fallback to CRL. But the CRL won't return a
proper answer all the time either (e.g. even if it's only slightly out of date)
so "soft-fail" mode would still be effectively present.

Hope this helps.

Cheers