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

Server NGINX
1

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? :slight_smile:

Thanks a lot!

– Shimi

2

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? :slight_smile:

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 D.
http://nginx.org/

3

On Sun, Apr 13, 2014 at 1:39 PM, Maxim D. [email protected]
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 :slight_smile: ) - 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

4

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:

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 D.
http://nginx.org/

5

On Sun, Apr 13, 2014 at 6:11 PM, Maxim D. [email protected]
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
:slight_smile:

Thanks again for all your answers!

– Shimi