On Tue, Jun 20, 2017 at 6:39 AM, Stefan Eissing
<stefan.eiss...@greenbytes.de> wrote:
>
>> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <rpl...@apache.org>:
>>
>>> 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.)

Reply via email to