Slashdot Mirror
802.1X Security Overview
HJ Franzen writes "Ars Technica have what they call a wireless security blackpaper posted that's well worth a read. I wish this was available when I was spec'ing wireless VPN solutions for my campus. The article is pretty detailed and discusses the many ways in which companies are trying to address the fatal flaws in WEP."
Really! I'm enjoying my free broadband!
Just keep using it, everything is all right.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
how the current standard is broken, visit toms hardware:
/ in dex.html
http://www.tomshardware.com/network/02q3/020719
They've got some good information on why 64/40 and 128 bit encryption isn't enough; as well as why the current "consumer-level" equipment can't do enough to thwart drive-bys.
Karnal
... unless it's encrypted. Even then, your signal will be able to be recored and broken 10 years later when computers are faster.
I have a Zaurus SL-5500, and when using it with my 802.11b network, it doesn't seem to care about the SID.
It doesn't matter what name I use, it seems to always work. Has anyone else experienced this?
John
The drops of water don't know themselves to be a river; and yet the river flows.
The SSID should be created with the same rules as any strong password (long, non-meaningful strings of characters including letters, numbers and symbols).
By default the Access Point broadcasts the SSID every few seconds in what are known as 'Beacon Frames'. While this makes it easy for authorized users to find the correct network, it also makes it easy for unauthorized users to find the network name.
Can someone then explain to me what is the reason for choosing a secure SSID?
i use a little "consumer elvel" access point/router with DHCP turned off, and a strong subnet mask (i'm talking 29 bits!) then i filled up every IP address in the range by assiging multiple ip addresses to the adapter on my server
--fetch daddy's blue fright wig, i must be handsome when i release my rage
whats the difference between an encrypted ack packet and a non enc'd one from a sniffing point of view not a one..
any key you could possible be using will get exposed through these very well documented and standardized packets.
short of non-reversable encs like md5 it is basically impossible to protect data if you know the before enc and after enc data on a common packet.
even if they manage to enc say only data in a packet. a smart sniffer will realise that if he/she sends a standard packet with data to the ip hes trying to access that they can get the keys that way too. This changes the nature from a purely passive interception attack but none-the-less doesnt make it at all secure.
its been well known in military tactics for decades that no matter how you encrypt your data it will always be broken when its exposed to scruitany. Hell pgp can even easily be broken if you know the source doc before encryption and thats supposed to be one of the most secure encryption devices out there.
Add to this that with tcpip you'll always know the source I cant see how you're gonna encrypt the packets short of changing the way tcpip works.
If you're going to use wireless dont expect absolute privacy. This should never have been a concern. If you want security fork out the bucks for wired systems.
Transmitting any sensitive information over radio just doesnt make any sense and is the very reason for the extreme security measures taken by governments. For example in nuclear launch codes.... One time use of one code which has to be on the sub prior to it leaving dock. ol dubyah cant just call up some sub and say launch without the right one of these codes and for good reason.
As for unrestricted broadband access (connection sniffing/interjection) thats tougher. How do you keep someone who can know your keys off your system well you got two choices... You setup a custom algorithm that changes the keys on both the client and access point according to a certain time internally. At best a hacker will grab 3 or 4 of these keys but if they continually rotate around something that cant be standardized it would be very difficult short of knowing the algorithm used to change keys to get reliable access tho it would undoubtedly be possible given enough time to figgure out the deal with the algorithm.
Any way you look at it its gonna be security through obsfuscation and theres really nothing you can do about it. You want wireless you're gonnna have to accept the freeloaders on your service.
To me tho id encourage open access points to everyone. But then again im sure you dont want to get your cute little ip banned from your favorite channel. Maybe ipv6 could help with a translated address or such. i dunno but as it is now you cant block wireless access so why even try.
Are you trying to say I am the only one who has been hacking in to windows systems, applying patches, and beefing up security? I mean, the ends justify the means, right? Just don't be surprised if you leave your system on, leave the room, and come back to discover gentoo running on it....
I haven't read the aforementioned article, but I will check it out. My experiences may just say the same thing as they say (or maybe not). So sorry if this is repeated.
WEP is a joke unless you keep rekeying connection, which depending on how many packets you throw across the connection may or may not be realistically possible. (In many cases I'd guess not)
Choosing a secure SSID as someone mention won't get you very far if you're running in infrastructure mode since it broadcasts that. And if someone knows you have an AP then they can scan channel by channel until tcpdump picks something up and then you really don't need an SSID.
IPSec is a widely accessible protocol that gives the ability to encrypt communications and do authentication (in much the same way that ssh does it). IPSec is available on many platforms: Linux, Windows 2k/XP, BSD, (I think Mac OSX does), and most of them support it natively (ie no slow userspace daemons to run).
Using the authentication you can allow only authorized clients to connect, by allowing only IPSec packets through your router and then let IPSec do the rest. IPSec also does rekeying for the encryption so it's much safer than WEP.
Patrik
----------
Just your ordinary BOFH
http://killertux.org
For subscribers only?
I like to make PDF's of pages of particular interest for offline reading and archiving should they ever go offline.
I usually click the printer friendly version if they have one, print it to a file, which gives me a postscript file within Linux, then using the a tool that come with ghostscript (?) "ps2pdf" the file. It usually comes out very nice.
But with Ars, I prefer to just grab the article with wget, since they don't seem to offer a printer friendly version outside of a subscribers only PDF file. Anyone subscribed? Free?
Course, now I have OS X, I just print preview then save to PDF.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
in my town there are so many (mostly linksys) AP's that use the default SSID that I could practically drive arround and hit the internet from anywhere. It would be interesting to compromise a machine across the internet while connected to someone else's AP... the deleting of your logs is basically driving home.
- what is the definition of simultanagnosia?! I've been meaning to look it up!
There will always be people willing to break the encryption no matter what the costs in time, and technology. If you wanted access to my Internet connection through my 802.11 (without physically breaking into my home), you could get it eventually. But I can make it difficult for you, and that is the point.
Encryption was never to prevent information from being intercepted. It was never to stop data from being read. It was to delay. It comes back to the simple question - how important is the security of your network/data?
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
ok i know the last one was that "infamous" M$ paper, but could someone give me a "color chart" as to define all these different papers that i'm seeing more and more often posted on slashdot?
moox. for a new generation.
But who will want your 10-years old porn collection or DIVX rips?
The joke here is that ars has published an aritcle that has useful technical information, but their website has a black background with white text. Therefore, this is a black paper.
I don't want free as in beer. I just want free beer.
Blackpaper? That's a kewl term I haven't heard before. I suppose it's a paper in response to a white paper showing the dark side of a technology?
M@
Krispy Cream is people
Security is only one issue that needs to be considered in implementing wireless networking. We identified three key issues in developing a wireless strategy: (1) security that was "good enough", (2) end-user simplicity, and (3) technical staff set-up and management.
We eventually decided to use Nathan Zorn's Authentication Gateway. Wireless connections are blocked at the gateway until users connect via ssh. Clients need to have ssh and know the name of the gateway: everything else gets configured automatically. The system uses iptables, PAM, and ssh and the only admininstration required is to build accounts. The system might not scale well, but works well for an entity our size (one department).
I gave a presentation about our conclusions.
There was a mention of using a VPN scheme to secure your wireless LAN, which would be fine to protect your own data but still allows 'visitors' to piggyback their own networks on top of yours. This still allows the 'visitor' to take an IP address from your DHCP server and talk to the other machines.
This thought might not solve the piggyback problem but it might go a step further in securing your data. Use a PPPoE server (such as a Win2K box running RASPPPoE) to hand out network addresses and require all your clients to connect using some form of PPPoE (again, such as RASPPPoE) which can be reasonably protected using MD5 CHAP for passwords and encrypted packets.
The only thing exposed then are MAC addresses, so 'visitors' could still piggyback their own network on top of yours, but they're not taking up IP addresses or able to see *anything* on your network except other MAC addresses.
And if you wanted to be really smart you could have a probe program (too bad one doesn't exist yet) that could compare a MAC address to a matching PPPoE connection, say every ten minutes. If a MAC address doesn't have a corresponding PPPoE connection, it's blacklisted for a while and the port is freed for a legitimate client.
Use Evolution instead of Outlook? Bewa
The only major objection I have is that Ars is presenting some WEP problems as being RC4 problems ie: that RC4 is broken and cannot be secure if implemented properly. "The main problem with WEP is that the RC4 stream cipher used to encrypt the data has been proven insecure." I'd change that to read ".. has been proven insecure if research notes regarding these problems are ignored."
They claim the RC4 algorithm itself is broken, which it is to some degree, but there's lots of information on how to avoid these problems that was available prior to the design of WEP. I also dislike their implication that RC4 inherently uses a 24 bit IV, that was an IEEE decision, RC4 can use an IV that's as large as you want.
RC4 is reasonably secure when implemented correctly, but IEEE ignored the very well known and clearly stated fact that when using RC4, keys must not be re-used for the same data. And that's not surprising, block ciphers are greatly weakened by such things too, which is why anyone in their right mind uses a decent sized IV. RC4 is weaker to key reuse than block ciphers because of its design, but that was a well known fact prior to the design of WEP.
Weak keys are a genuine weakness in RC4. However, they too are well documented and can be easily detected and skipped prior to use. The fact that WEP uses a 24bit IV makes it particularly easy to create a table of IVs that weak, making this problem significantly worse. A great paper on RC4's weak keys, and how to avoid the problem, was posted to sci.crypt in 1995:
http://marcel.wanda.ch/Archive/WeakKeys.txt
So all the weaknesses in WEP that stem from the use of RC4 as an encryption algorithm were well documented, and methods of avoiding them resulting in weaknesses were well known, but the IEEE chose not to heed them. They were trying to make something "secure enough" and traded off things like using a short IV without consulting the cryptographic community about the implications.
Hindsight is 20-20, but I can't exactly call these RC4 flaws. I mean, if you had a power tool and you ignored the warnings printed in the manual, would you blame the tool when it fails?
Using a short IV is clearly an implementation flaw, the fault of WEP not RC4. IEEE wanted to save a few bytes of overhead and purposefuly chose a short IV. The weak keys are a flaw in RC4, but just generating a few bytes and discarding prior to using the key helps reduce the scope of this attack dramaticly. Even better is to detect and avoid the use of the weak keys in the first place, or do both. Since this was widely known when WEP was designed, I consider it to be a implementation flaw in WEP as well, albeit one that stems from a weakness in RC4.
-Matt
In other news, a consortium of large companies has announced that they have developed a building material that spray paint cannot adhere to. This should help companies that can not or will not secure their networks protect themselves from the insiduous threats of wardriving and warpainting. More news at 11.
The article seems very intent on proving that every possibility is flawed. However I wonder about their VPN reasoning. They exude that using VPN's you can still let "crackers" talk and communicate using your WAP. But why would anyone go to the trouble of hacking into a WAP, just to essentially use ad-hoc mode on their wireless cards?
Bueller?
Bueller?
1. Authentication comes before association, not the other way around as the article mentioned. Authentication was not added in 802.11b it was there in the original 802.11 spec.
:)
2. Decryption takes no longer with 128 bit wep than it does with 64bit wep. This depends on the actual RC4 implementation, but anyone who implemented RC4 in a way that it takes twice as long to crypt a 128bit string than it does to do 64 bits doesn't know what they are doing. Most implementations use a lookup table that makes encryption take the same amount of time regardless of key length. I'm no encryption expert, but I believe that all symetric algorithms share this attribute. It certainly won't "drastically shrink useable bandwidth" unless you have a very lame access point or 802.11 card. I don't believe any implementation will reduce the bandwidth at all by using 128 bit encryption.
3. Turning off beacon frames breaks some important 802.11 features, such as power management support. What most vendors do is not disable sending beacons, but they lie about the ssid (or leave it blank) in the beacons, and only respond to probe requests if the client request the correct ssid in the probe.
4. Turning off or hiding the ssid gives you no security whatsoever. All it does is keep the casual person from seeing your network. Any form of WEP will work better than that, because the casual user won't be able to exchange data packets on your network. The professional cracker will not be slowed down at all by hiding the ssid, all it takes is a sniffer to listen for a probe request/response which contains the actual ssid. Anyone who thinks they are securing their network in this way is deluding themselves.
5. I won't repeat the comments previously made about the authors incorrect understanding of how RC4 works, and why it is exploitable in this implementation.
After I finish reading the parts on 802.1x maybe I'll add to this list.
- Access to other attackers in your group over the wireless.
- Access to legitimate clients.
As you point out, the former isn't really a super big deal. The latter, however, means that the attacker can probe legitimate clients on the same WLAN, find a weakness in one, and gain access to that box. Once an attacker has access to a legit client, I'm sure you can see the way forward.When you say something like 802.1X and you mean all wireless, you are showing ignorance.
802.1 encompasses a large number of wired standards in addition to wireless.
Or maybe the poster meant the actual standard named 802.1x? Port Based Network Access Control? I thought that was used for tying switch ports to certain MAC addresses.
I propose if you mean to say "all the 802.11 standards" you say 802.11*, since IEEE uses letters such as "x" to denote certain standards, not as a wildcard.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
The whole article is a bit silly, pushing relatively unproven standards (EAP) which have been extended (LEAP) and extended (PEAP) over VPN standards with a good trackrecord (IPSEC).
The client is always the weakest link, for both VPN and wireless access. Basically, the author's argument boils down to saying that most IPSEC clients do not block access from other clients while they are connected (split tunneling), whereas the [LP]EAP clients do.
It's a matter of configuration. There is no way one can claim that one client is more secure that the other. Clients are always unsafe, and if not, its user is :-). I'm sure a determined recalcitrant enduser can always hack his [LP]EAP client to enable split tunneling, or other unsafe settings.
The only way to fix this (for both VPN and wireless) is to supply the user with trusted hardware. But that would mean a lot of money and a revolt of endusers because their PCs will be taken away...
By the way, here's an article by Microsoft on this matter. It basically says that Microsoft will solve all your problems if only you would buy into the latest Microsoft offerings.
Would you rather use a solution based on open standards, try Wavesec. It is mostly based on IPSEC, DHCP and DDNS.
-------
Warning: Slashdot may contain traces of nuts.
Your speech is as free as a bird, but Slashdot's providing of a forum is not. If you don't care for Slashdot's policy, set up your own website or STFU.
chops and chekhov are right, and the (currently +4!)comment they're replying to is wrong.
All the block ciphers in PGP, like IDEA, CAST and so on have (so far) survived cryptanalysis based on known plaintext attacks. In fact, a cipher is considered "cracked" in the academic sense if the key can be retrieved with *chosen* plaintext in less time than by searching all possible keys.
The "black paper" makes this conclusion about shared-secret authentication as part of association:
"By passively listening to the conversation, an attacker can obtain two of the three variables in the authentication equation; the clear text challenge string and what the challenge string looks like after it has been encrypted. By plugging these values into the RC4 equations, the attacker can easily solve for the shared authentication key. "
Actually, this is not what their referenced whitepaper describes at all. By observing the authentication sequence, an attacker can forge an authentication by responding correctly to the challenge without knowing the WEP key. This is made possible by the amateur 802.11b authentication scheme, not because RC4 is easily 'solved'.
So, while the shared secret authentication does not hinder a determined attack, it is incorrect to say that it weakens security at all. In the case of unenthusiastic stumblers, it may hinder casual associations with your AP.
To recommend an "open authentication" scheme for improved security seems like bad advice.
Apparently "blackpaper" means "white text on a black background".
Please - this is one fad from the '90s that deserves to die, quickly.
I've been thinking of hacking together a somewhat simple system that would randomly generate WEP keys, use tcl/expect/perl-expect whatever to control lynx-ssl to connect to my AP, set up a new WEP key on the AP (it can have multiple keys), then ssh to my laptops and change the wep keys on them.
One could easily write small scripts for whatever AP or system you wanted to reconfig, assuming you can do 'em from a command line.
Comments?
-- I speak only for myself.