From owner-freebsd-current@freebsd.org Sat Mar 21 10:11:17 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4B50C25CAE5 for ; Sat, 21 Mar 2020 10:11:17 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48kxHm1J0wz4dfy for ; Sat, 21 Mar 2020 10:11:15 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5B165828.dip0.t-ipconnect.de [91.22.88.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 400C9247D; Sat, 21 Mar 2020 11:11:12 +0100 (CET) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id D086411F2B; Sat, 21 Mar 2020 11:10:39 +0100 (CET) Date: Sat, 21 Mar 2020 11:10:38 +0100 Message-ID: <20200321111038.Horde.rgAGgZxVa9iVtXMBf4CIY2q@webmail.leidinger.net> From: Alexander Leidinger To: John-Mark Gurney Cc: Rick Macklem , freebsd-current@freebsd.org Subject: Re: TLS certificates for NFS-over-TLS floating client References: <20200319191605.GJ4213@funkthat.com> <20200320192923.GK4213@funkthat.com> In-Reply-To: <20200320192923.GK4213@funkthat.com> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_M8_tNGFnqA8wLMuMfTFM8H6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 48kxHm1J0wz4dfy X-Spamd-Bar: -------- X-Spamd-Result: default: False [-8.81 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; URIBL_BLOCKED(0.00)[leidinger.net.multi.uribl.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; IP_SCORE(-3.72)[ip: (-9.77), ipnet: 89.238.64.0/18(-4.88), asn: 34240(-3.92), country: DE(-0.02)]; NEURAL_HAM_MEDIUM(-0.99)[-0.995,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; SIGNED_PGP(-2.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[40.88.22.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 10:11:17 -0000 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 (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--