> 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
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
> 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
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
> 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
> -Ursprüngliche Nachricht-
> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Gesendet: Dienstag, 20. Juni 2017 13:40
> An: dev@httpd.apache.org
> Betreff: Re: ocsp stapling improvements
>
>
> > Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <
> 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
> 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
> 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
> 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
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
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
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
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
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
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
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:
17 matches
Mail list logo