Issue with OCSP stapling when server certificate has been revoked by CA

[shimi]

On Sun, Apr 13, 2014 at 6:11 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Sun, Apr 13, 2014 at 01:55:24PM +0300, shimi wrote:
>
> > On Sun, Apr 13, 2014 at 1:39 PM, Maxim Dounin <mdounin at mdounin.ru>
> wrote:
> >
> > Hello!
> > >
> > > As long as no good OCSP response is received, nginx will not
> > > staple anything as it doesn't make sense (moreover, it may be
> > > harmful, e.g. if the response isn't verified).
> > >
> > >
> > >
> > Hello!
> >
> > Thank you for your answer. So I understand this is a deliberate behavior
> by
> > nginx and not a bug.
> >
> > Followup question, then, if I may:
> >
> > By "good", do you mean "positive"? i.e. "we have verified that the
> > certificate is OK and valid"?
>
> I mean "good" as specified here:
>
> http://tools.ietf.org/html/rfc6960#section-2.2
>
> > I'm not sure I understand why is it good idea not to tell the client that
> > the certificate is known and has been revoked... the purpose (as I
> > understand OCSP stapling) is to verify the cert is OK. Wouldn't returning
> > no-response to a client might cause it to think it may be an intermittent
> > issue with accessing OCSP, and thus "soft-fail" and trust the (revoked)
> > cert "for now" until a proper response can be obtained? And if that is
> the
> > case, wouldn't passing the negative response from the OCSP server
> > immediately tell the client that something is fishy? (i.e. someone is
> > MITM'ing the innocent user with a cert using a stolen key that was
> revoked
> > by the real owner? The recent heartbleed bug is an excellent example...).
> > Sounds like a security issue to me, but again, I may be missing
> something?
>
> An attacker can and will do the same.  And nginx behaviour does
> not limit an attacker in any way.
>

Good point! I must be tired for having raised that scenario to begin with
:-)

Thanks again for all your answers!

-- Shimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140413/3676cef0/attachment.html>