Hi Benjamin,
Le 19/10/2017 à 00:43, Benjamin Kaduk a écrit :
NFS has no built-in encryption, it may be possible to tunnel it but this
is out-of-scope here (using a VPN and tunnel everything would be easier
than nitpicking and tunnel only the NFS data flow).
This statement is either false or highly misleading. NFS (both v3 and v4)
is an RPC protocol, and RPCSEC_GSS exists and can provide per-message
confidentiality protection. It may be true that Kerberos is basically
the only GSS-API mechanism implemented for RPCSEC_GSS, and the necessary
Kerberos setup is far more painful to set up than it needs to be,
but all modern NFS implementations support it.
The support RPCSEC_GSS has been added in NFSv4, it was not available in
NFSv3.
Try to find any mention of RPCSEC_GSS in NFSv3 RFC:
https://tools.ietf.org/html/rfc1813
NFSv4 RFC on the other side documents the addition of this feature in
the protocol:
https://tools.ietf.org/html/rfc3010
Don't confuse RPCSEC_GSS with AUTH_KERBEROS and AUTH_DES, which weren't
widely supported and protect only the authentication phase: in-transit
data was still left unprotected (and this is what we are talking about
with this KRACK issue).
The NFSv3 protocol itself had no authentication whatsoever, full trust
was given to the client system, making it a blatant security hole in
most infrastructures. That's precisely one of the reasons why NFSv4 was
needed.
I agree with you however that with a properly setup NFSv4 + Kerberos
infrastructure you can get something secure. Granted.
To go back in the realm of both FreeBSD and NAS appliances, it seems
that FreeNAS supports NFSv4 "krb5p (authentication and privacy)":
http://doc.freenas.org/9.3/freenas_sharing.html
But NFSv3 is still the default even in the last version:
http://doc.freenas.org/11/services.html
I don't know if they managed to make it easy to use or if an external
Kerberos server is required, but in the former case that would indeed be
a great choice for end-users (but, given it is not the default and seems
to be among the "advanced" options, I fear that setting-up Kerberos is
left as an exercise for the user).
SMB has no widely compatible encryption:
- Microsoft has built its own, proprietary encryption available and
compatible only with the latest Windows versions.
- Open source implementations rely on TLS, natively supported by some
client but requiring (AFAIK) `stunnel` server-side.
I am not a SMB/CIFS expert, but (e.g.)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670508 seems to
indicate that "proprietary" is false, and does not give much support
to the claim that it requires TLS. (I believe in-kernel TLS support
had not landed by June, when Xenial was getting its fix.)
Sorry, but Microsoft SMB extensions *are* proprietary extensions.
I encourage your to read the following page which explains the
impressive work made by Samba people:
https://www.samba.org/samba/docs/myths_about_samba.html
And in particular the description of their "French cafe" technique:
http://samba.org/ftp/tridge/misc/french_cafe.txt
The Unix and Free/Libre software world owe them both for the SMB support
on Unix made and maintained thanks for very hard and complex work, and
as one of the most active defenders of the laws enforcing compatibility
as an exception in vendor's EULA forbidding reverse engineering so other
projects can legally build Free/Libre software compatible with
closed-source proprietary software.
Reducing Samba people work to simply coding some open standard is nearly
disrespectful.
Discussions have been made on documenting Microsoft's extensions as IETF
standards, but Microsoft closed the subject years ago. In your link
there is indeed mention of "upstream" development, but your link points
toward an Ubuntu bug ticket and the "upstream" team is the Samba
development team, not Microsoft.
Due to security concern affecting in-transit data communicated in clear
text, in 2008 Samba people developed an open extension allowing to
provide good encryption:
https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#idp62151568
As they state: "Currently this is only supported by Samba 3.2 smbclient,
and hopefully soon Linux CIFSFS and MacOS/X clients. Windows clients do
not support this feature."
In 2012 Microsoft came with its own proprietary solution to achieve
similar goal:
https://blogs.technet.microsoft.com/filecab/2012/05/03/smb-3-security-enhancements-in-windows-server-2012/
Samba people now work to understand and reimplement Microsoft's own
creation, but work is far from being complete ("in progress"):
https://wiki.samba.org/index.php/SMB3_kernel_status#Security_Features
An update of Samba documentation is pending which better explains the
difference between Samba and Microsoft SMB encryption features, but this
update is currently pending until, I suppose, that Microsoft SMB3
encryption support in Samba is complete:
https://git.samba.org/?p=samba.git;a=commitdiff;h=51ae17b0703eaa481d602ffc7d8231a629fcb5fd
Regarding TLS and SMB, I'm indeed sorry as Samba's implementation of SMB
encryption (which is unrelated to the link you provided) indeed does not
rely on it. I guess I mixed this with some documentation on how, thanks
to `stunnel`, it is still possible to have an SMB encryption working for
both Unix and Windows hosts:
https://wiki.netbsd.org/tutorials/how_to_secure_samba_with_stunnel/
But the point in my previous answer was less about TLS than explaining
that, as for now, there is no easy and widely compatible way to enable
encryption for SMB, and therefore propose SFTP as the easiest, safest
and most compatible alternative for low-tech end-users would the
underlying network not be trustable.
I am aware that this is a FreeBSD list and the offerings on FreeBSD
for SMB are somewhat limited, but you did not scope your statement
to FreeBSD and so neither do I.
And I'm happy about that. I like diversity, dislike blinkers and love to
learn new things.
Ronald brought on the table Linux (OpenElec), proprietary platforms
(Amazon TV, Windows 7), and I think that's all fine because FreeBSD,
"the power to serve", should also be able to serve to non-FreeBSD
systems in a secure way, even when a vulnerability plagues the data-link
network layer.
> I fear I must wade into this thread, despite it being thick with FUD.
We are on a technical mailing list targeting grown-up people, please
remain focused on technical points and refrain from troll-like bold
statements seeking pure confrontation and not making discussion progress
in any way. Thank you for your comprehension.
Thank you for your answer (except maybe the FUD thing, but that's
already forgotten) as it was the occasion for me to check Samba work
current status (it takes years but they are progressing and
compatibility with current Windows infrastructure is reaching the
horizon, yes!) and remind to myself about the FreeNAS project which I
still have to try myself.
Regards,
Simon.
--
WhiteWinterWolf
https://www.whitewinterwolf.com
_______________________________________________
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
