Mailing List Archive

Re: svn commit: r1890693 - in /httpd/httpd/trunk: changes-entries/ssl_alpn_outgoing.txt modules/ssl/ssl_engine_io.c
On Fri, Jun 11, 2021 at 12:46 PM <icing@apache.org> wrote:
>
> Author: icing
> Date: Fri Jun 11 10:45:25 2021
> New Revision: 1890693
>
> URL: http://svn.apache.org/viewvc?rev=1890693&view=rev
> Log:
> *) mod_ssl: tighten the handling of ALPN for outgoing (proxy)
> connections. If ALPN protocols are provided and sent to the
> remote server, the received protocol selected is inspected
> and checked for a match. Without match, the peer handshake
> fails.
> An exception is the proposal of "http/1.1" where it is
> accepted if the remote server did not answer ALPN with
> a selected protocol. This accomodates for hosts that do
> not observe/support ALPN and speak http/1.x be default.

While mod_proxy_http2 sets "proxy-request-alpn-protos", I don't think
that mod_proxy_http does.
Should it set "http/1.1" such that if the backend returns something
other than "http/1.1" or empty we fail the negotiation there too?

Cheers;
Yann.
Re: svn commit: r1890693 - in /httpd/httpd/trunk: changes-entries/ssl_alpn_outgoing.txt modules/ssl/ssl_engine_io.c [ In reply to ]
> Am 11.06.2021 um 12:58 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>
> On Fri, Jun 11, 2021 at 12:46 PM <icing@apache.org> wrote:
>>
>> Author: icing
>> Date: Fri Jun 11 10:45:25 2021
>> New Revision: 1890693
>>
>> URL: http://svn.apache.org/viewvc?rev=1890693&view=rev
>> Log:
>> *) mod_ssl: tighten the handling of ALPN for outgoing (proxy)
>> connections. If ALPN protocols are provided and sent to the
>> remote server, the received protocol selected is inspected
>> and checked for a match. Without match, the peer handshake
>> fails.
>> An exception is the proposal of "http/1.1" where it is
>> accepted if the remote server did not answer ALPN with
>> a selected protocol. This accomodates for hosts that do
>> not observe/support ALPN and speak http/1.x be default.
>
> While mod_proxy_http2 sets "proxy-request-alpn-protos", I don't think
> that mod_proxy_http does.
> Should it set "http/1.1" such that if the backend returns something
> other than "http/1.1" or empty we fail the negotiation there too?

I think sending "http/1.1" should be fine, if we are willing to accept an empty response for this (which we have extra handling for). This will let us continue to work against servers that do not really handle ALPN.

But servers that do, can react to our "http/1.1" and abort the connection if they cannot fulfill this. I think that would be good without any likelihood of breaking things (fingers crossed).

In this context: I am thinking of adding SNI hostname and ALPN protocols to the ap_ssl_bind_outgong() as optional parameterts. I have to check if that would work correctly in all cases, but it would be much nicer than the current notes.

Cheers, Stefan