ocsp stapling improvements

2017-06-12 Thread Stefan Eissing
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 about it, here. I identified the following points so far:

Re: The drive for 2.4.26

2017-06-12 Thread Jim Jagielski
Still looking at a T today... I will RM unless someone else would like to do so!

Re: svn commit: r1798472 - /httpd/httpd/branches/2.4.x/CHANGES

2017-06-12 Thread Eric Covener
I thought we were leaving proxy_http2 experimental? On Mon, Jun 12, 2017 at 10:13 AM, wrote: > Author: jim > Date: Mon Jun 12 14:13:50 2017 > New Revision: 1798472 > > URL: http://svn.apache.org/viewvc?rev=1798472=rev > Log: > Note that as of 2.4.26, HTTP/2 is no longer

Re: svn commit: r1798472 - /httpd/httpd/branches/2.4.x/CHANGES

2017-06-12 Thread Jim Jagielski
That's right. It's that specific module. > On Jun 12, 2017, at 10:18 AM, Eric Covener wrote: > > I thought we were leaving proxy_http2 experimental? > > On Mon, Jun 12, 2017 at 10:13 AM, wrote: >> Author: jim >> Date: Mon Jun 12 14:13:50 2017 >> New

Re: svn commit: r1798472 - /httpd/httpd/branches/2.4.x/CHANGES

2017-06-12 Thread Eric Covener
On Mon, Jun 12, 2017 at 11:29 AM, Jim Jagielski wrote: > That's right. It's that specific module. > >> On Jun 12, 2017, at 10:18 AM, Eric Covener wrote: >> >> I thought we were leaving proxy_http2 experimental? http://svn.apache.org/viewvc?rev=1798470=rev ?

Re: ocsp stapling improvements

2017-06-12 Thread Jacob Champion
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

Re: ocsp stapling improvements

2017-06-12 Thread Eric Covener
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

2017-06-12 Thread Ruediger Pluem
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

2017-06-12 Thread Ruediger Pluem
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

2017-06-12 Thread 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 for improvement were raised and we need a > discussion about what should be done

Re: ocsp stapling improvements

2017-06-12 Thread 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 update responses at server start/regular intervals > 4. Use something better than