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
mistakes.
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
secret model.
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.
Best,
Russell
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
+0000:
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
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
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.
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? 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?
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?
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
server.
As suggested by others, having a site local CA created by the NFS
admin. seemed
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
captured and...
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?)
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
from
the phone
company, I doubt this would work for me (which I why I say I don't
know how
to do this). I suspect there are ways and it would be nice if you
could document
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
5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current To
unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
