On Sun, May 25, 2025 at 7:29 PM NeilBrown <neil@xxxxxxxxxx> wrote:
>
> 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.
True. But if the IP address must match that of the client's IP host address, it
limits where the cert. (or password, if you like) can be used.
(The subnet where the IP address is supported, for example.)
Without this, a compromised cert. can be used from anywhere.
>
> 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.
I'm not sure #2 makes it stronger than just "it verified", since
verified means that the "password" is correct.
Now, I agree that the CN (or cert. serial# or anything else in the cert)
can be used to distinguish which certs. are allowed for which file system
exports. (Saves having different issuers to differentiate the certs.)
--> Put another way, the CN can be used to decide which file systems
can be accessed and how, but it is not really useful to just say
that the cert. is valid, since verification has already done that.
I also agree #1 and #3 are optional and their use really depends on
what the network topology for client->server is and ranges from useless
up to useful, I think?
rick
>
> Thanks,
> NeilBrown
>
