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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp