<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 13, 2014 at 6:11 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br>

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

-- Shimi<br></div></div></div></div>