httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: ocsp stapling improvements
Date Tue, 20 Jun 2017 11:39:56 GMT

> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <rpluem@apache.org>:
> 
> I guess the core mistake we do today is that we expire the entries in the cache
> after SSLStaplingStandardCacheTimeout. But we should keep them in the cache as long as
> they are valid (so either whats in the next update field of the response or this update
> + SSLStaplingResponseMaxAge).

+1

> Instead we should have a refresh parameter that I would set as percentage of the
> expired time (so between this update and next update or as percentage of already
> expired SSLStaplingResponseMaxAge). Once this refresh time is passed OCSP responses
> should get refreshed by a background job (possibly implemented by mod_watchdog).

+1

>> 2. Persist responses (is this just a config/default issue?)
> 
> This could become tricky given the various so cache implementations we have. I could
> only think of persisting the whole cache when Apache is shutdown.

I am not very experienced with those. Would the current Stapling implementation not work with
a "socache_dbm"? And what would be the drawback of that?

As an alternative, use of mod_watchdog offers advantages here. If we have only one thread
(for all or for a particular certificate) that writes the cache in a server (all processes),
it becomes easy to use the file system, I think. Write per tmpfile+rename should be good enough
and it should no longer need a global mutex. Server names are distinct and make for an easy
directory tree.

The question then is if mod_watchdog jobs still have privileges or if those files have common
ownership and if that is a problem.

Does this makes sense or am I insane?

>> 3. Start update responses at server start/regular intervals
> 
> What I want to avoid is that the server "hangs" at start because of a "hanging" OCSP
server.
> I admit that this can happen already today on the very first SSL request with stapling
turned
> on, but IMHO this is a bad behavior. So either just do the stuff on a regular basis in
the background
> and do not staple if there is no valid OCSP response yet (I know Hanno won't like that
:-))
> Or have an initial (valid) OCSP response being loaded from a file during startup. It
would be up to
> the admin to fill this file with a valid OCSP response before it starts httpd.

Can we push the burden of getting a OCSP response to the client, even for must-staple certificates?
This would be nice as a fall back in case of errors. The error might be in the data center
for outgoing connections, so the client might succeed where the server fails.

-Stefan
Mime
View raw message