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

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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx