httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: ocsp stapling improvements
Date Tue, 20 Jun 2017 15:43:29 GMT
On Tue, Jun 20, 2017 at 6:39 AM, Stefan Eissing
<> wrote:
>> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <>:
>>> 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?

I consider it very unwise to use root to perform client queries, almost
as unwise as serving any responses. The problem in both cases is
that every defect in parsing (and there is 'input' in either case) opens
up the remote possibility of a root exploit.

All client requests, for stapling, for health check, for any purposes
whatsoever should be performed as httpd configured user. Whether
that happens in an ombudsman resource process or the typical
worker process is a design question.

Yes, a dbm certainly should survive a server restart, that's why one
would use dbm for the SSL Session Cache (before session tickets
offered a fresh solution - although these suffer just as many issues
as our OCSP implementation so far.)

View raw message