[Top] [All Lists]

Re: [ietf-smtp] ALPN: implementation / behaviour

2021-07-10 08:55:15
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".

"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 [1] 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

<Prev in Thread] Current Thread [Next in Thread>