On Fri, Jun 5, 2015 at 8:39 AM Stefan Eissing
wrote:
>
> > Am 05.06.2015 um 01:37 schrieb Yann Ylavic :
> >
> > On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding
> wrote:
> >>
> >> Hence, we might need a configurable way to ignore a client's ALPN,
> though I doubt that
> >> "SSLalpn off" is the ri
> Am 05.06.2015 um 01:37 schrieb Yann Ylavic :
>
> On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding wrote:
>>
>> Hence, we might need a configurable way to ignore a client's ALPN, though I
>> doubt that
>> "SSLalpn off" is the right way to express that. Likewise, neither is
>> SSLAlpnPreferen
On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding wrote:
>
> Hence, we might need a configurable way to ignore a client's ALPN, though I
> doubt that
> "SSLalpn off" is the right way to express that. Likewise, neither is
> SSLAlpnPreference.
> The server protocol(s) preference should be independe
> On Jun 4, 2015, at 9:19 AM, Stefan Eissing
> wrote:
>
> I think we need to clarify some things:
>
> 1. ALPN is initiated by the client. When a client does not send ALPN as part
> of client helo, the SSL alpn callbacks are not invoked and the server does
> not send any ALPN information back.
On Thu, Jun 4, 2015 at 6:19 PM, Stefan Eissing
wrote:
> I think we need to clarify some things:
>
> 1. ALPN is initiated by the client. When a client does not send ALPN as part
> of client helo, the SSL alpn callbacks are not invoked and the server does
> not send any ALPN information back. This
I think we need to clarify some things:
1. ALPN is initiated by the client. When a client does not send ALPN as part of
client helo, the SSL alpn callbacks are not invoked and the server does not
send any ALPN information back. This is different from NPN.
2. SSLAlpnPreference is intended as the
On Thu, Jun 4, 2015 at 2:39 PM, Yann Ylavic wrote:
> On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener wrote:
>>
>>
>> On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic wrote:
>>>
>>> I think what makes the thing a bit awkward is that the
>>> negotiable/preferred ALNP identifiers (protocols) is configurable
;> even for multiple hosts at the same ip.
>>>
>>>
>>>
>>> I would say returning some error is a valid response for not enabling
>>> H2Engine on a VHost, while still handling ALPN when explicitly disabled is
>>> not.
>>>
>>>
On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener wrote:
>
>
> On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic wrote:
>>
>> I think what makes the thing a bit awkward is that the
>> negotiable/preferred ALNP identifiers (protocols) is configurable in
>> both httpd (SSLAlpnPreference) and mod_h2 (hard coded
>
>
>> If no identifier is registered, mod_ssl won't register the ALPN
>> callback either, so that httpd continues to work without ALPN when not
>> needed.
>>
>
>
I do like that from a backport perspective though.
On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic wrote:
> I think what makes the thing a bit awkward is that the
> negotiable/preferred ALNP identifiers (protocols) is configurable in
> both httpd (SSLAlpnPreference) and mod_h2 (hard coded).
> The former is only a hint while the latter is the real prop
t; Bert
>>
>>
>>
>> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
>> Sent: woensdag 3 juni 2015 22:20
>> To: dev@httpd.apache.org
>> Subject: Re: ALPN patch comments
>>
>>
>>
>> That is why mod_h2
: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Sent: woensdag 3 juni 2015 22:20
> To: dev@httpd.apache.org
> Subject: Re: ALPN patch comments
>
>
>
> That is why mod_h2 allowe "H2Engine on|off" on base server and vhosts. If I
> understand you correctly,
enabling H2Engine
on a VHost, while still handling ALPN when explicitly disabled is not.
Bert
From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
Sent: woensdag 3 juni 2015 22:20
To: dev@httpd.apache.org
Subject: Re: ALPN patch comments
That is why mod_h2 allowe
That is why mod_h2 allowe "H2Engine on|off" on base server and vhosts. If I
understand you correctly, this does what you ask for.
//Stefan
> Am 03.06.2015 um 19:45 schrieb William A Rowe Jr :
>
>> On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing
>> wrote:
>> Hmm, personally, I do not like re
On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing wrote:
> Hmm, personally, I do not like redundant configurations. If someone
> configures a module, like mod_h2, to be enabled (H2Engine on), she could
> expect the module to take all the necessary steps. So I am no fan of a
> „SSLAlpnEnable“.
>
The
With the current (master) code of mod_h2, you'd probably need
something like the attached patch to handle a possible failure in
modssl_register_alpn(), because SSLALPNPreference was not configured
(as per my proposed mod_ssl patch).
On Wed, Jun 3, 2015 at 5:16 PM, Stefan Eissing
wrote:
> Hmm, I c
Hmm, I cannot test this today since I am travelling.
If Jim wants to tag 2.5.13 this week, then either the current v4 patch makes it
in, or we need to postpone this. A changed patch on which my module (and
possibly others) chokes on, will not serve anyone I assume.
As with the "don't send NPN
On Wed, Jun 3, 2015 at 4:45 PM, Yann Ylavic wrote:
>
> This means enabling ALPN only if SSLALPNPreference is used.
Something like below :
Index: modules/ssl/mod_ssl.c
===
--- modules/ssl/mod_ssl.c(revision 1683271)
+++ modules/s
On Wed, Jun 3, 2015 at 3:43 PM, Stefan Eissing
wrote:
> Hmm, personally, I do not like redundant configurations. If someone
> configures a module, like mod_h2, to be enabled (H2Engine on), she could
> expect the module to take all the necessary steps. So I am no fan of a
> „SSLAlpnEnable“.
Nei
On Wed, Jun 3, 2015 at 3:43 PM, Stefan Eissing
wrote:
>
> If a client sends ALPN information in its hello, it certainly can expect an
> answer from the server.
> Since in absence of any other modules, the httpd will do „http/1.1“, I think
> that is a reasonable response.
FWICS, httpd will alert
On 06/03/2015 03:43 PM, Stefan Eissing wrote:
Hmm, personally, I do not like redundant configurations. If someone configures
a module, like mod_h2, to be enabled (H2Engine on), she could expect the module
to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“.
If a client sends A
I additionally tested today on Ubuntu 14.04 LTS. Works for me.
> Am 03.06.2015 um 12:56 schrieb Stefan Eissing :
>
> I tested the lined patch on a 2.4.x checkout with mod_h2 on OS X 10.10 and
> openssl 1.0.2. All my tests ran fine.
>
> //Stefan
>
>> Am 02.06.2015 um 16:56 schrieb Eric Covener
Hmm, personally, I do not like redundant configurations. If someone configures
a module, like mod_h2, to be enabled (H2Engine on), she could expect the module
to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“.
If a client sends ALPN information in its hello, it certainly can e
I wonder if registering the ssl_callback_alpn_select callback
inconditionally could break some clients.
Are those (ALPN ready) always negociate "http/1.1"?
Otherwise we could check for sc->server->ssl_alpn_pref->nelts > 0 (or
a dedicated SSLAlpnEnable) beforing using
SSL_CTX_set_alpn_select_cb().
I tested the lined patch on a 2.4.x checkout with mod_h2 on OS X 10.10 and
openssl 1.0.2. All my tests ran fine.
//Stefan
> Am 02.06.2015 um 16:56 schrieb Eric Covener :
>
> Can you test the latest rev of the backport candidate?
>
> http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch
>
Can you test the latest rev of the backport candidate?
http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch
On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:
>
> > Am 25.04.2015 um 11:47 schrieb Kaspar Brand :
> >
> > On 22.04.2015 18:54, Jim Jagielsk
It sounds like it could be a vhost thing. SSL_CTX is most likely not global,
but maybe unique for a vhost? I am not certain myself, maybe someone else with
more knowledge of mod_ssl could pitch in?
//Stefan
> Am 01.06.2015 um 13:04 schrieb Rainer Jung :
>
> Am 29.04.2015 um 13:05 schrieb Kaspa
Am 29.04.2015 um 13:05 schrieb Kaspar Brand:
I did some formatting cleanup in r1676709 and put a patch for 2.4.x
online under
https://people.apache.org/~kbrand/mod_ssl-2.4.x-alpn_2015-04-29.diff.
This should hopefully make it easier for people to test and review (it's
an amalgamation of ten revis
The key issue I had with the lack of optional functions on the old NPN
backport is addressed, that's great. Looks promising!
NPN is now irrelevant with ALPN, I presume?
On Wed, Apr 29, 2015 at 6:05 AM, Kaspar Brand
wrote:
> On 27.04.2015 17:04, Stefan Eissing wrote:
> >> Am 25.04.2015 um 11:47
Thank You!!
Will review ASAP.
> On Apr 29, 2015, at 7:05 AM, Kaspar Brand wrote:
>
> On 27.04.2015 17:04, Stefan Eissing wrote:
>>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand :
>>> Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
>>> certainly needs more eyes before a ba
On 27.04.2015 17:04, Stefan Eissing wrote:
>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand :
>> Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
>> certainly needs more eyes before a backport proposal could be made.
>> There's also a "TODO: we should have a mod_ssl configurati
> Am 25.04.2015 um 11:47 schrieb Kaspar Brand :
>
> On 22.04.2015 18:54, Jim Jagielski wrote:
>>> For me the time seems right to rip NPN out of trunk and only backport
>>> the ALPN code to 2.4.
>>>
>>
>> I'd be +1 for that.
>
> So, to get one step further, and since there were no explicit obje
On 22.04.2015 18:54, Jim Jagielski wrote:
>> For me the time seems right to rip NPN out of trunk and only backport
>> the ALPN code to 2.4.
>>
>
> I'd be +1 for that.
So, to get one step further, and since there were no explicit objections
to removing NPN support so far (or arguments for keeping
Am 23.04.2015 um 06:56 schrieb Kaspar Brand:
On 22.04.2015 21:30, Rainer Jung wrote:
Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the same block is are already part of
ssl_private.h, just 10 lines above.
I don't know if I have any points to give here, but if NPN does not make it to
2.4, it's fine with me to remove it from trunk also. Only mod_spdy is affected
afaik.
//Stefan
> Am 23.04.2015 um 06:56 schrieb Kaspar Brand :
>
>> On 22.04.2015 21:30, Rainer Jung wrote:
>>> Am 22.04.2015 um 17:49
On 22.04.2015 21:30, Rainer Jung wrote:
> Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
>> Thanks. In the patch for ssl_private.h, the complete NPN block should
>> actually be dropped - the same block is are already part of
>> ssl_private.h, just 10 lines above.
>
> I've kept the new one and droppe
On 22.04.2015 18:45, Stefan Eissing wrote:
> I understand your argument. My pov is of someone trying to bring
> http/2 to the people. While bringing a new httpd on an existing
> system seems easy, installing a new system openssl is more
> challenging with its dependencies and the changes in hiding
Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
On 22.04.2015 10:52, Stefan Eissing wrote:
I made two small patches based on the feedback from Kaspar. One for
the code and one for the documentation.
Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the sa
>
> For me the time seems right to rip NPN out of trunk and only backport
> the ALPN code to 2.4.
>
I'd be +1 for that.
> Am 22.04.2015 um 17:49 schrieb Kaspar Brand :
>
>> On 22.04.2015 10:52, Stefan Eissing wrote:
>> I made two small patches based on the feedback from Kaspar. One for
>> the code and one for the documentation.
>
> Thanks. In the patch for ssl_private.h, the complete NPN block should
> actually b
On 22.04.2015 10:52, Stefan Eissing wrote:
> I made two small patches based on the feedback from Kaspar. One for
> the code and one for the documentation.
Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the same block is are already part of
ssl_private.h
I made two small patches based on the feedback from Kaspar. One for the code
and one for the documentation. Since I build against releases, I did not test
the doc patch building.
This code patch I tested against my already patched 2.4.12 with openssl 1.0.2
and 1.0.1 in mod_h2 sandbox.
Re NPN
43 matches
Mail list logo
