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. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
