Re: Diskless NFS over TLS
- In reply to: Peter Jeremy : "Re: Diskless NFS over TLS"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 03 Jul 2023 01:29:49 UTC
On Tue, Jun 27, 2023 at 3:17 AM Peter Jeremy <peterj@freebsd.org> wrote: > > On 2023-Jun-24 06:40:34 -0700, Rick Macklem <rick.macklem@gmail.com> wrote: > >On Sat, Jun 24, 2023 at 6:15 AM Rick Macklem <rick.macklem@gmail.com> wrote: > >> > >> On Sat, Jun 24, 2023 at 2:24 AM Peter Jeremy <peterj@freebsd.org> wrote: > >> > I am contemplating whether it's possible to use secure NFS for at least > >> > the root mount[*]. The problem is that NFS-over-TLS relies on > >> > rpc.tlsclntd to perform the STARTTLS and that needs a functional > >> > userland to run it. > >> At this point, I do not think the "tls" option can be added via "mount -u". > >> I had assumed that users would want "on the wire encryption, etc" to > >> be done right away, before any non-encrypted data travels across the > >> wire. > > That would be ideal but I agree it would be be difficult to implement. > In particular, it would mean the boot loader would need to perform > the TLS handshake. > > >Btw, to make this work for your case would be non-trivial, since the > >old (non-TLS) > >TCP connection would need to continue to work until the TLS handshake upcall > >to the daemon is completed. And the, the TCP connection used for NFS RPCs > >would need to be switched to use the new TLS/TCP connection. This is not how > >the krpc works now, so I am not exactly volunteering to do this, even if others > >think it is a good idea. > > Thanks for that. I'll consider it infeasible for now. Yep. The Linux folk put the TLS handshake in the kernel, but I do not see FreeBSD doing that (it has to be maintained, among other reasons it is a bit scary to do). > > >> Can you put all the data that needs to be secured on a separate volume and > >> mount that from /etc/fstab? (I'm sure you have thought of this, but...) > >> Note that there is overhead in using NFS-over-TLS (mostly CPU overhead, > >> assuming you do not have hardware offload), so you only want to use it > >> when there is data that needs to be secured. > > I was thinking more of relying on TLS for better protection against > network issues and also trying to move towards a zero-trust network. > The main problem is that one of the pieces of data needing to be > secured is the NFS TLS keys needed to mount the secure volume. > > Thinking more, I'm not sure how much value NFS-over-TLS provides unless > I can secure the boot process (DHCP and TFTP) as well. I'm about as unknowledgible w.r.t. security as they come, but something like Intel's SGX might work? rick > > Thank you for your input. > -- > Peter Jeremy