> On Jan 25, 2024, at 8:05 PM, Dan Shelton <dan.f.shelton@xxxxxxxxx> wrote: > > On Thu, 25 Jan 2024 at 22:11, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: >> >> On 25 Jan 2024, at 15:37, Jeff Layton wrote: >> >>> On Thu, 2024-01-25 at 03:21 +0100, Dan Shelton wrote: >>>> Hello! >>>> >>>> Is it possible for a NFSv4 client to implement TLS support via >>>> /usr/bin/openssl s_client? >>>> >>>> /usr/bin/openssl s_client would do the connection, and a normal >>>> libtirpc client would connect to the other side of s_client. >>>> >>>> Does that work? >>>> >>>> Dan >>> >>> Doubtful. RPC over TLS requires some cleartext setup before TLS is >>> negotiated. At one time Ben Coddington had a proxy based on nginx that >>> could handle the TLS negotiation, but I think that might have been based >>> on an earlier draft of the spec. It would probably need some work to be >>> brought up to the state of the RFC. >> >> Yeah, its' a little bit rotted. Wasn't super fresh to begin with, but it >> did help bootstrap some implementation. >> >> You could also modify openssl to be aware of the clear text, something like: >> https://github.com/bcodding/openssl/commit/9bf2c4d66eacccd3530fb2f3a0a6c87d5878348c >> >> .. but I think you're definitely in "what are you really trying to do?" territory. > > For example legacy NFSv4 client add-on? You cannot expect that > everyone can or will update to the latest and greatest version, so > either you have clients without TLS, which is a security risk, or have > a way to retrofit them. The way that retrofit is done today is with an ssh tunnel. This is a description of such a mechanism: https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls Many cloud providers install tooling on their client images to build that tunnel and redirect NFS traffic locally into the tunnel. It's generally transparent to the client's users, except for its performance impact. (cf. Amazon EFS) -- Chuck Lever
