On Fri, 26 Jan 2024 at 02:05, 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. Is there a public NFSv4.1 server with TLS enabled, which I can use to test whether openssl with https://github.com/bcodding/openssl/commit/9bf2c4d66eacccd3530fb2f3a0a6c87d5878348c can be used to plug in older clients? Dan -- Dan Shelton - Cluster Specialist Win/Lin/Bsd
