On 5/25/25 9:47 PM, 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? When that copy is discovered, the server can use a CRL to fence the use of the copied certificate (and as Rik T. pointed out, NFSD does not yet support that kind of mechanism). > --> It is true that verification will show that the cert. is valid, but is it > valid for that client system? > (Not checking the reverse DNS name makes the check somewhat weaker, > imho. Now, is having the IP address in the cert. and checking > that stronger. > Well, maybe. The hassle is that the certs. all have to be replaced when > some network type decides to reconfigure the LANs or move the system > onto a different subnet for some reason.) None of that works for NFS clients whose name and address are dynamically assigned. > Another way a cert. can be protected from being moved to a different client > by someone naughty is adding a passphrase to it (the -aes256 option on > the openssl command line when creating the CSR). The hassle is that > someone has to type the passphrase in when the system is started/rebooted. > > There is no perfect solution (or security is not a binary value, if > you prefer), so > I chose to provide as many options as I could, so that sysadmins could choose > what works for them. (Of course, they need to understand what is going on and > documenting that can be a challenge.) Fair. Our implementations might differ in this regard. > rick > >> >> Ideally it would be more than just the CN. We want to know both the >> domain in which the peer has authority (e.g. example.com) and the type >> of authority (e.g. serve-web-pages or proxy-file-access or >> act-as-neilb). >> I don't know internal details of certificates so I don't know if there >> is some other field that can say "This peer is authorised to proxy file >> access requests for all users in the given domain" or if we need a hack >> like exporting to nfs-client.example.com. >> >> But if the admin has full control of what names to export to, it is >> possible that the distinction doesn't matter. I wouldn't want the >> certificate used to authenticate my web server to have authority to >> access all files on my NFS server just because the same domain name >> applies to both. >> >> Thanks, >> NeilBrown -- Chuck Lever
