Re: ktls-utils client address verification and other patches

[Chuck Lever <chuck.lever@oracle.com>]

On 6/8/25 6:51 AM, Ken Milmore wrote:
> I've been evaluating the use of mtls to secure NFS mounts and have noticed there's a fairly serious limitation:
> Any client which has a valid certificate can impersonate a different client, since the server does not verify client address.
> 
> This is unfortunate, as I'd like to give different clients access to different NFS shares by naming the clients in /etc/exports,
> and I'd like to use mtls to ensure that each client not only has a trusted certificate, but that it is only able to access the
> shares to which it is entitled by /etc/exports. In other words, I want to verify the client host name or address against the
> client certificate to avoid address spoofing.
> 
> I can understand why this is not the default behaviour: In general, a server will not be able to verify clients in this way.
> But for NFS on a personal or corporate LAN, it is highly desirable.
> 
> To this end, I've developed some patches which allow the tlshd server to be configured to instruct GnuTLS to perform client
> address verification.
> 
> Please see patch series here:
> 
> https://codeberg.org/kbm0/ktls-utils/commits/branch/verification-patchset
> 
> Because the server can only obtain the client hostname by reverse address lookup, and this has security implications, I have
> been careful to confirm the hostname first by performing a forward lookup in the manner of FCrDNS: We call getaddrinfo() and
> check that one of the resulting addresses matches the one which was obtained from the reverse lookup. Should this check fail,
> we reject the certificate.
> 
> I've also added an option to use a textualized IP/IPv6 address for verification against the certificate, in cases where no DNS
> address can be found. This works if the certificate includes the client IP address as an alternative name. It is also possible
> to use the IP address as the first recourse, and this may be useful in some circumstances - it is possible for client and server
> to verify each other entirely based on IP addresses with no reliance on DNS, if the certificates are set up correctly.
> 
> These behaviours are enabled by setting options in tlshd.conf like so:
> 
> [authenticate.server]
> verify_peername=true
> verify_peeraddr=true
> 
> Another issue I came across involves the fact that when a client connects to a server, the server name is passed to GnuTLS for
> the purposes of SNI. If the client connects with a bare IP or IPv6 address, this is not strictly allowed, as only DNS names may
> be used for SNI. This causes the server to reject the transaction. I've added an option to omit the SNI in cases where the client
> is connecting using an IP address:
> 
> [authenticate.client]
> relax_sni=true
> 
> There are some other patches in the series: I wanted to textualize the peer address up front so it can be used for both logging
> and also for verification.
> 
> I also thought some of the processing in netlink.c looked a bit sloppy: Optimistic assumptions were being made about the
> contents of return buffers when functions like getnameinfo() are called. I have tried to correct these.
> 
> I am hoping for some informal review or feedback for these patches in the first instance. I didn't want to just spam the mailing
> list with them upfront. If there is any interest in them, I will submit them formally.

Some general comments:

Essentially we don't want to make certificate validation dependent on
DNS for any reason, since DNS is easily spoofed. Have you considered
putting the client's IP address in it's certificate's SAN field?

Further, there will be plenty of cases where clients obtain their IP
address dynamically. In those cases the server needs to perform its
certificate validation based solely on what is in the certificate.

But meanwhile, you can post your patches to this mailing list (inline,
not as attachments) one at a time, and we can have a look at each
individual proposal.


-- 
Chuck Lever