> -----Ursprüngliche Nachricht----- > Von: Stefan Eissing [mailto:[email protected]] > Gesendet: Dienstag, 20. Juni 2017 13:40 > An: [email protected] > Betreff: Re: ocsp stapling improvements > > > > 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?
It might cause I/O overhead compared with socache_shmcb, but it might be a good solution for those who want to have persisted OCSP responses. Other people might priorize a distributed cache like dc or memcache. So I like the idea of just staying with the current approach to define the socache provider used for caching. Who knows? Maybe someone writes a socache_staggered that allows to go through several socache providers one after another in case of a cache miss? That would allow to have a shmcb first and a dbm second. > > 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 guess this is all solvable, but as stated above I am in favor of just using the socache API for that and let our requirements be solved by an appropriate socache provider. > > >> 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. I would be in favor of this. I think it is still reasonable to have the client try the OCSP server if the server cannot get a valid response to staple. But this is my personal opinion, so others might have different requirements. The question to me is what do we need to do in mod_ssl code to offer this? I mean the changes that are now on the table should ensure that we get a more reliable stapling infrastructure within mod_ssl that allows people to try must-staple. Anything else we need or can do? Regards Rüdiger
