...making Linux just a little more fun!
Ben Okopnik [ben at linuxgazette.net]
WEP, since pretty much its very beginning, was acknowledged as a stop-gap protocol. Seems that the gap has been bridged:
https://eprint.iacr.org/2007/120
Abstract: We demonstrate an active attack on the WEP protocol that is
able to recover a 104-bit WEP key using less than 40.000 frames in 50%
of all cases. The IV of these packets can be randomly chosen. This is an
improvement in the number of required frames by more than an order of
magnitude over the best known key-recovery attacks for WEP. On a IEEE
802.11g network, the number of frames required can be obtained by
re-injection in less than a minute. The required computational effort is
approximately 2^{20} RC4 key setups, which on current desktop and laptop
CPUs is neglegible.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Rick Moen [rick at linuxmafia.com]
Quoting Ben Okopnik (ben@linuxgazette.net):
> WEP, since pretty much its very beginning, was acknowledged as a > stop-gap protocol. Seems that the gap has been bridged: > https://eprint.iacr.org/2007/120
The whole notion of wrapping an entire wireless session in crypto, embedding that crypto in hardware, and declaring it blessed, was an obviously bad idea all along -- and also unnecessary, since sound algorithms for authentication and session encryption already exist higher in the stack. Smart people have therefore always simply ignored WEP, and fortunately can just continue so doing.
For the same reason, whatever sucker bait eventually replaces the "stop-gap protocol" will be equally easily ignored.
René Pfeiffer [lynx at luchs.at]
On Apr 14, 2008 at 1231 -0700, Rick Moen appeared and said:
> Quoting Ben Okopnik (ben@linuxgazette.net): > > > WEP, since pretty much its very beginning, was acknowledged as a > > stop-gap protocol. Seems that the gap has been bridged: > > https://eprint.iacr.org/2007/120 > > The whole notion of wrapping an entire wireless session in crypto, > embedding that crypto in hardware, and declaring it blessed, was an > obviously bad idea all along -- and also unnecessary, since sound > algorithms for authentication and session encryption already exist > higher in the stack. Smart people have therefore always simply ignored > WEP, and fortunately can just continue so doing.
True, and you can easily combine 802.11b/g with IPsec or OpenVPN. Both should be safe enough when coupled with X.509 certificates (remember, short pre-shared keys can always be brute-forced). Keep a transparent proxy near the access point for all unauthenticated users and XOR/ROT13 all their unencrypted packets. ;)
If you want to stay within the means of 802.11 go for WPA2 with a 64-bit pre-shared key or again X.509 certificates (defined as per 802.11i). If you have a RADIUS server at hand (or always wanted to configure one ;), you can move the whole authentication and key management business off your access point to other segments of the network (also called the "enterprise mode"). Enterprise mode is reasonably safe provided no one attacks the RADIUS<->access point communication (RADIUS uses MD5-hashed passwords).
Best, René.
Rick Moen [rick at linuxmafia.com]
Quoting René Pfeiffer (lynx@luchs.at):
> True, and you can easily combine 802.11b/g with IPsec or OpenVPN. > [...]
That all seems like drastic over-engineering, to me.
Locally, in my house LAN, we have non-encrypted, non-authenticated, no-fuss 802.11b wireless. People who use the wireless networking simply know that, and bear it in mind. E.g., if you wish to conduct a authenticated, encrypted session of any type of traffic, you use whatever application-level handling gives you the desired sort of authentication and encryption: SSL/TLS SMTP, IMAP-SSL, ssh tunnels with proper attention to key handling, and so on.
That is, if one assumes one's LAN or WAN link isn't inherently private and intrusion-proof -- isn't wrapped in magic crypto pixie dust to make it "blessed" and inherently trustworthy -- then the correct course of action is entirely obvious. And effective. And doesn't risk becoming unfixable in the future because a buggy or obsolete implementation has been burned into some WAP's firmware, or deep in some networking gear's infrastructure.
And, oddly enough, we take the exact same attitude to the house wired LAN. Why trust the wired LAN when I have random LUG members attending user group meetings on my back porch every 2nd and 4th Saturday? I don't trust them with my paper-based banking details, either, so why should I trust them with my networked computing data?
I developed that frame of mind during 1994-2000, when all my machines lived on the same ethernet hubs as the Linux-based Internet cafe downstairs that I helped build in San Francisco, and it's served me extremely well.
And, before someone asks: If someone ever parks out in my driveway and connects to my wireless network, and attempts outbound SMTP spam-injection, he/she can anticipate DoSing via annoyed homeowner with baseball bat. ;->
René Pfeiffer [lynx at luchs.at]
On Apr 14, 2008 at 1355 -0700, Rick Moen appeared and said:
> Quoting René Pfeiffer (lynx@luchs.at): > > > True, and you can easily combine 802.11b/g with IPsec or OpenVPN. > > [...] > > That all seems like drastic over-engineering, to me.
Well, it might be, depending on what kind of access point you want to have. Depending on the purpose either unencrypted, WEP, WPA/WPA2 or VPN access points can make sense.
> Locally, in my house LAN, we have non-encrypted, non-authenticated, > no-fuss 802.11b wireless. People who use the wireless networking simply > know that, and bear it in mind. E.g., if you wish to conduct a > authenticated, encrypted session of any type of traffic, you use > whatever application-level handling gives you the desired sort of > authentication and encryption: SSL/TLS SMTP, IMAP-SSL, ssh tunnels with > proper attention to key handling, and so on.
Yes, that's true, and I use encrypted application-level protocols where possible and sensible. There's even a group that promotes secure network design (https://www.opengroup.org/jericho/about.htm) by "using a well-defined mix of encryption, inherently secure protocols, and data-level authentication".
> That is, if one assumes one's LAN or WAN link isn't inherently private > and intrusion-proof -- isn't wrapped in magic crypto pixie dust to make > it "blessed" and inherently trustworthy -- then the correct course of > action is entirely obvious. And effective. And doesn't risk becoming > unfixable in the future because a buggy or obsolete implementation has > been burned into some WAP's firmware, or deep in some networking gear's > infrastructure.
I fully agree, and my suggestions wasn't meant to "secure" the access point. Just adding encryption may not increase trustworthiness.
> And, oddly enough, we take the exact same attitude to the house wired > LAN. Why trust the wired LAN when I have random LUG members attending > user group meetings on my back porch every 2nd and 4th Saturday? I > don't trust them with my paper-based banking details, either, so why > should I trust them with my networked computing data?
Who said I trust wires more than thin air? ;)
> [...] > And, before someone asks: If someone ever parks out in my driveway and > connects to my wireless network, and attempts outbound SMTP spam-injection, > he/she can anticipate DoSing via annoyed homeowner with baseball bat. ;->
Do you have a special doorbell that rings when strange MACs connect? ;)
Best, René.
Rick Moen [rick at linuxmafia.com]
Quoting René Pfeiffer (lynx@luchs.at):
> Well, it might be, depending on what kind of access point you want to > have. Depending on the purpose either unencrypted, WEP, WPA/WPA2 or VPN > access points can make sense.
It's possible my fundamental point might have been unclear: I'd simply rather _never assume_ that my networking infrastructure will protect against bad things (eavesdropping, forgeries), no matter what that infrastructure is capable of -- for what I regard as sound policy reasons.
It doesn't bother me if that infrastructure-level "protection" is present as long as it doesn't interfere with my operations (though experience suggests it frequently does interfere) -- but I don't rely on it. Having taken care of my own authentication and encryption needs at the application level, those infrastructure mechanisms can be ignored as superfluous -- which has proven a good thing in the wireless context, as the protocols have been badly designed, brittle, poorly compatible, and basically a lot of trouble and very little good.
Basically, starting in the early 1990s, I came to be comfortable with dealing, on the level of each host, with the security exposures one sees on the open Internet, decided there's little to be gained from regarding any network connection as being any more trustworthy than the open Internet, and adjusted my assumptions and practices accordingly. Guess what? It works splendidly, facilitates genuine defence in depth (as opposed to the "let's just wrap everything in another layer of software and hope for the best" kind), and helps promote overall sysadmin competence and self-reliance.
> Do you have a special doorbell that rings when strange MACs connect? ;)
Let's just say that one reasonable and proportionate response to finding one's self (at least somewhat) responsible for a LAN is to monitor what occurs over it.
Deividson Okopnik [deivid.okop at gmail.com]
I guess it all depends on the size of the network, and on how secure you need it to be - I wouldnt go trough all that to secure my home network (in wich a MAC filter would be more than enough) - but we do use WPA along with mac filtering in my work's wireless network, along with a proxy/domain that requires auth.
Kapil Hari Paranjape [kapil at imsc.res.in]
Hello,
On Tue, 15 Apr 2008, Deividson Okopnik wrote:
> I guess it all depends on the size of the network, and on how secure you > need it to be - I wouldnt go trough all that to secure my home network (in > wich a MAC filter would be more than enough) - but we do use WPA along with > mac filtering in my work's wireless network, along with a proxy/domain that > requires auth.
I have found that configuring WPA2 with shared keys is as easy as configuring WPA or WEP. Moreover, most hardware post 2004/2005 supports it. Why not use it?
Regards,
Kapil. --
Ben Okopnik [ben at linuxgazette.net]
On Mon, Apr 14, 2008 at 01:55:21PM -0700, Rick Moen wrote:
> > Locally, in my house LAN, we have non-encrypted, non-authenticated, > no-fuss 802.11b wireless. People who use the wireless networking simply > know that, and bear it in mind. E.g., if you wish to conduct a > authenticated, encrypted session of any type of traffic, you use > whatever application-level handling gives you the desired sort of > authentication and encryption: SSL/TLS SMTP, IMAP-SSL, ssh tunnels with > proper attention to key handling, and so on. > > That is, if one assumes one's LAN or WAN link isn't inherently private > and intrusion-proof -- isn't wrapped in magic crypto pixie dust to make > it "blessed" and inherently trustworthy -- then the correct course of > action is entirely obvious. And effective. And doesn't risk becoming > unfixable in the future because a buggy or obsolete implementation has > been burned into some WAP's firmware, or deep in some networking gear's > infrastructure.That's pretty much my own approach whenever I have to deal with that kind of an issue. I consider any network connections - anything past the physical confines of my computer - to be part of the "Internet cloud", and precisely as secure. In light of that, and given even the small risk of break-in via the few network services that I run, I deal with my data accordingly (essentially as if it was all on an open public network.)
I also appreciate Bruce Schneier's approach to a similar issue: open wireless networks.
I'm also unmoved by those who say I'm putting my own data at risk, because hackers might park in front of my house, log on to my open network and eavesdrop on my internet traffic or break into my computers. This is true, but my computers are much more at risk when I use them on wireless networks in airports, coffee shops and other public places. If I configure my computer to be secure regardless of the network it's on, then it simply doesn't matter. And if my computer isn't secure on a public network, securing my own network isn't going to reduce my risk very much. -- Bruce Schneier https://www.schneier.com/blog/archives/2008/01/my_open_wireles.html
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *