Re: problems getting rpc over tls to work

[Olga Kornievskaia <aglo@umich.edu>]

On Tue, Mar 28, 2023 at 10:29 AM Jeff Layton <jlayton@kernel.org> wrote:
>
> On Tue, 2023-03-28 at 14:04 +0000, Chuck Lever III wrote:
> >
> > > On Mar 28, 2023, at 8:55 AM, Jeff Layton <jlayton@kernel.org> wrote:
> > >
> > > I wonder...should we have the ktls-utils package install a self-signed cert by default?
> >
> > So this idea is intriguing, I had some similar thoughts.
> >
> > I'm not sure what the security implications of all this are.
> > We'd first need to look at other certificate-based packages
> > in Fedora to see if they offer a similar quick-setup. The
> > cert would have to be created at install time.
> >
> >
>
> I think when apache is installed, a self-signed cert is created. You
> don't have to use it, but it's what gets initially installed.

The problem I see with the plan is that the client (which will be
installing ktlsd) needs the server's certificate (not its own). So
installing a self-signed certificate helps with having one but is far
from having a no hassle install. I think having clear steps about how
to get server's cert installed into the client's trusted CA chain in
the man page would go a long way.

> > > I created a self-signed
> > > cert and tried to use it, but the client rejects it with this:
> > >
> > >    Mar 28 09:01:20 nfsclnt tlshd[1092]: Certificate signer not found.
> > >
> > > Is there a way to make it not try to validate the cert chain?
> >
> > Olga also found that self-signed server certs are not
> > working as we'd like. tlshd had a mechanism to force the
> > clients not to check the signer, but it was removed
> > because it was deemed insecure.
> >
> > I'd like to find a way to make self-signed work seamlessly.
> >
>
> Ditto. A lot of people are going to want to use TLS opportunistically
> without deploying their own CA and issuing "real" certificates.
>
> 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.

> --
> Jeff Layton <jlayton@kernel.org>
>