Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Subject: Re: ALPN patch comments
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: 
 <CAKQ1sVOmgqQUg1ditN2x3PLeJWd=oyJvLq_L6quyPSkoTadbZg@mail.gmail.com>
Date: Thu, 4 Jun 2015 18:19:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <13AA0595-AAA5-4150-8FFD-CABC8E780EB6@greenbytes.de>
References: 
 <CAKQ1sVMuQ9T0+BqZGMeSjfzWHG7pg_UsBfOZ0ORbubW_uw5Fpw@mail.gmail.com>
 <CALK=YjN867KUSJZG1Xv=7YoQ18YM8V4BKO9FMmriY6ofwgiyGg@mail.gmail.com>
 <CAKQ1sVMrGZif-HJpWWcmafipm9LJnRyyB5pdqYSM8CSH41DeeQ@mail.gmail.com>
 <CAKQ1sVOmgqQUg1ditN2x3PLeJWd=oyJvLq_L6quyPSkoTadbZg@mail.gmail.com>
To: dev@httpd.apache.org

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 final word to make a choice when =
either one ALPN callback proposes many protocols or of several callbacks =
propose protocols. So, when mod_spdy and mod_h2 are active *and* the =
client claims to support spdy/3.1 and h2, the SSLAlpnPreference =
determines what gets chosen and sent to the client. This was not =
necessary with NPN as in that SSL extension the client was making the =
choice.

3. Independent of the client proposal, as I read the spec, the server is =
free to chose any protocol identifier it desires. This might result in =
the client closing the connection. So, if the client uses ALPN and the =
server does not want/cannot do/is configured not to support any of the =
clients proposals, httpd can always send back =E2=80=9Ehttp/1.1=E2=80=9C =
since this is what it always supports.

In this light, and correct me if I=E2=80=99m wrong, I see no benefit and =
only potential harm by introducing a =E2=80=9ESSLALpn on|off=E2=80=9C =
configuration directive. I think the current implementation covers all =
use cases and if one is missing, please point out the scenario.

As with the register once or on every connection optimization, yes, =
there might be some performance to gain. But I think it is not so =
straightforward to implement this, as not only the address and port =
influences this but also the SNI that gets send in the client helo. So, =
one would have at least to verify that registering an ALPN callback =
*after* the connection is open and SNI has been received has any effect.=20=


cheers,

  Stefan

> Am 04.06.2015 um 14:52 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>=20
> On Thu, Jun 4, 2015 at 2:39 PM, Yann Ylavic <ylavic.dev@gmail.com> =
wrote:
>> On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener <covener@gmail.com> =
wrote:
>>>=20
>>>=20
>>> On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic <ylavic.dev@gmail.com> =
wrote:
>>>>=20
>>>> 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 proposal to =
the
>>>> client (with the fall back to "http/1.1").
>>>>=20
>>>> Maybe it would be cleaner to let the modules register the ALPN
>>>> identifiers (at configure time, with another optional function), =
and
>>>> get rid of SSLAlpnPreference on mod_ssl side.
>>>> 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.
>>>>=20
>>> I think we need SSLAlpnPreference any time modules register ALPN =
protocols,
>>> otherwise the admin has no control over whih is negotiated.  I don't =
think
>>> we should rip it out.
>>=20
>> OK, so it should probably be renammed SSLAlpnIDs or similar, and be
>> more than just a hint when configured (i.e. refuse connection if no
>> client ALPN ID matches).
>=20
> I meant fall back to "http/1.1" still, not refuse the connection.

<green/>bytes GmbH
Hafenweg 16, 48155 M=C3=BCnster, Germany
Phone: +49 251 2807760. Amtsgericht M=C3=BCnster: HRB5782