Re: ALPN support for GnuTLS connections

[Eric Marsden <eric.marsden@risk-engineering.org>]

On 14/10/2024 11:22, Robert Pluim wrote:
>>>>>> On Sat, 12 Oct 2024 11:30:41 +0200, Eric Marsden <eric.marsden@risk-engineering.org> said:
>      Eric> (1) It would be useful for elisp code to be able to determine whether
>      Eric> Emacs has ALPN support. The elisp code will generally know that the
>      Eric> service it's connecting to requires ALPN, and it would be useful to be
>      Eric> able to inform the user that they should upgrade Emacs, instead of
>      Eric> getting a generic "connection failed" error. The C preprocessor test
>      Eric> HAVE_GNUTLS_ALPN_SET_PROTOCOLS  isn't visible from elisp, nor is (I
>      Eric> think?) the binding to gnutls_alpn_set_protocols. This might also be
>      Eric> useful for other features such as the AEAD support. Perhaps a function
>      Eric> such as gnutls-feature-available-p(:alpn) ?
>
> `gnutls-available-p' returns a list of available TLS features, we can put
> "alpn" in there. AEAD is already there.
OK, that sounds good to me, thanks.

> Yes, in order to palliate servers not following the requirement to be
> strict, the recommendation is for the client to be strict. I donʼt
> mind that, although we should add a way to turn it off. Perhaps an
> ":alpn-flags" parameter with symbols for the two current flags, plus
> one that means "zero".
Also sounds good.

>      Eric> In fact I see reading the ALPACA web page that TLS clients are
>      Eric> recommended to use the SNI extension to indicate the server name that
>      Eric> they wish to connect to, which gnutls.c is not currently doing. One
>      Eric> thing at a time!
>
> gnutls.c has been sending SNI since 2014
Thanks for the correction.

Eric