Re: Potential kTLS issue with TLS-PSK, GnuTLS + Rawhide - how to debug it?
Hello Simon,
Thanks for looking into it!
Simon Farnsworth <simon(a)farnz.org.uk> writes:
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(a)gmail.com>
> 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(a)gmail.com>
>
> 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.
Yes, that is the case. With gnutls-cli:
$ gnutls-cli -d1 -p 5556 localhost --pskusername psk_identity --pskkey "..."
--priority NORMAL:-KX-ALL:+ECDHE-PSK
|<1>| disabling KTLS: failed to set keys
If you disable CHACHA20-POLY1305, it works without that message:
$ gnutls-cli -d1 -p 5556 localhost --pskusername psk_identity --pskkey "..."
--priority NORMAL:-CHACHA20-POLY1305:-KX-ALL:+ECDHE-PSK
I've filed an issue so those ciphersuites are eventually supported:
https://gitlab.com/gnutls/gnutls/-/issues/1434
Regards,
--
Daiki Ueno