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

80e3e869e6a0be55a76350aa6e8a87f1?d=identicon&s=25 shimi (Guest)
on 2014-04-13 10:28
(Received via mailing list)
Hi,

I'm contacting the list after doing some Google-foo and not finding
anything - not sure if this is due to my searching skills, or because
nobody ever asked about this... pardon me if it's a known issue, and a
link
to a relevant resource would be appreciated in such a case.

I'm using Nginx as a reverse HTTP proxy to Tomcat, primarily for the
purpose of doing OCSP stapling.

When Nginx starts for the first time, and there's no cached OCSP
response,
the first client to try an OCSP will fail; I understand that this is by
design, and I've overcome it by simply 'warming' the cached manually by
using OpenSSL's s_client...  of course I'll be happy to learn there's a
way
to make Nginx block and get OCSP response if there's a cache miss (I
understand that blocking every time in case of OCSP server being down
won't
help performance much, but I guess cache can be negative in such a case,
instead of a miss, and maybe this is already the case...)

Anyways, that's not the main issue I have.

The main issue I have is that when a revoked certificate is being used
by
Nginx, and an OCSP is being conducted against the server port where this
certificate is served.

Watching the packets arriving from ocsp.digicert.com via Wireshark, I
see
the OCSP response saying that the certificate is revoked (so, Nginx
seems
to be querying the OCSP server fine?), and I also see this in Nginx's
error
log:

2014/04/07 17:44:41 [error] 27005#0: certificate status "revoked" in the
OCSP response while requesting certificate status, responder:
ocsp.digicert.com

Yet, the OpenSSL s_client, even after multiple attempts (so the cache
should be "warm"), returns that no OCSP response was returned from the
server...

Naturally, I would expect the response to be proxied by Nginx back to
the
client.

What am I missing / doing wrong? :)

Thanks a lot!

-- Shimi
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2014-04-13 12:40
(Received via mailing list)
Hello!

On Sun, Apr 13, 2014 at 11:27:17AM +0300, shimi wrote:

> When Nginx starts for the first time, and there's no cached OCSP response,
> The main issue I have is that when a revoked certificate is being used by
> ocsp.digicert.com
>
> Yet, the OpenSSL s_client, even after multiple attempts (so the cache
> should be "warm"), returns that no OCSP response was returned from the
> server...
>
> Naturally, I would expect the response to be proxied by Nginx back to the
> client.
>
> What am I missing / doing wrong? :)

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

--
Maxim Dounin
http://nginx.org/
80e3e869e6a0be55a76350aa6e8a87f1?d=identicon&s=25 shimi (Guest)
on 2014-04-13 12:56
(Received via mailing list)
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'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
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2014-04-13 17:12
(Received via mailing list)
Hello!

On Sun, Apr 13, 2014 at 01:55:24PM +0300, shimi wrote:

> 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

> 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/
80e3e869e6a0be55a76350aa6e8a87f1?d=identicon&s=25 shimi (Guest)
on 2014-04-13 18:01
(Received via mailing list)
On Sun, Apr 13, 2014 at 6:11 PM, Maxim Dounin <mdounin@mdounin.ru>
wrote:

> > > staple anything as it doesn't make sense (moreover, it may be
> > Followup question, then, if I may:
> > understand OCSP stapling) is to verify the cert is OK. Wouldn't returning
> 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
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.