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

[shimi]

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'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?

Let's say I want to proxy the response despite it being possibly harmful
(in a way I do not yet understand :) ) - is that something straightforward
as removing an 'if (revoked)' from somewhere in the source code, or would I
need to hire some Nginx code expert to change this behavior?

By the way, if it's actually the spec (RFC) that says that you're not
supposed to staple such responses, I'm also very fine with that. But if
not, it would sound weird to me that Nginx decides to handle them in a
special way....

Thanks again,

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