> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <[email protected]>: > > 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
