On 5/27/25 12:29 PM, Rick Macklem wrote: > On Tue, May 27, 2025 at 8:05 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> On 5/25/25 8:09 PM, NeilBrown 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. >>> >>> 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. >> >> My thought is that, for each handshake, there would be two stages: >> >> 1. Does the NFS server trust the certificate? This is purely a chain-of- >> trust issue, so validating the certificate presented by the client is >> the order of the day. >> >> 2. Does the NFS server authorize this client to access the export? This >> is a check very similar to the hostname/netgroup/IP address check >> that is done today, but it could be done just once at handshake time. >> Match the certificate's fields against a per-export filter. >> >> I would take tlshd out of the picture for stage 2, and let NFSD make its >> own authorization decisions. Because an NFS client might be authorized >> to access some exports but not others. >> >> So: >> >> How does the server indicate to clients that yes, your cert is trusted, >> but no, you are not authorized to access this file system? I guess that >> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC. >> >> What certificate fields should we implement matches for? CN is obvious. >> But what about SAN? Any others? I say start with only CN, but I'd like >> to think about ways to make it possible to match against other fields in >> the future. > Just fyi, here's an example where filtering on the DNS or IP field in the > SAN (SubjectAltName) could improve security.. > (Dusting off my CS sysadmin hat.) > > Suppose I had a file system where student grades and exam questions > were stored. > The mount was restricted to faculty offices, where their machines had fixed > well known IP addresses and FQDNs assigned. > However, as it was for my case, the building their offices were in also had > student labs and the building was assigned a subnet by the campus > networking folk. > --> As such, a student could easily come in off hours (when the faculty were not > around and, as such, had their office computers shut down) and > plug into the > subnet (they just had to find an RJ45 jack somewhere that they > could access). > --> They could then set their laptop up with the same IP address > as a faculty > member's office computer and defeat ordinary /etc/exports > filtering based > on client IP address. > > However, these students would not have the X.509 cert. with a DNS or IP field > set to the correct address in it. (They might have a valid cert. so > their laptop can > mount the file systems students have coursework assignments on, but it would > not have the DNS or IP of a faculty member's office computer.) > --> This additional filtering would stop them from accessing the > marks/exam question > file system (or at least make it a lot harder for them to do so). > > As already discussed, there is a tradeoff between using DNS or IP. (I'll admit > FreeBSD doesn't currently support the IP case, but it probably should.) To be clear, there is a marked difference between relying on reverse DNS queries versus relying on a DNS hostname or IP address contained in a client certificate's SAN field. DNS queries are untrustworthy, but fields in a certificate (once its trust chain has been validated) are OK to use, IMO. But I would like NFSD's administrative interface to be unambiguous about which DNS/IP information is being matched against. > rick > >> >> What would the administrative interface look like? Could be the machine >> name in /etc/exports, for instance: >> >> *,OU="NFS Bake-a-thon",* rw,sec=sys,xprtsec=mtls,fsid=42 >> >> But I worry that will not be flexible enough. A more general filter >> mechanism might need something like the ini file format used to create >> CSRs. >> >> >> What about pre-shared keys? No certificate fields there. >> >> >> -- >> Chuck Lever -- Chuck Lever
