On Sun, May 18, 2025 at 7:15 PM Dan Shelton <dan.f.shelton@xxxxxxxxx> wrote:
>
> On Wed, 14 May 2025 at 23:51, Martin Wege <martin.l.wege@xxxxxxxxx> wrote:
> > Interoperability is also a big problem (nay, it's ZERO
> > interoperability), as this is basically a Linux kernel client/kernel server only
> > solution.
> > libtirpc doesn't support TLS, Ganesha doesn't support TLS, so yeah,
> > this is an issue, and not a solution.
> >
> > Fazit: Supporting your argumentation with Kerberos5 or TLS is not gonna fly.
>
> I tried to add TLS support to libtirpc, but I think it's simply not
> possible. The APIs are just not compatible.
> Ganesha folks also tried the same, and failed - their ntirpc would
> require a major redesign to support TLS.
Well, I'll admit I don't know if the userspace RPC code in FreeBSD
is considered the tirpc or not. (It's in libc and happens to have Frank's
initials on it from long ago when he worked on it for NetBSD.)
Anyhow, at a quick glance, it doesn't look all that difficult.
The low level functions in clnt_vc.c that do I/O on the socket
are called __msgread() and __msgwrite(). If RPC over TLS is
enabled, those functions would need to use SSL_read() and SSL_write().
When a new TCP connection is created (in clnt_vc_create() in this code),
it then needs to do a Null RPC with AUTH_TLS (7) as the authentication
flavor. If it gets STARTTLS in the reply's verifier, then it does a
SSL_connect(). If that succeeds, it flips some flag to tell the I/O
functions to use SSL_read() and SSL_write().
(There is some arm waving to create the SSL context and associate
the TCP socket with it. You can find all that in the sources for
rpc.tlsclntd.c in FreeBSD.)
I haven't actually done this (I did the daemons and krpc mods for
FreeBSD, but not libc ones), but unless there is some corner
that makes it really difficult, it doesn't look like a lot of work to me.
(If Frank or anyone else wants to do this, they can email me for
more info.)
rick
ps: The biggest hassle is that, once you do it, the applications that
use the library will also need to link in a bunch of SSL
libraries as well.
(The simple thing is to have a separate library version. Since it's in
libc in FreeBSD, this is more bothersome.)
>
> So, why do the NFS folks even bother with NFS over TLS, if it is this
> kind of mismatch?
>
> Dan
> --
> Dan Shelton - Cluster Specialist Win/Lin/Bsd
>
