Date: Tue, 3 Mar 2020 19:22:34 -0800 From: Benjamin Kaduk <kaduk@mit.edu> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "freebsd-current@FreeBSD.org" <freebsd-current@freebsd.org> Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <20200304032234.GY98042@kduck.mit.edu> In-Reply-To: <YTBPR01MB3374EFF14948CB8FEA1B5CCDDDE50@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> References: <YTBPR01MB3374EFF14948CB8FEA1B5CCDDDE50@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 04, 2020 at 03:15:48AM +0000, Rick Macklem wrote: > Hi, > > I am slowly trying to understand TLS certificates and am trying to figure > out how to do the following: > -> For an /etc/exports file with... > /home -tls -network 192.168.1.0 -mask 255.255.255.0 > /home -tlscert > > This syntax isn't implemented yet, but the thinking is that clients on the > 192.168.1 subnet would use TLS, but would not require a certificate. > For access from anywhere else, the client(s) would be required to have a > certificate. My gut reaction: that doesn't sound like a good idea. Trusting the local network to be secure is pretty risky, in general. > A typical client mounting from outside of the subnet might be my laptop, > which is using wifi and has no fixed IP/DNS name. > --> How do you create a certificate that the laptop can use, which the NFS > server can trust enough to allow the mount? You can give your laptop a certificate for an arbitrary name, provided that the NFS server knows to "validate" that name in an appropriate fashion. (I don't remember what draft-ietf-nfsv4-rpc-tls says about this validation.) > My thinking is that a "secret" value can be put in the certificate that the NFS > server can check for. > The simplest way would be a fairly long list of random characters in the > organizationName and/or organizationUnitName field(s) of the subject name. > Alternately, it could be a newly defined extension for X509v3, I think? It would be better to just make a site-local CA and trust everything it issues (which, admittedly, is not the greatest option itself.) > Now, I'm not sure, but I don't think this certificate can be created via > a trust authority such that it would "verify". However, the server can > look for the "secret" in the certificate and allow the mount based on that. > > Does this sound reasonable? I'm not sure what goal you're trying to achieve by this "security through obscurity". > Also, even if the NFS client/server have fixed IP addresses with well known > DNS names, it isn't obvious to me how signed certificates can be acquired > for them? > (Lets Encrypt expects the Acme protocol to work and that seems to be > web site/http specific?) RFC 8738 specifies the ACME protocol for validating IP addresses. -Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200304032234.GY98042>