On Mon, 26 May 2025, Rick Macklem wrote: > On Sun, May 25, 2025 at 5:09 PM NeilBrown <neil@xxxxxxxxxx> wrote: > > > > On Mon, 26 May 2025, Chuck Lever wrote: > > > On 5/20/25 9:20 AM, Chuck Lever wrote: > > > > Hiya Rick - > > > > > > > > On 5/19/25 9:44 PM, Rick Macklem wrote: > > > > > > > >> Do you also have some configurable settings for if/how the DNS > > > >> field in the client's X.509 cert is checked? > > > >> The range is, imho: > > > >> - Don't check it at all, so the client can have any IP/DNS name (a mobile > > > >> device). The least secure, but still pretty good, since the ert. verified. > > > >> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for > > > >> the client's IP host address. > > > >> - DNS matches exactly what reverse DNS gets for the client's IP host address. > > > > > > > > I've been told repeatedly that certificate verification must not depend > > > > on DNS because DNS can be easily spoofed. To date, the Linux > > > > implementation of RPC-with-TLS depends on having the peer's IP address > > > > in the certificate's SAN. > > > > > > > > I recognize that tlshd will need to bend a little for clients that use > > > > a dynamically allocated IP address, but I haven't looked into it yet. > > > > Perhaps client certificates do not need to contain their peer IP > > > > address, but server certificates do, in order to enable mounting by IP > > > > instead of by hostname. > > > > > > > > > > > >> Wildcards are discouraged by some RFC, but are still supported by OpenSSL. > > > > > > > > I would prefer that we follow the guidance of RFCs where possible, > > > > rather than a particular implementation that might have historical > > > > reasons to permit a lack of security. > > > > > > Let me follow up on this. > > > > > > We have an open issue against tlshd that has suggested that, rather > > > than looking at DNS query results, the NFS server should authorize > > > access by looking at the client certificate's CN. The server's > > > administrator should be able to specify a list of one or more CN > > > wildcards that can be used to authorize access, much in the same way > > > that NFSD currently uses netgroups and hostnames per export. > > > > > > So, after validating the client's CA trust chain, an NFS server can > > > match the client certificate's CN against its list of authorized CNs, > > > and if the client's CN fails to match, fail the handshake (or whatever > > > we need to do). > > > > > > I favor this approach over using DNS labels, which are often > > > untrustworthy, and IP addresses, which can be dynamically reassigned. > > > > > > What do you think? > > > > I completely agree with this. IP address and DNS identity of the client > > is irrelevant when mTLS is used. What matters is whether the client has > > authority to act as one of the the names given when the filesystem was > > exported (e.g. in /etc/exports). His is exacly what you said. > Well, what happens when someone naughty copies the cert. to a different > system? Then you have already lost. Certificates are like passwords. I guess 2FA is a thing and maybe it makes sense to check both IP and certificate. But I certainly wouldn't want to trust only that the IP matches the certificate. I would want to be able to check the certificate without even considering the IP. Maybe: 1/ Is the IP from a permitted subnet - if not, reject. 2/ is the certificate for an approved CN - if not, reject. 3/ Does the IP match the CN 1 and 3 could be optional. 2 shouldn't be. Thanks, NeilBrown
