Re: problems getting rpc over tls to work

[Olga Kornievskaia <aglo@umich.edu>]

On Tue, Mar 28, 2023 at 11:06 AM Chuck Lever III <chuck.lever@oracle.com> wrote:
>
>
>
> > 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.

What's the point of "no authentication". I thought the server is
always authenticated.

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

I guess in that case, I (grudgingly) agree with something like
xprtsec=anonymous/nvtls".

>
>
> --
> Chuck Lever
>
>