Received-SPF: pass (google.com: domain of linux-nfs+bounces-1453-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <CAAvCNcBMY1mrgEgy4APSiFXDP5u=64YXNjiHHjh8RscPsB3row@mail.gmail.com>
 <b25436fa457256f0f409fbc33f60c13e8ab6af12.camel@kernel.org>
In-Reply-To: <b25436fa457256f0f409fbc33f60c13e8ab6af12.camel@kernel.org>
From: Cedric Blancher <cedric.blancher@gmail.com>
Date: Fri, 26 Jan 2024 08:22:00 +0100
Message-ID: <CALXu0Uc3t6NgvG_FJRvnTYoXKVi2whOWfysApt5Gj4RhAPn0oQ@mail.gmail.com>
Subject: Re: Implement NFSv4 TLS support with /usr/bin/openssl s_client?
To: Jeff Layton <jlayton@kernel.org>
Cc: Dan Shelton <dan.f.shelton@gmail.com>, 
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>, Benjamin Coddington <bcodding@redhat.com>
Content-Type: text/plain; charset="UTF-8"

On Thu, 25 Jan 2024 at 21:44, Jeff Layton <jlayton@kernel.org> 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.

What about libtirpc-based apps? Is anyone going to add TLS support to libtirpc?

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur