On Friday, 25 November 2022 13:57:26 GMT Richard W.M. Jones wrote: > Turns out this is fixed in upstream gnutls (not the version in > Rawhide). The commit which fixes it is: > > commit 67843b3a8e28e4c74296caea2d1019065c87afb3 > Author: Frantisek Krenzelok <krenzelok.frantisek@xxxxxxxxx> > Date: Mon Sep 5 13:05:17 2022 +0200 > > KTLS: fallback to default > > If an error occurs during setting of keys either initial or key update > then fallback to default mode of operation (disable ktls) and let the > user know > > Signed-off-by: Frantisek Krenzelok <krenzelok.frantisek@xxxxxxxxx> > > lib/handshake.c | 7 ++++++- > lib/tls13/key_update.c | 23 +++++++++++++++++++---- > 2 files changed, 25 insertions(+), 5 deletions(-) > > With full debugging you can see the message caused by this commit: > > nbdkit: null[1]: debug: gnutls: 4: HSK[0x7fc9e00010a0]: TLS 1.3 set read key > with cipher suite: GNUTLS_CHACHA20_POLY1305_SHA256 nbdkit: null[1]: debug: > gnutls: 13: BUF[HSK]: Emptied buffer > nbdkit: null[1]: debug: gnutls: 13: BUF[HSK]: Emptied buffer > nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Start of epoch > cleanup nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Epoch #0 > freed nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Epoch #1 > freed nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: End of epoch > cleanup nbdkit: null[1]: debug: gnutls: 1: disabling KTLS: failed to set > keys > Is this because kTLS doesn't support PSK? > kTLS doesn't do key management, so it doesn't know the difference between PSK and X.509 (it gets the symmetric keys from userspace after the key exchange is done). However, looking at https://gitlab.com/gnutls/gnutls/-/blob/master/lib/system/ ktls.c, GnuTLS only supports using kTLS with GNUTLS_CIPHER_AES_128_GCM and GNUTLS_CIPHER_AES_256_GCM cipher suites, while your debugging output shows that this connection is using GNUTLS_CHACHA20_POLY1305_SHA256. As a result, the upstream fix you point to does the right thing because you can't use GnuTLS's kTLS support on this connection (at all), and the only thing that makes sense is to disable kTLS. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ include/uapi/linux/tls.h suggests that kTLS has some degree of support for ciphers other than the two GnuTLS enables it for, but I don't know enough about TLS to know whether enabling all the ciphers current kernels support in GnuTLS would enable it to be used for this connection. -- Simon Farnsworth _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
