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
This message is in MIME format and has been PGP signed. --=_M8_tNGFnqA8wLMuMfTFM8H6 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting John-Mark Gurney <jmg@funkthat.com> (from Fri, 20 Mar 2020=20=20 12:29:23=20-0700): >> to be the best solution. The server can verify that the certificate=20= =20 >>=20was issued by >> the local CA. Unfortunately, if the client is compromised and the=20=20 >>=20certificate 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=20=20 trusted=20CA". - Then you can require that the CN matches the hostname and the=20=20 reverse=20lookup matches. - Or (similar to browsers today) you can ignore the CN and require=20=20 that=20the hostnames of the client matches one of the subject=20=20 alternative=20name (SAN) entries (requires reverse DNS lookup to work=20=20 and=20match). At this point you prevent simple cert theft as additionally you=20=20 require=20that someone also has to be able to modify the DNS (or NFS=20=20 server=20hosts file, but then he probably can already add an additional=20= =20 cert=20to the truststore of nfsd). Additional protection is possible by also adding the IP to the SAN. I=20=20 haven't=20put an effort into evaluating if either IP or DNS is enough=20=20 from=20a security point of view, or if it makes a difference if the "IP=20= =20 in=20SAN" case has an additional benefit in terms of security if it is=20= =20 in=20addition to the reverse DNS requirement. Yes this makes it more inconvenient to change the IP of a host, but if=20= =20 all=20the policy possibilities are up to the admin to configure (e.g.=20=20 "cert=20is signed by trusted CA" as a default, and all the other=20=20 possibilities=20as an option for nfsd), it is up to the admin and the=20=20 security=20requirement. In general, all the possibilities are can either be distinct, or=20=20 accumulative.=20There is also the possibility that you do not go with=20=20 any=20CA but configure X self-signed certs for X clients as being=20=20 trusted=20and the cert of the client needs to be an exact match with one=20= =20 of=20the X self-signed certs in the truststore. Whatever the policy(/ies) is/are in nfsd, I suggest to make it=20=20 explicit=20in the docs what is required and what is checked for each=20=20 policy.=20And even if it may be obvious for you Rick, please also print=20= =20 out=20why a client was rejected. Unfortunately I've seen a lot of cases=20= =20 where=20the error is a simple/frustrating "certificate rejected", but no=20= =20 info=20which part of the certificate check failed. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_M8_tNGFnqA8wLMuMfTFM8H6 Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----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----- --=_M8_tNGFnqA8wLMuMfTFM8H6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200321111038.Horde.rgAGgZxVa9iVtXMBf4CIY2q>