TLS certificates for NFS-over-TLS floating client
Russell L. Carter
rcarter at pinyon.org
Fri Mar 20 01:44:45 UTC 2020
So ok, it's good to code to RFCs. OTOH, state actors are a thing now.
Alice & Bob's protocols need to be perfect. State actors watch for
Here I commit heresy, by A) top posting, and B) by just saying, why
not make it easy, first, to tunnel NFSv4 sessions through
e.g. net/wireguard or sysutils/spiped? NFS is point to point.
Security infrastructure that actually works understands the shared
Not going to argue further. I'm a grateful letsencrypt consumer.
Rick is a hero for his NFS work. I use his code every day.
On 2020-03-19 16:41, Rick Macklem wrote:
> John-Mark Gurney wrote:
>> Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15
>>> I am slowly trying to understand TLS certificates and am trying
>>> 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
>> Are you looking at implementing draft-cel-nfsv4-rpc-tls?
> Yes. The 2 week out of date (I can only do commits once in a while
these days) can
> be found in FreeBSD's subversion under base/projects/nfs-over-tls.
>>> This syntax isn't implemented yet, but the thinking is that
>>> 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.
>>> 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
>>> server can trust enough to allow the mount? 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
>>> Alternately, it could be a newly defined extension for X509v3, I
>>> 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
>>> Does this sound reasonable?
>> Without a problem statement or what you're trying to accomplish,
>> it's hard to say if it is.
> The problem I was/am trying to solve was a way for NFS clients
> without a fixed IP/DNS name could have a certificate to allow access
> to the NFS
> As suggested by others, having a site local CA created by the NFS
> 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. --> I've thought of
> having the client keep the certificate encrypted
in a file and
> require the "user" of the client type in a passphrase to
unencrypt the certificate
> so that it can be used by the daemon in the client that
handles the client side
> of the TLS handshake, but I have not implemented this. --> This would
> at least subvert the simple case of the
certificate file being copied
> to a different client and being used to mount the NFS
server, but if the
> client is compromised, then the passphrase could be
>>> Also, even if the NFS client/server have fixed IP addresses with
>>> DNS names, it isn't obvious to me how signed certificates can be
>>> for them? (Lets Encrypt expects the Acme protocol to work and
>>> that seems to be web site/http specific?)
>> There is DNS challenges that can be used. I use them to obtain
>> certs for SMTP and SIP servers... using nsupdate, this is
>> relatively easy to automate pushing the challenges to a DNS server,
>> and I now use DNS challenges for everything, including https.
> Since my internet connection is a single dynamically assigned IP
> company, I doubt this would work for me (which I why I say I don't
> to do this). I suspect there are ways and it would be nice if you
> this, so I can put it in a howto document. - An actual example using
> the nsupdate command would be nice. Thanks, rick
>> Thanks for any help with this, rick
> Let me know if you'd like to hop on a call about this.
> -- John-Mark Gurney Voice: +1 415 225
> "All that I will do, has been done, All that I have, has not."
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current To
> unsubscribe, send any mail to
> "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current