Received-SPF: pass (google.com: domain of linux-nfs+bounces-1436-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Benjamin Coddington <bcodding@redhat.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Dan Shelton <dan.f.shelton@gmail.com>,
 Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Implement NFSv4 TLS support with /usr/bin/openssl s_client?
Date: Thu, 25 Jan 2024 16:11:37 -0500
Message-ID: <96A320F4-AFC1-4DD9-8D5D-784F13DE94D4@redhat.com>
In-Reply-To: <b25436fa457256f0f409fbc33f60c13e8ab6af12.camel@kernel.org>
References: <CAAvCNcBMY1mrgEgy4APSiFXDP5u=64YXNjiHHjh8RscPsB3row@mail.gmail.com>
 <b25436fa457256f0f409fbc33f60c13e8ab6af12.camel@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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 base=
d
> 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 li=
ke:
https://github.com/bcodding/openssl/commit/9bf2c4d66eacccd3530fb2f3a0a6c8=
7d5878348c

=2E. but I think you're definitely in "what are you really trying to do?"=
 territory.

Ben