Hello!

On Wed, Sep 23, 2015 at 09:42:32AM -0400, 173279834462 wrote:

> > Though not providing an OCSP response isn't a problem at all
> > as OCSP stapling is just an optimization, and
>
> Well. it *is* a problem.
>
> Without stapling, each client that hits our server also hits the ocsp
> server.
> In our case, the ocsp server is overloaded (StartSSL), and therefore we
> can help by caching the response and delivering it ouselves.

The problem here is that OCSP server is overloaded. The fact that
nginx isn't able to provide help in this situation to a few first
connections is at most lack of optimisation.

> There is another, more general problem: ocsp servers may log the hits.
> Although this may not happen with StartSSL (we do not know for sure),
> it is still a concern on privacy of clients and profiling of all sorts.

That's the problem with OCSP, not with nginx. Clients who
consider this to be a problem can use other ways to check
certificate validity, including CRLs and CRLsets.

> > there is no need to care about pre-caching things.
>
> If it works, yes.
> If it does not work, then we must update manually.
> One wants to avoid the latter case.

Consider switching to a CA which works?

If you OCSP server is overloaded and not able to respond to
requests, nginx won't be able to load an OCSP response as
well, and nothing would help.

If your OCSP server is responding - at least to some requests -
nginx eventually will be able to load a response and will start
serving it to clients.

> > As long as there are clients who ask your server about an OCSP response
> >- nginx will load it and will provide it to clients as needed.
>
> It is *not* working. Please move on with the wishful thinking. It would be
> great if things were as you say. In reality, they are not.
>
> I think we agree that the following openssl test would be sufficient
> and good to ask the server about an OCSP response. In practice,
> nginx is still not delivering as intended.
>
> echo QUIT \
> | openssl s_client \
> -CAfile /etc/ssl/ca-bundle.pem \
> -connect $fqdn:443 \
> -servername $fqdn \
> -tlsextdebug \
> -status 2>&1
>
> where fqdn is the server's address.

I believe I already explained how it works, but let me repeat. As
soon nginx sees an connection with Certificate Status Request TLS
extension, it will start loading an OCSP response from you CA OCSP
responder. Once the response is loaded, it will be stapled to
further connections. It is not possible to return an OCSP
response in connection which was first to request it due to
OpenSSL API limitations and the fact that loading a response can
take a while.

That is, assuming 1 worker process and just started nginx, an OCSP
staple is expected to be returned on the second connection with
"openssl s_client -status ...".

Note though that if your CA OCSP responder is overloaded and not
responding, it is likely that nginx won't be able to load a
response, much like your clients. In this case nginx will retry
loading a response each 5 minutes.

As far as I understand, what you are asking about is a persistent
cache of OCSP responses, to mitigate your CA's OCSP responder
availability issues. This is not a feature currently available in
nginx (and you've choosen very wrong way to ask for a feature in
an open source project).

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx