On Sep 6, 2015 8:09 AM, "Kaspar Brand" wrote:
>
> On 05.09.2015 13:06, Tim Bannister wrote:
> > It's not just conventional browsers. I think automated / embedded
> > HTTP clients will also benefit from stapling, either because
> > networking filters would block a
On 05.09.2015 13:06, Tim Bannister wrote:
> It's not just conventional browsers. I think automated / embedded
> HTTP clients will also benefit from stapling, either because
> networking filters would block a conversation between the client and
> the CA's OCSP responder, or the extra latency from
Am 06.09.2015 um 15:06 schrieb Kaspar Brand:
Taking into account that OCSP responders from the big players are
running on fairly robust infrastructure these days (cf. the sr.symcd.com
example, aka ocsp.verisign.net, aka ocsp.ws.symantec.com.edgekey.net),
I'm not buying the "OCSP is unreliable"
On 05.09.2015 12:53, Ben Laurie wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand wrote:
>> I'm also very sceptical that a higher percentage of handshakes with
>> stapled responses (how much exactly?) will lead browser vendors to
>> switch to hard fail - as the
On 05.09.2015 14:23, Jeff Trawick wrote:
> On 09/04/2015 10:59 AM, Kaspar Brand wrote:
>>> 1. The default configuration should not trigger unsolicited outgoing
>>> queries to untrusted systems, for both a) and b), that's how I would put it.
>
> Re: "unsolicited":
>
> Key words/phrases from the
On Sat, 5 Sep 2015 at 09:32 Kaspar Brand wrote:
> On 04.09.2015 17:54, Rob Stradling wrote:
> > Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
> > enabled. Browsers aren't likely to start hard-failing by default until
> > that % is a lot higher.
On 5 Sep 2015, at 11:53, Ben Laurie wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand wrote:
>> On 04.09.2015 17:54, Rob Stradling wrote:
>>> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
>>> enabled. Browsers aren't likely to
On 04.09.2015 17:54, Rob Stradling wrote:
> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
> enabled. Browsers aren't likely to start hard-failing by default until
> that % is a lot higher.
>
> The vast majority of the servers that have OCSP stapling enabled are
> running
On 09/04/2015 10:59 AM, Kaspar Brand wrote:
On 02.09.2015 01:54, Jeff Trawick wrote:
On 08/30/2015 02:30 AM, Kaspar Brand wrote:
today's situation, because this assessment misses the fact that with the
current RFC-6066-based implementation, stapling can't fully achieve the
goal of obviating
On 02.09.2015 01:54, Jeff Trawick wrote:
> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>> today's situation, because this assessment misses the fact that with the
>> current RFC-6066-based implementation, stapling can't fully achieve the
>> goal of obviating OCSP queries for the clients - all
On 04/09/15 15:59, Kaspar Brand wrote:
> On 02.09.2015 01:54, Jeff Trawick wrote:
>> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>>> today's situation, because this assessment misses the fact that with the
>>> current RFC-6066-based implementation, stapling can't fully achieve the
>>> goal of
On 08/30/2015 02:30 AM, Kaspar Brand wrote:
On 28.08.2015 19:27, Jeff Trawick wrote:
For one, it is appropriate for the default config is there to enable
practices which are reasonable in most situations, and OCSP Stapling is
widely accepted as an appropriate feature for HTTP servers to enable.
On 08/29/2015 08:10 PM, William A Rowe Jr wrote:
On Aug 29, 2015 1:49 PM, "Jeff Trawick" > wrote:
>
> On 08/28/2015 04:17 PM, Tim Bannister wrote:
>>
>> Jeff Trawick > wrote:
>>>
>>>
>>> As of now
On 28.08.2015 19:27, Jeff Trawick wrote:
For one, it is appropriate for the default config is there to enable
practices which are reasonable in most situations, and OCSP Stapling is
widely accepted as an appropriate feature for HTTP servers to enable.
I have some doubts whether widely accepted
Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 28.08.2015 19:27, Jeff Trawick wrote:
For one, it is appropriate for the default config is there to enable
practices which are reasonable in most situations, and OCSP Stapling is
widely accepted as an appropriate feature for HTTP servers to
On 29.08.2015 17:56, olli hauer wrote:
On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote:
Thanks for the detailed explanation. So yes OCSP stapling is really
beneficial if it is possible for the server admin to set it up. But
it likely requires additional configuration steps outside of
On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote:
-Ursprüngliche Nachricht-
Von: Rob Stradling [mailto:rob.stradl...@comodo.com]
Gesendet: Freitag, 3. Juli 2015 12:01
An: dev@httpd.apache.org
Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 02/07/15
On Aug 29, 2015 1:49 PM, Jeff Trawick traw...@gmail.com wrote:
On 08/28/2015 04:17 PM, Tim Bannister wrote:
Jeff Trawick traw...@gmail.com wrote:
As of now there's still a veto on my suggestion of enabling stapling by
default in the httpd trunk config.
Would that default need to be
On Mon, Jul 13, 2015 at 3:08 AM, Ruediger Pluem rpl...@apache.org wrote:
On 07/11/2015 08:55 PM, William A Rowe Jr wrote:
If you are suggesting we shouldn't change the compiled-in default, I can
agree, POLS (Principal Of Least Surprise). If you are suggesting the
default
config
On 07/11/2015 08:55 PM, William A Rowe Jr wrote:
If you are suggesting we shouldn't change the compiled-in default, I can
agree, POLS (Principal Of Least Surprise). If you are suggesting the default
config shouldn't reflect the ability to efficiently handle OCSP by stapling,
here
I
On 01.07.2015 14:27, Ben Laurie wrote:
On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote:
The fundamental objection I have to enabling stapling by default in our
GA releases is that it would enable a phoning home feature (to the
CA's OCSP responders) as a side effect of
We can have a dialog about the best behavior of our default config.
However...
On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand httpd-dev.2...@velox.ch
wrote:
On 01.07.2015 14:27, Ben Laurie wrote:
On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch
wrote:
The fundamental
On Sat, Jul 11, 2015 at 2:55 PM, William A Rowe Jr wr...@rowe-clan.net
wrote:
We can have a dialog about the best behavior of our default config.
However...
On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand httpd-dev.2...@velox.ch
wrote:
On 01.07.2015 14:27, Ben Laurie wrote:
On 1 November
On Jul 3, 2015 9:37 AM, Rob Stradling rob.stradl...@comodo.com wrote:
On 03/07/15 11:13, Plüm, Rüdiger, Vodafone Group wrote:
snip
Thanks for the detailed explanation. So yes OCSP stapling is really
beneficial
if it is possible for the server admin to set it up. But it likely
requires
On 03/07/15 11:13, Plüm, Rüdiger, Vodafone Group wrote:
snip
Thanks for the detailed explanation. So yes OCSP stapling is really beneficial
if it is possible for the server admin to set it up. But it likely requires
additional
configuration steps outside of httpd to make the OCSP responder
On 02/07/15 19:03, Ruediger Pluem wrote:
snip
Just to be sure I don't miss anything. This is not about disabling OCSP, its
about disabling OCSP stapling by default.
Maybe I have a wrong understanding of OCSP stapling, but to me stapling only
provides performance improvements, not
security
-Ursprüngliche Nachricht-
Von: Rob Stradling [mailto:rob.stradl...@comodo.com]
Gesendet: Freitag, 3. Juli 2015 12:01
An: dev@httpd.apache.org
Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 02/07/15 19:03, Ruediger Pluem wrote:
snip
Just to be sure I don't
[mailto:benlau...@gmail.com mailto:benlau...@gmail.com] Im
Auftrag von
Ben Laurie
Gesendet: Mittwoch, 1. Juli 2015 14:27
An: dev@httpd.apache.org mailto:dev@httpd.apache.org
Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 1 November 2014 at 09
: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch
wrote:
On 30.10.2014 15:51, Jeff Trawick wrote:
IMO the present concerns with OCSP Stapling are:
* not so clear that it has seen enough real-world testing
-Ursprüngliche Nachricht-
Von: benlau...@gmail.com [mailto:benlau...@gmail.com] Im Auftrag von
Ben Laurie
Gesendet: Mittwoch, 1. Juli 2015 14:27
An: dev@httpd.apache.org
Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 1 November 2014 at 09:05, Kaspar Brand
On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 30.10.2014 15:51, Jeff Trawick wrote:
IMO the present concerns with OCSP Stapling are:
* not so clear that it has seen enough real-world testing; commented out
sample configs and better documentation will help, as
On 30.10.2014 15:51, Jeff Trawick wrote:
IMO the present concerns with OCSP Stapling are:
* not so clear that it has seen enough real-world testing; commented out
sample configs and better documentation will help, as will enabling by
default in trunk (just a little?)
* related bugs 57121
IMO the present concerns with OCSP Stapling are:
* not so clear that it has seen enough real-world testing; commented out
sample configs and better documentation will help, as will enabling by
default in trunk (just a little?)
* related bugs 57121 and 57131
A simple way to help with the broader
Am Thu, 30 Oct 2014 10:51:15 -0400
schrieb Jeff Trawick traw...@gmail.com:
# Define a relatively small cache for OCSP Stapling using
# the same mechanism that is used for the SSL session cache
# above. If stapling is used with more than a few certificates,
# the size may need to
On Thu, Oct 30, 2014 at 4:54 PM, Hanno Böck ha...@hboeck.de wrote:
Am Thu, 30 Oct 2014 10:51:15 -0400
schrieb Jeff Trawick traw...@gmail.com:
# Define a relatively small cache for OCSP Stapling using
# the same mechanism that is used for the SSL session cache
# above. If
35 matches
Mail list logo