From owner-freebsd-security@freebsd.org Wed Oct 18 20:52:43 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 2B4F2E43BD0 for ; Wed, 18 Oct 2017 20:52:43 +0000 (UTC) (envelope-from walterp@gmail.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8CE169E48 for ; Wed, 18 Oct 2017 20:52:42 +0000 (UTC) (envelope-from walterp@gmail.com) Received: by mail-qk0-x235.google.com with SMTP id n5so7921720qke.11 for ; Wed, 18 Oct 2017 13:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=odsY3laA1eF6Imcl3msfjv4JqSW51O/BWw2sZd4D6X8=; b=uLknnk+VJ4oeiy/6PR1KbVR0XiQjxmTTSfTGIxWyQzB+06IoKn5+vhfeN94zv2ALLr +A23Bkam4ca1tCCAWFcvDq7/oKUmYizNv3vLl1TF631icgwVsCmYVKyaCc4P1joHrUqn tuJEBIkssnrJfMEsjRxjkDJfxG1MnGiPQYtKH1YNSTNUqQMuDCtWVE5SYpXNEaBSjXBr +xTHZR4t+HtoNuezPYHzdN4SBo8mvTVPL3upj2XxSUeP88/de+pJBXz2mJAOCmgUWgK+ ifWqVTBhzs3cjI1vXSG54VH+WrFALmEV+Gpw2kP+dMU87PBKHuiaKQnz54p6Ni3yx41r IxMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=odsY3laA1eF6Imcl3msfjv4JqSW51O/BWw2sZd4D6X8=; b=rUrbJ42sGOSBHH6OgCz1RDeaW1fml6wHYR3KY6y+beZI8AwvrrWZoCRjjgLqoqxa9y JbQ4V0m006M/wBPliMsZ8QvSIB09cLOa+V5r1YOkIQccNKrzctCa3AwMGmZfDYt/54K2 SdnvfZRXI3z5QCuR5kRMi1LnG9c3O4b7eL4qyX4/3pk79wYU4qL9rITiW2d11ssJWWKQ dwj4c4uDZ9vrqUMaH9IoYsBAog/SW4Ed6b4FbyY4QtHVo9WoJJsZRdE2DZjEMBf1HNIp O4fy46hUCKXFmc8U9d4ZgLLSGSaLoL8J4DfpU+Y+eXFKiuogzObk2p1JHzfnV5OKEOJl xqVA== X-Gm-Message-State: AMCzsaWwnladU4Duscwzysu9FxwChX+FTtIyhZ1mZoCR0wFQIc7z01Zp KwTvnGUkwpSWtvaynTXgbdrYf7Bx/6PmP8NdTXk= X-Google-Smtp-Source: ABhQp+R7TtKhwsGn/B55Kll41NXXkCXkT6bNZa0PokpNYSPebmbRUL9Bahud0IGbhOzfkqW0RrnoxtK/Lc9rNHWTJOE= X-Received: by 10.55.109.131 with SMTP id i125mr4103496qkc.219.1508359961746; Wed, 18 Oct 2017 13:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.181.165 with HTTP; Wed, 18 Oct 2017 13:52:41 -0700 (PDT) In-Reply-To: References: From: Walter Parker Date: Wed, 18 Oct 2017 13:52:41 -0700 Message-ID: Subject: Re: freebsd-security Digest, Vol 634, Issue 3 To: freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 20:52:43 -0000 > > > > Message: 3 > Date: Tue, 17 Oct 2017 21:00:11 -0700 > From: "Ronald F. Guilmette" > To: freebsd-security@freebsd.org > Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response > Message-ID: <32999.1508299211@segfault.tristatelogic.com> > > > 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? I have to ask, > because I honestly don't know. If not, is it easily possible to add > or attach some additional encryption layer to those? And if I did so, > would it even help any? (I'm guessing that it might, just on the basis > of what little I know about SSH. I don't even really know how SSH works. > The only think I do know is that it is possible to use it to both start > up and continue a secure connection, even in the presence of utterly > compromised data links. And I gather than this is also -the- fundamental > and inherent feature of TLS also.) > > Please note that I am asking only about what is -easily- possible. I > wish that I had time to learn in depth about all things crypto (starting > from my very low starting point) but I don't. And I'm just running a > little home network here, not a network for, say, a huge corporation > or for a sprawling factory floor. So I just doesn't make sense for me > to spend, say, 200 man hours to get something working. I just don't > have that kind of time to devote to this. > > Basically if there is an -eay- crypto-protected way of mounting volumes > and then accessing them, either for NFS or for SMB (or both) then I do > think I'd like to try that. > > >What you did is secure only the lowest layers and put no security on the > >higher ones, the security of the complete stack relying on the lowest > >layer security. > > Yea, I think that I sort of got that. > > >All sensitive operations should be done using secure channels. > >The most versatile secure channel is setting-up a custom VPN within your > >LAN... > > Frankly, I must sheepishly admit that have no idea how to even begin to > do that. Pointers to tutorials would be appreciated. > > Note also that whatever I do in this regard, I have to be able to entice > or coerce at least one of (a) OpenELEC/LibreELEC and/or (b) Windoze7 > to follow suit. > > >At last remains Internet access. There are two threats there: > > > >1) An attacker may intercept your connection. He will not be in measure > >to bypass HTTPS security though, so assertion such a "hacker can now > >steal your passwords and credit card numbers" as heard this morning in > >the news is bullshit as long as you ensure that your connection is > >indeed secure through HTTPS thanks to the little padlock. > > Well, as I mentioned earlier, my Amazon Fire TV box doesn't need to > access anything from my local file server, but it *does* somehow > (and mostly automagically) access protected content off the Internet, > via my local WiFi network. At the moment, I don't even know if > whatever credentials of mine that are stored in, and transmitted from > that box are at risk, and I have even less of an idea of how to > secure them if they are indeed at risk. > > >There are paid VPN services available on the Internet, some of them even > >proposing smartphone apps. They are commonly and effectively used on > >public WiFi network which are by definition untrusted, and would be an > >easy way to secure your Internet access through an untrusted WiFi > >without having to learn to setup a VPN server yourself. > > Right, but how do I entice the Fire TV box to use such a thing? That's > the enigma, I think... at least for me. > > >2) An attacker may use your Internet access for his own purposes. > > Yea, I've gathered at least that much. It is a worrying possibility, > but as I have pretty crappy (low) bandwidth, I think that if bad guys > show up in my neighborhood, they will easily find much better pickings > from some of my neighbors. So for the moment, I'm not going to worry > about this, but of course, I'm going keep my ear to the ground, and will > patch my router and my WiFi clients the minute patches or these things > are available. > > >Your WiFi access point firewall may offer the possibility to restrict > >outgoing connections to only the VPN server. This would effectively > >restrict Internet access to hosts and devices able to authenticate > >against the VPN server. > > It doesn't. :-( > > >I hope these few elements help you to see things a bit clearer and, > >maybe, give you some useful ideas. > > Yes, thanks. > > I feel sure that I am probably speaking for a few hundred million people, > all over the world, when I say that this whole WPA2 debacle is really > rather entirely annoying. But with helpful folks like you around, even > the dunderheads like me will probably manage to make it through this mess > without too much pain. > > Thanks for your thoughts. > > > Regards, > rfg > > SMB has supported authentication signing for a long time (more than a decade). That can be used for basic security. SMB3 supports encryption. To work with SMB3 encryption you will need at least Windows 8. The Samba project supports SMB3 and many of the security features in it, but not share level encryption. Password authentication works with signing and encryption. Until Samba supports the new share encryption in SMB3, you will need to use something like stunnel (or an encrypted VPN) to enable the privacy features that come with encryption. What that means is that the newest versions of Samba can talk to newer Windows boxes with the authentication pieces (the username/password exchange) done with encryption to make exploitation much harder. Encryption on NFS appears to be by using stunnel or SSH to encrypt the data (or using a VPN). Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis