On Sun, May 25, 2025 at 6:47 PM Rick Macklem <rick.macklem@xxxxxxxxx> 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? > --> 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. I should have said "reverse name lookup" and not reverse DNS. Important fqdn names can be put in /etc/hosts and the system configured to look there before DNS. If that is done on the NFS server end, a problem with DNS spoofing should be avoided, I think? rick > 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.) > > 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.) > > 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
