WPA2 bugz - One Man's Quick & Dirty Response

[Benjamin Kaduk]

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/rfc3010

Right, 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.txt

Fair 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