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.
"data is set to NULL ... if no protocol has been selected".
"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_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,
and then if the tls_id 16 is seen  the client did receive
an ALPN extension from the server, distinguishing the above
[I've not tried this, client-side. Server side works fine.]
OpenSSL doesn't seem to give that level of observability.
ietf-smtp mailing list