Received-SPF: pass (google.com: domain of linux-nfs+bounces-3580-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: Benjamin Coddington <bcodding@redhat.com>
To: Dan Shelton <dan.f.shelton@gmail.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Implement NFSv4 TLS support with /usr/bin/openssl s_client?
Date: Fri, 07 Jun 2024 07:08:04 -0400
Message-ID: <44A8B3C5-9486-40A3-9D2D-C317A0208A50@redhat.com>
In-Reply-To: <CAAvCNcAe4ho539uhJ32qQJj5dBxBBAbKgPXXC15R4b=axtEvGA@mail.gmail.com>
References: <CAAvCNcBMY1mrgEgy4APSiFXDP5u=64YXNjiHHjh8RscPsB3row@mail.gmail.com>
 <b25436fa457256f0f409fbc33f60c13e8ab6af12.camel@kernel.org>
 <96A320F4-AFC1-4DD9-8D5D-784F13DE94D4@redhat.com>
 <CAAvCNcBjuTLwsLb7nQxaS_O8PVLGPxk=6y2Wj8rp3se0+YxvPQ@mail.gmail.com>
 <CAAvCNcAe4ho539uhJ32qQJj5dBxBBAbKgPXXC15R4b=axtEvGA@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On 6 Jun 2024, at 19:53, Dan Shelton wrote:

> On Fri, 26 Jan 2024 at 02:05, Dan Shelton <dan.f.shelton@gmail.com> wro=
te:
>>
>> On Thu, 25 Jan 2024 at 22:11, Benjamin Coddington <bcodding@redhat.com=
> 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 th=
at
>>>> could handle the TLS negotiation, but I think that might have been b=
ased
>>>> 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, bu=
t it
>>> did help bootstrap some implementation.
>>>
>>> You could also modify openssl to be aware of the clear text, somethin=
g like:
>>> https://github.com/bcodding/openssl/commit/9bf2c4d66eacccd3530fb2f3a0=
a6c87d5878348c
>>>
>>> .. 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/9bf2c4d66eacccd3530fb2f3a0a6=
c87d5878348c
> 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