Re: ALPN: implementation / behaviour

On 10/07/2021 09:23, Claus Assmann wrote:
> It seems there are the following possible cases to handle:
> 1. the other side did not offer/specify ALPN.
> 2. the other side did offer/specify ALPN and there is
>    2.1  a match
>    2.2  no match
> 
> but there is no way to determine case 1 for the client.

SSL_get0_alpn_selected() -
"data is set to NULL ... if no protocol has been selected".

gnutls_alpn_get_selected_protocol()
"On success, GNUTLS_E_SUCCESS (0) is returned,
otherwise a negative error code is returned."

... look as though they'll combine 1. and 2.2


Under GnuTLS you can hook into the handshake operations:
   gnutls_handshake_set_hook_function(state->session,
             GNUTLS_HANDSHAKE_ANY, GNUTLS_HOOK_POST, tls_server_hook_cb);

in the callback, spot an htype GNUTLS_HANDSHAKE_SERVER_HELLO
split by extension:
   gnutls_ext_raw_parse(NULL, tls_server_serverhello_ext, msg,
                            GNUTLS_EXT_RAW_FLAG_TLS_CLIENT_HELLO);
and then if the tls_id 16 is seen [1] the client did receive
an ALPN extension from the server, distinguishing the above
cases.

[I've not tried this, client-side.  Server side works fine.]


OpenSSL doesn't seem to give that level of observability.
-- 
Cheers,
   Jeremy


[1] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml