WhiteWinterWolf (Simon)
2017-Oct-19 13:07 UTC
WPA2 bugz - One Man's Quick & Dirty Response
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
On Thu, Oct 19, 2017 at 03:07:57PM +0200, WhiteWinterWolf (Simon) wrote:> 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/rfc3010Right, NFSv4 built it in from the start whereas it had to be hacked onto NFSv3> 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).It seems that RFC 2623 aims to clarify their differences. (It only covers the single-DES kerberos enctypes, which are not particularly secure anymore; see RFC 6649.)> 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.Indeed, the design goals were from a different era (and before my time).> 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).Alas, it is left that way all too often. Since we're on the topic, I'll link http://web.mit.edu/kerberos/krb5-latest/doc/admin/install.html and note that that is quite different from the Heimdal included in the FreeBSD base system.> > >> 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.txtFair enough, and thank you for the links. I don't do much with SMB, myself, so had to try to search while writing my previous mail. -Ben