On 6 Jun 2024, at 19:53, Dan Shelton wrote: > 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? That little hack is really only appropriate to retrieve a server's certificates, it will not work as TLS-offload layer. Why not just do an implementation for libtirpc? Ben
