TLS certificates for NFS-over-TLS floating client
Alexander Leidinger
Alexander at leidinger.net
Sat Mar 21 10:11:17 UTC 2020
Quoting John-Mark Gurney <jmg at funkthat.com> (from Fri, 20 Mar 2020
12:29:23 -0700):
>> 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.
>
> 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
trusted CA".
- Then you can require that the CN matches the hostname and the
reverse lookup matches.
- Or (similar to browsers today) you can ignore the CN and require
that the hostnames of the client matches one of the subject
alternative name (SAN) entries (requires reverse DNS lookup to work
and match).
At this point you prevent simple cert theft as additionally you
require that someone also has to be able to modify the DNS (or NFS
server hosts file, but then he probably can already add an additional
cert to the truststore of nfsd).
Additional protection is possible by also adding the IP to the SAN. I
haven't put an effort into evaluating if either IP or DNS is enough
from a security point of view, or if it makes a difference if the "IP
in SAN" case has an additional benefit in terms of security if it is
in addition to the reverse DNS requirement.
Yes this makes it more inconvenient to change the IP of a host, but if
all the policy possibilities are up to the admin to configure (e.g.
"cert is signed by trusted CA" as a default, and all the other
possibilities as an option for nfsd), it is up to the admin and the
security requirement.
In general, all the possibilities are can either be distinct, or
accumulative. There is also the possibility that you do not go with
any CA but configure X self-signed certs for X clients as being
trusted and the cert of the client needs to be an exact match with one
of the X self-signed certs in the truststore.
Whatever the policy(/ies) is/are in nfsd, I suggest to make it
explicit in the docs what is required and what is checked for each
policy. And even if it may be obvious for you Rick, please also print
out why a client was rejected. Unfortunately I've seen a lot of cases
where the error is a simple/frustrating "certificate rejected", but no
info which part of the certificate check failed.
Bye,
Alexander.
--
http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild at FreeBSD.org : PGP 0x8F31830F9F2772BF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20200321/baf583b3/attachment.sig>
More information about the freebsd-current
mailing list