From owner-freebsd-security@freebsd.org Fri Oct 20 02:14:44 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F307E4CE5B for ; Fri, 20 Oct 2017 02:14:44 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B996C636C0 for ; Fri, 20 Oct 2017 02:14:43 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074422-5c1ff70000004cba-d7-59e95c08ce1b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id F0.18.19642.90C59E95; Thu, 19 Oct 2017 22:14:33 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9K2EVeW016249; Thu, 19 Oct 2017 22:14:31 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9K2ER61018797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2017 22:14:29 -0400 Date: Thu, 19 Oct 2017 21:14:27 -0500 From: Benjamin Kaduk To: "WhiteWinterWolf (Simon)" Cc: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response Message-ID: <20171020021427.GH96685@kduck.kaduk.org> References: <32999.1508299211@segfault.tristatelogic.com> <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> <20171018224344.GA96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IR4hTV1uWMeRlp0LRNw6Jn0xM2i5b5t5kt Xl1+xebA7DHj03wWj/ubGpk9fl5dyx7AHMVlk5Kak1mWWqRvl8CVsa9FquC3TMWyWf/ZGxhn iXcxcnJICJhIrLo9ia2LkYtDSGAxk8TJ+x+ZIZyNjBK7/19kB6kSErjKJLG+N62LkYODRUBV 4vxnI5Awm4CKREP3ZWYQW0TAUeLn+62sIDazQITE6hOTWUBsYQFLidlN7WBjeIGWTZv6kR1i /j1Gia/tNxkhEoISJ2c+YYFo1pHYufUOG8guZgFpieX/OCDC8hLNW2eD7eIUcJd4P+UiG4gt KqAsMW/fKrYJjIKzkEyahWTSLIRJs5BMWsDIsopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXVC83 s0QvNaV0EyMozNldlHYwTvzndYhRgINRiYd3w4UXkUKsiWXFlbmHGCU5mJREeTdwvIwU4kvK T6nMSCzOiC8qzUktPsQowcGsJML7Igwox5uSWFmVWpQPk5LmYFES590WtCtSSCA9sSQ1OzW1 ILUIJivDwaEkwZsbDdQoWJSanlqRlplTgpBm4uAEGc4DNNwTpIa3uCAxtzgzHSJ/ilFRSpzX IQooIQCSyCjNg+sFpSGJ7P01rxjFgV4R5q0EaecBpjC47ldAg5mABrPbvwAZXJKIkJJqYJyn FlMns3uaVfdilV9+5ja6J6e+d1ETjup23O73Pb9S+/b+6zW9eoJnf3k42ojuYWZ04el1/Wl1 4HHtY5fXOx7E+a1e5D3P51eisv5CEf26S0t27KyztDExSshcz71EROeVr1ed+rVfJQru9oVl FXqvjGpaV9U+3h4f8f5TxsO/09XMD+9KVWIpzkg01GIuKk4EANywKwAeAwAA X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 02:14:44 -0000 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