freebsd security - Oct 2017 - WPA2 bugz - One Man's Quick & Dirty Response

Hi Ronald,

I have yet to investigate this WPA2 thing on my side, too much 
contradictory informations depending on the sources yet.

Let me however add my two cents regarding your issue:

A network can be divided in several logical layers: the data link layer 
(here WiFi), the networking layer (here TCP/IP), and the application 
with the data it manipulates, both in transit and at rest.

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.

But this "ideal solution" is not always feasible.

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.
This is usually weak and prone to be vulnerable (if it wasn't due to 
this WPA2 weakness, it would be something else).

There are however techniques allowing to secure higher layers without 
having to trust the lower ones.
That's how, for instance, HTTPS work for online payment: neither you nor 
the bank or merchant trusts the Internet network, but all sensitive 
operations are done within a secure tunnel created between you and the 
remote party and isolating you form any threat affecting networks in 
between.

This WPA2 crisis strongly reminds me WEP (even-though I don't know yet 
if it is really as scary: again different source gives completely 
different information).
But nevertheless at that time it was simply assumed that the Wi-Fi was 
just to be considered as an untrusted network, the same way as you 
(should) consider Internet.

A sane approach which was usually recommended was as follow:

1)
Sensitive accesses must be properly secured. As you cannot trust lower 
layers, use something like a VPN, which is able to authenticate both the 
source and destination hosts and create a secure tunnel between them.

At the time of the WEP issue, there was a movement to completely drop 
any kind of WiFi "security" and use plain, open WiFi instead but rely
on
VPN to authenticate the hosts and provide appropriate access and security.
This was maybe an extreme position, but still this shows the idea and 
remains secure indeed, as long as all your hosts support VPN of course.

2)
Non-sensitive accesses *may* use lower security if needed.
In particular, I don't think that your Amazon TV supports any kind of 
VPN tunneling, but also I don't know if it requires write access to your 
network share or if it uses it only to read non-sensitive media files.

A common scenario is to allow read-only access limited to non-sensitive 
documents over the untrusted WiFi network. Yes, an attacker can take 
over your network and copy your movies and musics, but is this really 
problem for you?
IT security is always a question of trade-offs depending on your 
particular situation, but for the "few zillions" you mentioned this is
usually not a problem (and actually the attacker will most likely not 
even care of such files).

All sensitive operations should be done using secure channels.
The most versatile secure channel is setting-up a custom VPN within your 
LAN, but there are other alternatives. For instance, to update the 
content of your shared directories, you can use SFTP instead (the SSH 
file transfer protocol) instead of a writable share: this is very easy 
to setup (FileZilla is an easy to use and well-known SFTP client) and 
the whole communication will be secured by SSH.

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.
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.

2) An attacker may use your Internet access for his own purposes.
At the peak of the WEP crisis, maps of location of weak WEP Internet 
access points were shared (for a fee, I guess, everything is a matter of 
business) on shady forums (typically pedo-pornographic forums) so their 
users can take advantage of such unsecured networks to access illegal 
content anonymously.
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. Not the ideal solution in case of a public VPN 
server (where everyone can subscribe), but enough to deter such low-tech 
attackers who just seek for ready-made available Internet accesses.

So, to summarize:

- Unsecure shares must be read-only and offer access to only 
non-sensitive files.
- Write accesses and access to sensitive files must be done through 
secure channels authenticating both the server and the client. SFTP is a 
common solution, with FileZilla a widely used client.
- If an Internet access is needed over the WiFi, public VPN services 
offer ready-to-use solutions.
- Restricting outgoing access to the VPN server will prevent casual 
attackers from taking advantage of your Internet connection.

None of this requires high amount of technical knowledge and allows to 
provide a good level of security independently of your WiFi security level.

I hope these few elements help you to see things a bit clearer and, 
maybe, give you some useful ideas.

Regards,
Simon.

-- 
WhiteWinterWolf
https://www.whitewinterwolf.com

In message <49252eda-3d48-f7bc-95e7-db716db4ed91 at whitewinterwolf.com>, 
"WhiteWinterWolf (Simon)" <freebsd.lists at 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?  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