Date: Wed, 18 Oct 2017 19:27:42 +0200 From: "WhiteWinterWolf (Simon)" <freebsd.lists@whitewinterwolf.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com>, freebsd-security@freebsd.org Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response Message-ID: <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> In-Reply-To: <32999.1508299211@segfault.tristatelogic.com> References: <32999.1508299211@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ronald, Le 18/10/2017 à 06:00, Ronald F. Guilmette a écrit : > > In message <49252eda-3d48-f7bc-95e7-db716db4ed91@whitewinterwolf.com>, > "WhiteWinterWolf (Simon)" <freebsd.lists@whitewinterwolf.com> 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). 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. > Please note that I am asking only about what is -easily- possible. Securing in-transit NFS and SMB communication is not part of this. > I don't even really know how SSH works. I don't know what kind of device / server you are using to store and share your files. If your files repository proposes a web interface, it may be as simple as going in the SSH/SFTP tab, check the "enable" box, and access your files through an SFTP-capabe client such as FileZilla (AFAIK, FreeNAS, since we are on a FreeBSD mailing list, supports SFTP shares natively). For a basic usage you don't need to dig into the details of how the SSH protocol works and the impressive number of features it offers. Simply know that one of its features is SFTP, standing for Secure File Transfer Protocol, so when you need a protocol to securely transfer files then SFTP can do it. > 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.) You're right. > 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. I understand, that's why I mention SFTP which is usually a widely supported, painless and secure way to transfer files over a potentially untrusted network. > Basically if there is an -easy- 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. This is becoming more-and-more a concern. NFS, but that's my opinion, is a rather historical protocol so I don't think there will be any major evolution there. As stated above, the SMB protocol is evolving to better protect in-transit data, but there are business interests here at play which prevents, for now, the users from having any simple and widely-compatible solution. As a reminder SMB is an undocumented proprietary protocol from Microsoft. Open-source implementations have been done by individuals reverse-engineering Microsoft's own work. Having Microsoft and the open-source community stretching in different directions pursuing different goals is not the best situation for a quick and sane evolution of the protocol. >> 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. > Hence the following of my sentence: "but there are other alternative". "Versatile" and "easy-to-use" are often very different things. > 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. For OpenElec, this may become an issue if you are using it to access sensitive files. But usually this is not the case. For "Windoze7", according to this post: https://security.stackexchange.com/q/171542/32746#171546 It seems that updating the client might be enough to thwart most of the attack. Windows 7 is still supported for security updates, so I don't doubt that Microsoft will release a fix for this system if this is not already done. Other than that, there are various solutions to protect browsing data: - You can use a paid VPN service. Again, you don't need to learn how to setup a VPN: all the work is done by the VPN provider services and they provide straightforward assistants to automatically configure your system. - You can use EFF's HTTPS Everywhere add-on and configure it to access only HTTPS websites, but this will most likely block a lot of websites. - Some browsers include proxy capability natively to protect your data from untrusted network, such as the Opera with its "VPN" feature and the TOR browser. The advantage is that such solution would work everywhere, so you can take your Windows 7 laptop at a cyber-cafe or access an airport WiFi and still benefit from the level of safety in your browsing than at your home. > 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. Amazon seems to be currently working on this: https://www.aivanet.com/2017/10/amazon-says-a-patch-for-wpa2-exploit-krack-is-in-the-works/ As always, with proprietary devices and software you are not in control on what the device is doing, don't even have any reliable understanding of it and rely on the upstream vendor for any change. >> 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, Not so worrying actually. Now that I've better checked this new attack, it doesn't sound as devastating as the previously mentioned WEP issues, at least not in its current stage (and WPA2 being better engineered than WEP, chances are that the story will not repeat). An attacker is able to join the WiFi network only if you use Wireless Gigabit (WiGig) which is quite uncommon. Common WiFi access (WPA2 CCMP, WPA TKIP) only allow an attacker to intercept and manipulate users data, not to join the network or obtain the network's password. > 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. Patches for computer-based devices should come very soon (if not already available). Depending on the providers and involved parties, it may take more time for mobile devices and router firmwares (the worst case being carrier-provided previous-generation Android smartphones: I wouldn't be surprised that a large portion of them will never be fixed). > 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. Thank you for your kind words. At least, the mediatisation of this flaw puts pressure on software and devices providers to fix this flaw and not ignore it. Maybe, the most useful thing that this "hundred million people" can do is keep an eye on these providers and push to get it fixed. Manufacturers often neglect security for end-users devices (it costs money while not being a selling-point). Such "debacle" may be have its advantages from time-to-time to make people think on how they use their devices. As a security engineer, I obviously campaign for safer devices and tools which provide security without even the user noticing it. But there are other interests in the field, so it may not be completely bad that people are reminded that technology may not be blindly relied upon. Regards, Simon. -- WhiteWinterWolf https://www.whitewinterwolf.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53010303-bd65-26a1-64b9-6eefa325ca46>