Add Kernel TLS to btrfs send/receive

[ivzhh]

Currently, btrfs send outputs to a pipe or a file; btrfs receive inputs from a pipe or a file. The pipe can be a SSH or a stunnel connection. btrfs send/receive itself doesn't handle any connection.

Kernel introduces TLS in version 4.13 (referred as ktls). Ktls provides a transparent TLS 1.2/1.3 connection: from user space aspect, applications use a normal socket fd to read/write from/to. This model fits into btrfs send's design well: btrfs first writes to a pipe and then splices data from pipe to the final fd (which is a file or pipe). Ktls simply replaces the final fd with the ktls socket fd. According to ktls' author, ktls can boost performance for 2~7%. Ktls helps less on receiving side: btrfs receive processes data in user space. But btrfs receive still can use transparent TLS layer.

I have implemented ktls for btrfs send/receive. Here are the key features:

• Use GnuTLS for handshake. OpenSSL is not suitable for this task, we need to pass IV and key from handshake session to kernel setting.
• Use PSK (pre-shared key) for handshake. User can use --key to use a key file or input password on prompt.
• Key file is checked as PEM format first; if it fails, key file is treated as raw binary file.
• Three TLS modes are supported: TLS 1.2 + GCM 128/256, TLS 1.3 + GCM 128.
• DTLS, certificate, Secure Remote Password (SRP) are not supported yet.

Would you mind to consider about this feature? Thanks!

[ivzhh]

Hi David, I have uploaded my patches to mail list. I am not sure whether this patch set is within btrfs-progs' roadmap. Would you mind to leave some comments? Thank you!

[kdave]

Sorry for late reply. There's some work pending for send/receive so I'll evaluate the ktls support as well.

As this quite independent and just adding a layer I'll probably add it under the experimental build. I'm a bit concerned about adding another dependency (gnutls), I wonder if it would be possible to reuse eg. an external utility in case ktls is not built in to btrfs-progs. For example, pipe through openssl or use the implementation in kernel crypto via kcapi. I don't think there's a fallback implementation of the whole TLS so we can't have own implementation inside progs like there's for the hash algorithms.

If I understand the usecase correctly, it's generating an encrypted stream right out of the send ioctl and needs the certificate to decrypt on the other side. Alternatively one would have to pipe the send stream through some other encryption process, like gpg. The ktls could save some processing and the certificates are standardized, so all the building blocks are ready.

Listening on socket could be useful on itself so I might change that to be a generic flag and not relaetd to ktls, but that's a minor thing to be changed.