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
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
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.
--
Jeff Layton <[email protected]>
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.
Ben
On Thu, 25 Jan 2024 at 22:11, Benjamin Coddington <[email protected]> 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.
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
> On Jan 25, 2024, at 8:05 PM, Dan Shelton <[email protected]> wrote:
>
> On Thu, 25 Jan 2024 at 22:11, Benjamin Coddington <[email protected]> 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.
The way that retrofit is done today is with an ssh tunnel.
This is a description of such a mechanism:
https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls
Many cloud providers install tooling on their client images
to build that tunnel and redirect NFS traffic locally into
the tunnel. It's generally transparent to the client's users,
except for its performance impact.
(cf. Amazon EFS)
--
Chuck Lever
On Thu, 25 Jan 2024 at 21:44, Jeff Layton <[email protected]> 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 <[email protected]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
?
On Fri, 26 Jan 2024 at 08:23, Cedric Blancher <[email protected]> wrote:
>
> On Thu, 25 Jan 2024 at 21:44, Jeff Layton <[email protected]> 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 <[email protected]>
> [https://plus.google.com/u/0/+CedricBlancher/]
> Institute Pasteur
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
On Fri, 26 Jan 2024 at 02:05, Dan Shelton <[email protected]> wrote:
>
> On Thu, 25 Jan 2024 at 22:11, Benjamin Coddington <[email protected]> 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
On 6 Jun 2024, at 19:53, Dan Shelton wrote:
> On Fri, 26 Jan 2024 at 02:05, Dan Shelton <[email protected]> wrote:
>>
>> On Thu, 25 Jan 2024 at 22:11, Benjamin Coddington <[email protected]> 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