tlshd: Kernel should not parse incoming client certificates

NFSD depends on seeing a non-zero remote peerid to know when the new
session has been authenticated via mTLS. NFSD does not parse the
incoming certificate, but tlshd tries to make it available to the
kernel and kernel consumers by adding it to the SPEC keyring.

However, add_key(2) /does/ parse the incoming certificate, and any
parsing failure results in failure to add the certificate to the
keyring. A parsing failure might be the result of an unrecognized
(but nonetheless valid) signature encryption algorithm. This will
become even more of a hazard as support for PQ signing algorithms
is introduced.

Key insertion failure causes tlshd to use TLS_NO_PEERID as the
remote peer ID. When this happens, a session which is successfully
authenticated by GnuTLS looks unauthenticated to NFSD, possibly
resulting in rejection of an NFS mount attempt.

We don't need or want the kernel or kernel TLS servers to parse
incoming certificates, especially now that tlshd is going to set
x.509 tags on each session.

Replace the add_key(2) call with a fixed special peerid value that
indicates successful mutual authentication. This solution is
reasonably backward compatible with all existing kernel TLS
support.

(I suspect the client side is going to have a similar problem).

Signed-off-by: Chuck Lever <[email protected]>

Author: chucklever

src/tlshd/server.c

@@ -287,7 +287,7 @@ static int tlshd_server_x509_verify_function(gnutls_session_t session,
 			gnutls_x509_crt_deinit(cert);
 			return GNUTLS_E_CERTIFICATE_ERROR;
 		}
-		peerid = tlshd_keyring_create_cert(cert, parms->peername);
+		peerid = UINT_MAX;
 		g_array_append_val(parms->remote_peerids, peerid);
 		gnutls_x509_crt_deinit(cert);
 	}