Re: ALPN support for GnuTLS connections

[Robert Pluim]

>>>>> On Sat, 12 Oct 2024 11:30:41 +0200, Eric Marsden 
>>>>> <eric.marsden@risk-engineering.org> said:

    Eric> On 10/10/2024 15:54, Robert Pluim wrote:
    >> Patch below. Works in my limited testing.

    Eric> Excellent, I can confirm that this works with the PostgreSQL 17.0 use
    Eric> case that I mentioned upthread, as well as with test servers from
    Eric> OpenSSL and Rustls (see the attached test file).

    Eric> Remaining questions in my mind:

    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.

    Eric> (2) The current behaviour of connection failing only depending on the
    Eric> server's ALPN setting is I think less than ideal. If the server is not
    Eric> configured to request ALPN, sending ALPN does not lead to failure. If
    Eric> server is looking for ALPN and wants another protocol, the connection
    Eric> fails. I think the default behaviour should be for the connection to
    Eric> fail if one of the ALPN protocols requested by the client is not
    Eric> selected: this seems to be more consistent and avoids a security
    Eric> attack called ALPACA, https://alpaca-attack.com/. This just requires a
    Eric> change to use GNUTLS_ALPN_MANDATORY (as well as updates to the
    Eric> documentation)

    Eric>         ret = gnutls_alpn_set_protocols (state, protocols, count,
    Eric> GNUTLS_ALPN_MANDATORY);

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".

    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

    Eric> (3) Perhaps you could add the attached tiny patch to the logging
    Eric> support for gnutls.c (which is very verbose), so that an EAGAIN
    Eric> doesn't pollute logs at level 1.

Iʼm reluctant to make such a change: GnuTLS logging is really only for
when things go wrong, and Iʼd rather not handicap it. And this is what
`delete-matching-lines' is for 😺.

Robert
--