Re: problems getting rpc over tls to work

[Jeff Layton <jlayton@kernel.org>]

On Tue, 2023-03-28 at 15:05 +0000, Chuck Lever III 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.
> 
> IMO xprtsec=tls needs to skip the signer check. I think I can make
> tlshd do that.
> 
> 

It's your call, but allowing the client to check the certificate without
requiring the server to do so seems like it'd be a good thing to allow.
Maybe there should be a new option for that instead then?

Either way, I'm not sure skipping the signer check altogether is the
best thing. It'd probably be good to check it, and just not fail the
connection if it fails. Have it log a message on each handshake instead
so that the admin is aware that the endpoint is not verified.
-- 
Jeff Layton <jlayton@kernel.org>