Re: ocsp stapling improvements

> Am 20.06.2017 um 17:43 schrieb William A Rowe Jr : > > 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

Re: ocsp stapling improvements

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

Re: ocsp stapling improvements

> Am 20.06.2017 um 17:19 schrieb Hanno Böck : > > On Tue, 20 Jun 2017 13:39:56 +0200 > Stefan Eissing wrote: > >> Can we push the burden of getting a OCSP response to the client, even >> for must-staple certificates? > > No, you can't. > The

Re: ocsp stapling improvements

On Tue, 20 Jun 2017 13:39:56 +0200 Stefan Eissing wrote: > Can we push the burden of getting a OCSP response to the client, even > for must-staple certificates? No, you can't. The whole point is that must staple enforces stapling. This has a bit to do with the

Re: ocsp stapling improvements

> Am 20.06.2017 um 14:35 schrieb Plüm, Rüdiger, Vodafone Group > : > > 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

Re: ocsp stapling improvements

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

Re: ocsp stapling improvements

> Am 13.06.2017 um 00:48 schrieb Hanno Böck : > > What I think needs also be handled: > * There's > https://bz.apache.org/bugzilla/show_bug.cgi?id=59049 > which indicates that faulty responses from the OCSP server may bring > the server into a faulty state from which it

Re: ocsp stapling improvements

> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem : > > > > On 06/12/2017 05:25 PM, Stefan Eissing wrote: >> I talked to the people orignally writing our ssl OCSP code regarding >> feedback we got from the Let's Encrypt server outage [1]. We agreed >> that some valid points

Re: ocsp stapling improvements

> Am 13.06.2017 um 00:48 schrieb Hanno Böck : > > Hi, > > On Mon, 12 Jun 2017 17:25:39 +0200 > Stefan Eissing wrote: > >> 1. Hand out existing responses until expired >> 2. Persist responses (is this just a config/default issue?) >> 3. Start

Re: ocsp stapling improvements

Hi, On Mon, 12 Jun 2017 17:25:39 +0200 Stefan Eissing wrote: > 1. Hand out existing responses until expired > 2. Persist responses (is this just a config/default issue?) > 3. Start update responses at server start/regular intervals > 4. Use something better than

Re: ocsp stapling improvements

On 06/12/2017 05:25 PM, Stefan Eissing wrote: > I talked to the people orignally writing our ssl OCSP code regarding > feedback we got from the Let's Encrypt server outage [1]. We agreed > that some valid points for improvement were raised and we need a > discussion about what should be done

Re: ocsp stapling improvements

On 06/12/2017 08:56 PM, Eric Covener wrote: > On Mon, Jun 12, 2017 at 11:25 AM, Stefan Eissing > wrote: >> As to 3, starting a task at server start or after a certain interval, >> do we have some infrastructure for this? Do we need something new? > > I don't

Re: ocsp stapling improvements

On 06/12/2017 08:50 PM, Jacob Champion wrote: > On 06/12/2017 08:25 AM, Stefan Eissing wrote: >> On 4, it seems, we lack a good http(s) client. The code we use >> for proxying is not easily reused for new connections, or? I see >> more need for such a thing in the near future. > > Did the

Re: ocsp stapling improvements

On Mon, Jun 12, 2017 at 11:25 AM, Stefan Eissing wrote: > As to 3, starting a task at server start or after a certain interval, > do we have some infrastructure for this? Do we need something new? I don't really understand the context, but some potential examples

Re: ocsp stapling improvements

On 06/12/2017 08:25 AM, Stefan Eissing wrote: On 4, it seems, we lack a good http(s) client. The code we use for proxying is not easily reused for new connections, or? I see more need for such a thing in the near future. Did the Apache-Serf-for-proxying effort end up going anywhere? I seem to