Re: problems getting rpc over tls to work

[Chuck Lever III <chuck.lever@oracle.com>]

> On Mar 28, 2023, at 11:03 AM, Jeff Layton <jlayton@kernel.org> wrote:
> 
> On Tue, 2023-03-28 at 14:45 +0000, Chuck Lever III wrote:
>> 
>>> On Mar 28, 2023, at 10:39 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
>>> 
>>> On Tue, Mar 28, 2023 at 10:29 AM Jeff Layton <jlayton@kernel.org> wrote:
>>>> 
>>>> It's true that it is less secure than having full chain-of-trust, but
>>>> this seems like a case of "perfect being the enemy of good". If we don't
>>>> allow for self-signed certificates, then we've created a rather large
>>>> hurdle for anyone who wants to deploy this.
>>>> 
>>>> One thing we could do is reinstate the tlshd option, but still allow it
>>>> to check the signature. Then it could log something if that check fails
>>>> but still allow the connection.
>>>> 
>>>> We should of course document why using that option is not ideal, but
>>>> ripping it out entirely seems rather draconian. That's just going to
>>>> drive people to not use TLS at all because of the hassle factor.
>>> 
>>> I would argue that "no verification" option should only be allowed in
>>> some extreme cases. Like say having an option that explicitly says
>>> it's running in a debug mode and say on the foreground only (-d -f
>>> --noverify). Having such options might clearly state the intent is to
>>> debug only and not run for any user usage.
>>> 
>>> I also don't see a real reason for "noverify" option except to remove
>>> frustrations during the setup.
>> 
>> I might put it this way: we don't want to have customers installing
>> something on their clients whose out-of-the-shrinkwrap configuration
>> is less than secure. "no verification" is less than secure.
>> 
>> My preference would be to have some kind of way to get self-signed
>> certs working with no client-side configuration needed. If the
>> client mounts with "xprtsec=tls" it should work. Do we need to
>> plumb that into our handshake upcall and make "anonymous"
>> handshakes explicitly allow unrecognized signers?
>> 
> 
> Since the client is the side that's rejecting things, having a mount
> option that allows you to relax that check seems like the right
> approach.
> 
> How about a new xprtsec= option? Maybe "xprtsec=nvtls" (no verify TLS)?
> That would allow things to work out of the box, but still leave
> xprtsec=tls as the more secure method.

Nah. xprtsec=tls is supposed to be less secure: no authentication,
just encryption. The secure method is xprtsec=mtls.

IMO xprtsec=tls needs to skip the signer check. I think I can make
tlshd do that.


--
Chuck Lever