Re: problems getting rpc over tls to work

From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: "kernel-tls-handshake@lists.linux.dev"
	<kernel-tls-handshake@lists.linux.dev>
Subject: Re: problems getting rpc over tls to work
Date: Tue, 28 Mar 2023 10:29:19 -0400	[thread overview]
Message-ID: <5f624bc3a8e900dc967cea5dfada5f9a94fa14b1.camel@kernel.org> (raw)
In-Reply-To: <430FEF8D-0953-4A24-9DC6-D53CFE211C05@oracle.com>

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.

> > 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.
-- 
Jeff Layton <jlayton@kernel.org>