On Sun, Apr 13, 2014 at 6:11 PM, Maxim Dounin <mdou...@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 <mdou...@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
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
