From owner-freebsd-security@freebsd.org Wed Oct 18 22:49:06 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 4EC62E45EEF for ; Wed, 18 Oct 2017 22:49:06 +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 DAB3C6D2E0 for ; Wed, 18 Oct 2017 22:49:05 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074422-f87ff70000007b75-3c-59e7d9276f98 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (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 02.AB.31605.829D7E95; Wed, 18 Oct 2017 18:43:53 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v9IMhm92030346; Wed, 18 Oct 2017 18:43:49 -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 v9IMhiVP031774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Oct 2017 18:43:47 -0400 Date: Wed, 18 Oct 2017 17:43:44 -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: <20171018224344.GA96685@kduck.kaduk.org> References: <32999.1508299211@segfault.tristatelogic.com> <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT19W8+TzS4FGTmkXPpidsFi3zbzNb vLr8is2B2WPGp/ksHvc3NTJ7/Ly6lj2AOYrLJiU1J7MstUjfLoErY9oq7oJjIhXnj+xha2Bc KtDFyMkhIWAice14F2MXIxeHkMBiJonGxb+hnI2MEv3TVrBCOFeZJLZMWM8K0sIioCox4cVm dhCbTUBFoqH7MjOILSLgKPHz/VawGmaBCInVJyazgNjCApYSs5vawep5gdb9e7QIzBYSKJM4 vuURG0RcUOLkzCcsEL06Eju33gGKcwDZ0hLL/3FAhOUlmrfOBlvFKeAucbNrKli5qICyxLx9 q9gmMArOQjJpFpJJsxAmzUIyaQEjyypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdU73czBK91JTS TYzgQHdR2sE48Z/XIUYBDkYlHt4F055HCrEmlhVX5h5ilORgUhLl1T3wLFKILyk/pTIjsTgj vqg0J7X4EKMEB7OSCK/2VqBy3pTEyqrUonyYlDQHi5I477agXZFCAumJJanZqakFqUUwWRkO DiUJ3s3XgRoFi1LTUyvSMnNKENJMHJwgw3mAhm+9BjK8uCAxtzgzHSJ/ilFRSpx3LUizAEgi ozQPrheUiCSy99e8YhQHekWYdz9IFQ8wicF1vwIazAQ0eJ3TE5DBJYkIKakGRin9C+k5Wfb5 U5+2VawP236i03b6YunfaRPmiHlsbp645tmajfL1oTLrI+681pt8lueq0uOLizVlA1nV1IUX vmHhT3eQj465oa0ZXhTBIi8jHRd/56POigMCbtuO/Zu4U/jgHxaFU0klx/p0Dm1c/bLP5u1c 1tKXxkezvjJ4nzc0jZhs7T27SomlOCPRUIu5qDgRAPnS9ucfAwAA 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: Wed, 18 Oct 2017 22:49:06 -0000 I fear I must wade into this thread, despite it being thick with FUD. On Wed, Oct 18, 2017 at 07:27:42PM +0200, WhiteWinterWolf (Simon) wrote: > Hi Ronald, > > Le 18/10/2017 à 06:00, Ronald F. Guilmette a écrit : > > > > In message <49252eda-3d48-f7bc-95e7-db716db4ed91@whitewinterwolf.com>, > > "WhiteWinterWolf (Simon)" wrote: > > > >> Ideally, you would use a specific protection for each of these layers, > >> so that an vulnerability affecting one layer would be compensated by > >> other layers. > > > > A good point. > > > > Right about now, I wish that I knew one hell of a lot more about both > > NFS and SMB than I do... and also SSH and TLS. I suspect that the > > file sharing protocols I am most concerned about (NFS & SMB) could > > perhaps be run in a manner such that both initial volume mounts and > > also data blocks (to & from) the share volumes would be additionally > > encrypted, so that I could be running everything securely, even if > > some attacker managed to do maximally evil things to my WiFi/WPA2 > > network. > > > > Do NFS and/or SMB have their own built-in encryption? > > No, not really. > > 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. > 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.) 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. -Ben