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

[Maxim Dounin]

Hello!

On Fri, Jan 22, 2016 at 09:47:09PM +0000, Alessandro Ghedini wrote:

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

As said above, browsers use OCSP, not OCSP stapling.  And "soft    
fail" makes much more sense for OCSP than for OCSP stapling.  When
using OCSP, only an attacker in a privileged network position can
stop OCSP requests.  But if a certificate was compromised (and 
revoked accordingly), OCSP response will show that the certificate 
was revoked.  But this is not the case with OCSP stapling: an 
attacker can easily avoid returning anything stapled.

Moreover, even with OCSP "soft fail" and "hard fail" are not the 
only options available and used in practice.  E.g., Opera do not 
show the lock icon till an OCSP response is received.

[...]

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

You are essentially trying to push "must staple" extension into 
nginx configuration.  And I'm not fan of both the "must staple" 
and what you are trying to do.

OCSP stapling was designed as an optimization for OCSP.  That is, 
if OCSP stapling is used, it saves an OCSP lookup.  But 
introducing "must staple" changes things a lot: now servers are 
required to provide OCSP responses even if they can't do so for 
some reason.  You can't start answering requests till you've 
loaded an OCSP response to staple it, and you essentially never know 
if will be able to start server or not.

I tend to think that "must staple" introduces much more 
complexity than it solves.  And the same applies to the 
configuration directive introduced by your patch.

-- 
Maxim Dounin
http://nginx.org/