Add an option to disable server certificate validation on the client

[chucklever]

We've had several independent requests (and a PR or two) to re-add support for the "-n" option, which disables tlshd's server certificate validation checking when it runs on the client. Checking would be disabled only for "encryption-only" mode -- for mtls, both peers would continue to validate the other's certificate.

The argument is that it makes code development easier, or that it simplifies deployment. When debugging or developing code, it should be simple enough to use self-signed certificates, and distribute an appropriate CA bundle for these certificates. We don't feel this is a compelling use case at this time.

The main use case, then, would be the desire to make the deployment of clients that need only encryption completely free from the problems of distributing certificate material. Currently one can do this only when the server's certificate has been signed by a well-known certificate authority that is likely to already be present on clients.

Notably, however, without server certificate validation, a man-in-the-middle can pretend to be a server and thus intercept TLS sessions from a client. This renders encryption rather pointless.

I'm opening this issue to continue the discussion: Does deployment convenience outweigh strong security? Conversely, is there a secure way to deliver a configuration setting that makes client set-up simpler? Comment below.

[grawity]

is there a secure way to deliver a configuration setting that makes client set-up simpler?

I am guessing this mostly applies to end-user devices that won't have the correct CA, and assuming that end-user devices would use Kerberos instead of sec=sys for the same reason. Would those be able to use Kerberos with TLS channel bindings, or is that impossible to implement in NFS?

(MS-RDP is often used this way, with CredSSP first doing a TLS handshake with a self-signed certificate followed by authenticating both sides via Kerberos and finally exchanging Kerberos-signed TLS verification.)

[chucklever]

I am guessing this mostly applies to end-user devices that won't have the correct CA

Not really. The requests have come from developers who want a fast way to set up systems for testing, without also having to provision a CA.

Most operating systems today already come with a set of pre-installed root CAs. An end-user device manufacturer can very easily obtain a certificate whose trust chain is anchored with one of these popular CAs to provide good assurance that the certificate will be recognized as valid.

and assuming that end-user devices would use Kerberos instead of sec=sys for the same reason.

I don't believe so. Kerberos requires a reachable KDC and a unique key in a keytab. So it would be even less convenient in that scenario IMO.

Would those be able to use Kerberos with TLS channel bindings, or is that impossible to implement in NFS?

RFC9289 does mention the use of channel binding for composing the use of TLS with Kerberos.