Date: Thu, 5 Mar 2020 22:55:10 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Benjamin Kaduk <kaduk@mit.edu> Cc: "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <YTBPR01MB337414C4160CAD932464F4A2DDE20@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20200304032234.GY98042@kduck.mit.edu> References: <YTBPR01MB3374EFF14948CB8FEA1B5CCDDDE50@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM>, <20200304032234.GY98042@kduck.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin Kaduk wrote:=0A= >On Wed, Mar 04, 2020 at 03:15:48AM +0000, Rick Macklem wrote:=0A= >> Hi,=0A= >>=0A= >> I am slowly trying to understand TLS certificates and am trying to figur= e=0A= >> out how to do the following:=0A= >> -> For an /etc/exports file with...=0A= >> /home -tls -network 192.168.1.0 -mask 255.255.255.0=0A= >> /home -tlscert=0A= >>=0A= >> This syntax isn't implemented yet, but the thinking is that clients on t= he=0A= >> 192.168.1 subnet would use TLS, but would not require a certificate.=0A= >> For access from anywhere else, the client(s) would be required to have a= =0A= >> certificate.=0A= >=0A= >My gut reaction: that doesn't sound like a good idea.=0A= Yep, I thought that the stuff in the certificate was encrypted in a way tha= t the=0A= client couldn't see it. I now see that isn't the case.=0A= =0A= >Trusting the local network to be secure is pretty risky, in general.=0A= Well, for my personal case, the subnet has a few machines plugged into it= =0A= around my desk and wifi isn't enabled on the modem/NAT gateway, so=0A= I'm fairly confident the local machines are ok.=0A= To be honest, I don't need encryption on the wire, but since the phone=0A= company uses Huawei technology, I could see some wanting the data=0A= encrypted on the wire, if the data were sensitive.=0A= This case is meant to be easy to do, since the clients don't have to have= =0A= certificates.=0A= =0A= I am trying to provide whatever people might need/want when I implement=0A= this. The rest is obviously up to them.=0A= =0A= >> A typical client mounting from outside of the subnet might be my laptop,= =0A= >> which is using wifi and has no fixed IP/DNS name.=0A= >> --> How do you create a certificate that the laptop can use, which the N= FS=0A= >> server can trust enough to allow the mount?=0A= >=0A= >You can give your laptop a certificate for an arbitrary name, provided tha= t=0A= >the NFS server knows to "validate" that name in an appropriate fashion. (= I=0A= >don't remember what draft-ietf-nfsv4-rpc-tls says about this validation.)= =0A= As you note below, creating a site local CA is probably appropriate and the= =0A= server should be able to check that the certificates were signed by this.= =0A= (I haven't quite figured out how to do this yet. I think I've created the C= A=0A= and used to sign a client certificate, but haven't yet gotten the server da= emon=0A= to verify it. (Playing with SSL_set_verify_locations() to try to get it to = work.;-)=0A= =0A= >> My thinking is that a "secret" value can be put in the certificate that = the NFS=0A= >> server can check for.=0A= >> The simplest way would be a fairly long list of random characters in the= =0A= >> organizationName and/or organizationUnitName field(s) of the subject nam= e.=0A= >> Alternately, it could be a newly defined extension for X509v3, I think?= =0A= >=0A= >It would be better to just make a site-local CA and trust everything it=0A= >issues (which, admittedly, is not the greatest option itself.)=0A= I had thought this would be too much work, but it seems fairly straightforw= ard,=0A= so this is what I am now working on.=0A= =0A= >> Now, I'm not sure, but I don't think this certificate can be created via= =0A= >> a trust authority such that it would "verify". However, the server can= =0A= >> look for the "secret" in the certificate and allow the mount based on th= at.=0A= >>=0A= >> Does this sound reasonable?=0A= >=0A= >I'm not sure what goal you're trying to achieve by this "security through= =0A= >obscurity".=0A= Yes. I now see it is the CA stuff that can stay secret.=0A= =0A= >> Also, even if the NFS client/server have fixed IP addresses with well kn= own=0A= >> DNS names, it isn't obvious to me how signed certificates can be acquire= d=0A= >> for them?=0A= >> (Lets Encrypt expects the Acme protocol to work and that seems to be=0A= >> web site/http specific?)=0A= >=0A= >RFC 8738 specifies the ACME protocol for validating IP addresses.=0A= I had looked at an older RFC, where it seemed to be web site specific.=0A= Since none of my stuff has fixed well known DNS names, I'm not going to=0A= worry about using an established CA for now.=0A= =0A= Thanks to everyone for their comments.=0A= I may respond to some of the other posts, but I'm figuring things out for n= ow.=0A= =0A= rick=0A= =0A= -Ben=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB337414C4160CAD932464F4A2DDE20>