Hi,
> Hi all,
>
> At GitHub we’ve worked on a patch to make HAProxy’s ALPN code compatible
> with the patches for it that have landed in OpenSSL:
Great, thats something that needs fixing, yes.
> This final version is slightly different from what HAProxy currently
> expects, which is based on some custom OpenSSL patches.
>
> Let me know if this is a good approach towards fixing this problem or
> that it should be done differently.
I gave it at try against OpenSSL 1.0.2-dev (git head OpenSSL_1_0_2-stable)
from a Google Chrome Browser, but it doesn't look like it behaves correctly.
draft-ietf-tls-applayerprotoneg-04 [1] is the current draf if I understand
correctly, but HAProxy doesn't behave according to the draft.
For example, in 3.1 The Application Layer Protocol Negotiation Extension:
> Servers that receive a client hello containing the
> "application_layer_protocol_negotiation" extension, MAY return a
> suitable protocol selection response to the client.
HAProxy does not select a suitable protocol based on the client hello.
Instead it always sends the fixed lists of ALPN protocols as specified
with the alpn keyword [2]. It even sends protocols the client never even
specified (chrome doesn't specify http/1.0 in alpn) [3].
> The "extension_data"
> field of the ("application_layer_protocol_negotiation(16)") extension
> SHALL be structured the same as described above for the client
> "extension_data", except that the "ProtocolNameList" MUST contain
> exactly one "ProtocolName".
HAProxy responds with all protocols specified with the alpn keyword, instead
of selecting *one single suitable* protocol from the client hello.
Here [4] is a handshake to a google server behaving correctly, by selecting
the single, most suitable protocol in the server hello.
Also, in section 3.2. Protocol Selection:
> It is expected that a server will have a list of protocols that it
> supports, in preference order, and will only select a protocol if the
> client supports it. In that case, the server SHOULD select the most
> highly preferred protocol it supports which is also advertised by the
> client. In the event that the server supports no protocols that the
> client advertises, then the server SHALL respond with a fatal
> "no_application_protocol" alert.
Of course we don't send this alert either, as we don't do any protocol
comparison and selection anywhere.
>From the openssl source file ssl/ssl_lib.c:
> /* SSL_CTX_set_alpn_select_cb sets a callback function on |ctx| that is called
> * during ClientHello processing in order to select an ALPN protocol from the
> * client's list of offered protocols. */
> void SSL_CTX_set_alpn_select_cb(SSL_CTX* ctx,
SSL_CTX_set_alpn_select_cb() is supposed to select the most suitable single
protocol from the client hello.
Looks like we need some additional logic to implement this correctly.
btw: is there any way to easily test this? I don't have a spdy backend
and I didn't find anything relevant in chrome://net-internals/ for
alpn-upgraded http/1.1 connections.
Regards,
Lukas
[1] http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-04
[2] http://cloudshark.org/captures/3e0a8a623142
[3] http://cloudshark.org/captures/293c4d2698d6
[4] http://cloudshark.org/captures/2382b1591cef
