Re: Diskless NFS over TLS

From: Rick Macklem <rick.macklem_at_gmail.com>
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