Date: Sat, 21 Mar 2020 11:10:38 +0100 From: Alexander Leidinger <Alexander@leidinger.net> To: John-Mark Gurney <jmg@funkthat.com> Cc: Rick Macklem <rmacklem@uoguelph.ca>, freebsd-current@freebsd.org Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <20200321111038.Horde.rgAGgZxVa9iVtXMBf4CIY2q@webmail.leidinger.net> In-Reply-To: <20200320192923.GK4213@funkthat.com> References: <YTBPR01MB3374EFF14948CB8FEA1B5CCDDDE50@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> <20200319191605.GJ4213@funkthat.com> <YTBPR01MB337407CFCBE26DBAB1BC985ADDF40@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> <20200320192923.GK4213@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Quoting John-Mark Gurney <jmg@funkthat.com> (from Fri, 20 Mar 2020 12:29:23 -0700): >> to be the best solution. The server can verify that the certificate >> was issued by >> the local CA. Unfortunately, if the client is compromised and the >> certificate is copied >> to another client, that client would gain access. > > This is why CRLs/OSCP is necessary, but there isn't anything you can do > to prevent that. This is both a better situation than what we have > today (no auth/confidentiality), and if you tie the cert to an IP, it's > of limited use, and better than today... There are multiple ways to handle that: - First of all, you can just validate based upon "cert is signed by trusted CA". - Then you can require that the CN matches the hostname and the reverse lookup matches. - Or (similar to browsers today) you can ignore the CN and require that the hostnames of the client matches one of the subject alternative name (SAN) entries (requires reverse DNS lookup to work and match). At this point you prevent simple cert theft as additionally you require that someone also has to be able to modify the DNS (or NFS server hosts file, but then he probably can already add an additional cert to the truststore of nfsd). Additional protection is possible by also adding the IP to the SAN. I haven't put an effort into evaluating if either IP or DNS is enough from a security point of view, or if it makes a difference if the "IP in SAN" case has an additional benefit in terms of security if it is in addition to the reverse DNS requirement. Yes this makes it more inconvenient to change the IP of a host, but if all the policy possibilities are up to the admin to configure (e.g. "cert is signed by trusted CA" as a default, and all the other possibilities as an option for nfsd), it is up to the admin and the security requirement. In general, all the possibilities are can either be distinct, or accumulative. There is also the possibility that you do not go with any CA but configure X self-signed certs for X clients as being trusted and the cert of the client needs to be an exact match with one of the X self-signed certs in the truststore. Whatever the policy(/ies) is/are in nfsd, I suggest to make it explicit in the docs what is required and what is checked for each policy. And even if it may be obvious for you Rick, please also print out why a client was rejected. Unfortunately I've seen a lot of cases where the error is a simple/frustrating "certificate rejected", but no info which part of the certificate check failed. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJedegeAAoJEBINsJsD+NiGFrMP/0bCJo3ptWPWlm5Nl0Ci+m5O d4LGTmgyZ2DNPW5nkuT6fc5R5rNGZb+WF1YzhZnlvHoZWa3FZ6Q7aUHNCMe5ptJu 4UMUzMlBf4czn1ndC4B9lyilANTKKNBKY3MIDu0JtE8QAtu4vbZ6VfHSlSN1A4dI vVEGSTqOrgJQ87LpIY+aI6AEfVbORQ20StoQqzUKTVPYP0ipEjYWRcWT8QNleNOM 9fdbnIXd5OWjL1hq7tsrXq1AjFqLR0Ddyov4EXSHZuR2zPUc1sj8OwDCB9AUkgv4 VSAtsKAFIe5GMtDe0lG4/Qymly+CfUH7ynyGwwjtLjR6IEpN3bnP1YkuiRkFN1Hl eEBqVdZNduDZipgmNDGwM+qjkipYWlhzOo19CpjXbyr0VnQ3gBgKxWEBHm9es8EI Mtzhk/kwpQelAGgu6qkc+60fv3BfPbJp+GLtcaUtRWBH6K0hH/tF83ehiF1cRI1G GasbJmR7EQtopkUq4UiIVKsxXDxLs8RFDR5fBEfWLAoatjxsEMEIZOlKKfjkc7bU 5ytBmXkg48whQyqT2xRFegGSioKH7FRznkAlgWhkcnSSAwmfLUaAiDNev+3J2eQ6 5AiOh31d/seGss5FnQ87mcmqWEPfqBDNFl3KMDTXMcKg3zbl0MUNnFGkWDL34Yik D3Oo9GS8mfqCRfFycyW0 =t33c -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200321111038.Horde.rgAGgZxVa9iVtXMBf4CIY2q>