Re: problems getting rpc over tls to work

[Jeff Layton <jlayton@kernel.org>]

On Tue, 2023-03-28 at 10:50 -0400, Olga Kornievskaia wrote:
> On Tue, Mar 28, 2023 at 10:45 AM Chuck Lever III <chuck.lever@oracle.com> 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?
> 
> My vote is not allow for insecure installs (ever).
> 


Is it really better to force people into plaintext connections? I very
much disagree here. Raise your hand if you've never used cURL with
"--insecure" or told Mozilla to accept a bogus cert.

> Perhaps ktlsd install on the client can prompt the user asking for
> location of either server's self-signed cert or server's CA and this
> way it would have everything that's needed before using it?
> 
> 

NAK. Interactive package installs are no bueno.
-- 
Jeff Layton <jlayton@kernel.org>