Re: A comment on NetworkManager

["Robert G. Brown" <rgb phy duke edu>]

On Thu, 11 May 2006, Aaron Konstam wrote:

> On Thu, 2006-05-11 at 09:51 -0400, Robert G. Brown wrote:
> > On Thu, 11 May 2006, Russell Harrison wrote:
> >
> > > must remember to hit "reply to all"
> >
> > :-)
> >
> > While we're accreting wish lists, let me add mine:
> >
> >    1) NM should to be able to manage keys and protocols (including WPA
> > and WPA-2, given that WEP is pretty much useless no matter how many bits
> > it has:-) without having to unlock the keyring.  I know the
> > key-unlocking problem will soon be solved "outside" of NM per se, but
> > hey, the WEP key for myssid is preserved in e.g.
> >
> >   P key
> .gconf/system/networking/wireless/networks/myssid
>
> This is  interesting, since the WEP key requested is for 13 characters
> but the WEP key recoorded is only 10 characters. What is going on?
>
> However, my directories are 700 so only I can read it.

This is a (smart) user choice, of course, but many users or new account
programs might create the tree 755 or whatever.  And besides, as long as
it is stored even 700 in cleartext, using a "decryption" step via the
keyring is just silly.  Either store it encrypted (only) or don't bother
encrypting it.  I'm inclined toward having the choice -- a userspace 700
DEFAULT security level on this part of the .gconf tree or at least all
files containing keys OR not storing the keys there at all and using
strict encryption.

This isn't an obvious choice to make -- most users would probably be
just fine with the 700 option, especially for WEP keys. 64-bit WEP takes
anywhere from five minutes to an hour of passive monitoring to break in
the worst cases and WEP in general should never take anyone longer than
ten to twenty hours to break, regardless of key length (the weakness is
in the 24 bit initialization vector used in BOTH 64 and 128 bit WEP,
transmitted in cleartext, which lets people statistically analyze
traffic on easily discoverable broadcast SSID networks and deduce the
static shared key).  Additional problems include its vulnerability to
man-in-the-middle attacks because of its lack of host authentication,
because most access points broadcast their ESSID, because tools like NM
can reconnect your network without warning so that you "think" you're
entering something into a secured encrypted channel not realizing that
you've reconnected to a new WAP and the remote password you are typing
is going out in cleartext (something that has happened to me already
more than once, or would have if I didn't use additional layers e.g.
ssh) and so on.

I think of 64-bit WEP (metaphorically) as like locking a door to your
house on a public street with one of the non-deadbolt type locks.  It
keeps the riff-raff out, but any real burglar will use a credit card or
aluminum ruler to open the door almost as fast as you can open it with
the key.  Which is fine -- that keeps out 99.99% of potential intruders,
as most of them are people who live in your neighborhood who just happen
to pick up your broadcasting SSID and could connect without even MEANING
to without WEP (as happens all the time to me at home as one of my
neighbors has "nothing" so my wireless connects there while I'm trying
to do all the mouse clicks and keyboarding required to get it to connect
to my non-broadcasting 64-bit WEP access point at home).  I don't care
if it is crackable, as all of my systems use e.g. ssh or ssl to encrypt
most of my network traffic, although NFS is probably (sigh) vulnerable
to somebody determined and knowledgeable.

128-bit WEP is a tiny bit stronger -- like using cheap deadbolts,
perhaps -- but your windows are still smashable, a lockpick can still
open it pretty easily.  Not broadcasting your ESSID in either case
stronger still although still pretty weak -- first they have to FIND
your house which is no longer on ANY street in plain sight -- you have
to know how to reach it through the woods or how to follow somebody who
is going there.

However, if you are doing e.g. something with medical records (EMRs)
then HIPAA requires, I think, something a bit stronger than WEP, period,
with or without broadcast ESSIDs.  WPA isn't bad -- it solves most of
the "obvious" problems with WEP but perhaps isn't NSA-grade security as
it has weak or static authentication.  WPA-2 is probably DOE/NSA grade
secure -- active authentication layers as well as a pretty solid
encryption scheme.  So ultimately for linux laptops or other wireless
tools to be useable in an EMR or DOE or corporate secure setting where
money or privacy or lives are really on the line, they (and NM) will
need to completely support them.  I still don't know much about MIMO and
whether it is yet another extension in security-land or more about
bandwidth on top of e.g. WPA-2, but that's coming as well.

The point being that NM is currently treating security in a very
internally contradictory manner -- supporting WEP (a good thing, don't
get me wrong) when WEP is basically "why bother" false-sense-of-security
aside from doing the exclusion what white/black/greylists would do much
better, forcing WEP through a forcibly re-authenticated keyring when it
is stored in cleartext (where 700 cleartext is pretty much, like WEP,
enough to keep casual attackers out and no more), and so on.

I personally tend to be cynical of any security measure that being root
on a system can obviously thwart beyond the obvious ones like using 700
files (readable by root with essentially no effort).  Root can easily
record and control 100% of what passes through the systems I/O channels
-- e.g. every keystroke you type as you type in passwords or keys -- and
of course all of the system's memory.  root can trivially su to any
user, or change permissions on any file.  Protecting root is something
one has to do as the sine qua non of all security, but MOST of what one
can do to secure a system at the user level is trivially circumventable
once root is compromised.

So I'm perfectly content for WEP keys, or even WPA keys, to be stored in
cleartext 700 in userspace or rootspace but see little point in making
things more complicated and cumbersome for users on top of this.  Any
measure that protects the keys from being trivially accessed by non-root
non-owners is as good as gpg encryption with a 2048 bit key and a
paragraph-long passphrase in that a root compromise gets them either
way, with nothing but a slight delay in the case of the encrypted key.
This delay isn't a terrible thing -- sometimes all that is needed to
detect an intrustion is time.  But layers of encryption like this often
provide an ILLUSION of "real security" that distract people from the
sober contemplation of risk.

BTW, I forgot to add to my wish list that NM would pop up a warning when
LEAVING any WEP/WPA (white) network, before entering an open/promiscuous
wireless network, white, grey or blacklisted!.  One should NEVER "think"
that one is connected to a particular white, secure access point, get a
cup of coffee and come back to find out only AFTER accessing some
network service that you are "oops" -- now connected through your
neighbor's non-encrypted WAP and anything you might have been doing has
been snoopable by any drive-by hacker for the last twenty minutes.

It wouldn't hurt to add the ESSID of the current connection beneath the
little bars icon as well so one can tell at a glance what one is
connected to.  Yes, this makes it readable over your shoulder.  However,
it makes it READABLE without taking mouse action over and over.  White
connections with non-broadcast ESSIDs could be represented by an index
from the white table, or a white icon, or a little locked icon if ESSID
on the task bar is considered too insecure, but because my wireless
tends to drop and reconnect every time we use the microwave downstairs I
find myself misconnected WAY too often for comfort the way this is done
now.

   rgb

--
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb phy duke edu