Re: problems getting rpc over tls to work

[Olga Kornievskaia <aglo@umich.edu>]

On Tue, Mar 28, 2023 at 11:19 AM Olga Kornievskaia <aglo@umich.edu> wrote:
>
> 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.

Sorry Ok we are discussing no authentication. But my point was "TLS"
in its know doesn't mean less secure and always does server side
authentication. In the early days of TLS, you could choose to do pure
Diffie hellman and that was "no authentication" but that's no longer
an option.

HTTPS explicitly prompts that user to do manual verification (ie when
it couldn't verify using existing CAs). It never allows for "no
verification" which we are discussing here.

> > 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
> >
> >