WPA2 Security Flaw Puts Almost Every Wi-Fi Device at Risk of Hijack, Eavesdropping (zdnet.com) 262
A security protocol at the heart of most modern Wi-Fi devices, including computers, phones, and routers, has been broken, putting almost every wireless-enabled device at risk of attack. From a report: The bug, known as "KRACK" for Key Reinstallation Attack, exposes a fundamental flaw in WPA2, a common protocol used in securing most modern wireless networks. Mathy Vanhoef, a computer security academic, who found the flaw, said the weakness lies in the protocol's four-way handshake, which securely allows new devices with a pre-shared password to join the network. That weakness can, at its worst, allow an attacker to decrypt network traffic from a WPA2-enabled device, hijack connections, and inject content into the traffic stream. In other words: hackers can eavesdrop on your network traffic. The bug represents a complete breakdown of the WPA2 protocol, for both personal and enterprise devices -- putting every supported device at risk. "If your device supports Wi-Fi, it is most likely affected," said Vanhoef, on his website. News of the vulnerability was later confirmed on Monday by US Homeland Security's cyber-emergency unit US-CERT, which about two months ago had confidentially warned vendors and experts of the bug, ZDNet has learned.
Finally! (Score:5, Informative)
Public announcement from Mathy Vanhoef is https://www.krackattacks.com/ [krackattacks.com] and his research paper can be found https://papers.mathyvanhoef.co... [mathyvanhoef.com].
nice work ! (Score:2)
this just goes to show who is paying attention :
https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4
What the fuck is Google going to do about Android? (Score:5, Insightful)
I'm really fucking concerned about how Google will fix this for Android, the most popular OS in the world.
Recent stats [android.com] are showing that only 0.2% of users are using Android 8.0, the latest version. Only about 18% are using Android 7.x releases. A whopping 32% are using Android 6.x! About 28% are using Android 5.x! About 21% are using Android 4.x!
So like 80% of Android users are still using Android 6.x and earlier!
If this problem can be avoided with a software fix, I think that Google should do everything they possibly can to get this fix to as many Android devices as possible.
I'm sure some fools here will come along and just tell affected users to "buy a new phone" or some infeasible bullshit like that. Realistically, that's not happening. Users will continue to use their older devices. It will reflect badly on Android if it's susceptible to this wifi security issue, even on older devices.
While they obviously can't provide updates to all of the Android devices out there, I really hope that Google will do what they can to get the fix to at least all Nexus and Pixel devices from the Nexus 4 onward.
The most sensible solution would be to fix it in Android 8.x, and then port Android 8.x to the Nexus 4 and all devices after it. Then this release would be made available to those who wish to upgrade. Not only would this fix this wifi problem, but it would also help fix at least some of the serious version fragmentation that Android is currently experiencing.
Re:What the fuck is Google going to do about Andro (Score:5, Interesting)
Google can't do anything about that.
It's the fucking telcos who are withholding updates from the end users. Even if you have the patched version on your hard drive, you can't install it, because your wireless provider won't let you. Verizon is the most egregious offender; as long as they continue to refuse to sell devices with unlocked bootloaders, the only way to install an update is when the telco feels like pushing it to the users.
Comment removed (Score:5, Informative)
Re: (Score:2)
This is where it goes wrong, android updates should be automatic for all phones that have android unless it's a driver issue, which this isn't.
I don't depend on ASRock or Intel to update my OS, Why should I depend on Samsung? Windows updates itself fine, as does Linux. But not Android, and it's clearly a system that doesn't work and will leave literally 100s of millions of devices open to being trojaned.
Things won't change until Mega-Corp A sues Mega-corp B or Little-Corp C for allowing their devices to be
Re: (Score:2)
Bullshit. Almost every carrier-sold device has a locked bootloader, and some are even SIM-locked.
A locked bootloader prevents you from:
1) Rooting the device.
2) Installing Lineage|Cyanogen|Any-other-OS.
Whereas a non-carrier branded device can usually be unlocked and the OEM has infrastructure in place to enable it - see Xiaomi, Motorola (Lenovo), etc.
Re: (Score:3)
but Android devices aren't something telcos have control over.
I take it you're not American? Yeah in most of the world the telcos in general don't get in the way much. However in America, the latest and greatest Android phones are telco specials, telco controlled, with telco specific firmware.
For example if you're the owner of a Galaxy S7 in the USA you will have one of these models depending who you buy it from:
SM-G930U
SM-G930V
SM-G930VL
SM-G930AZ
SM-G930A
SM-G930T1
SM-G930R6
SM-G930R7
SM-G930P
SM-G930T
SM-G930R4
If you're in Europe / The rest of the world with the exception o
How do home ISPs withhold tablet updates? (Score:2)
It's the fucking telcos who are withholding updates from the end users.
How is this true of Wi-Fi-only tablets or unlocked phones? For example, what power does Comcast have to withhold updates from my Wi-Fi-only Samsung Galaxy Tab A? That'd be like Comcast withholding updates from a Windows PC.
Re: (Score:2)
Expecting updates on a mobile device made ten years ago? What the hell you smokin? Sure, nowadays that's not quite so unreasonable as the pace of hardware improvement slows, but I don't expect manufacturer's to get in line any sooner than they're forced to. Hell, I'd even settle for allowing unlocking of EOL'd devices and pushing 'em to something like Lineage when available.
Re:What the fuck is Google going to do about Andro (Score:5, Informative)
The best thing might be for Google to provide appropriate security patch software for WPA2 for all versions of Android to carriers but it's likely they would never reach customer phones.
Re: (Score:2)
Re: What the fuck is Google going to do about Andr (Score:2)
Re: (Score:2)
Great! Now to get manufacturers to provide, if not push, updates on those devices. Best of luck!
Re:What the fuck is Google going to do about Andro (Score:4, Insightful)
Android 8 introduces Treble (Score:2)
I had hoped that it would be google, not the carrier or handset manufacturer providing updates. The manufacturer would provide drivers for the hardware, but Google would take care of the rest, similar to how MS rather than a PC manufacturer handles Windows updates.
Android 8 "Oreo" introduces Treble [android.com], which begins to refactor Android toward what you expected: a stable driver ABI.
Re: (Score:2)
Google stops providing security updates for their devices 3 years after they are first available.
I know that my Nexus 5 phone will not get patched by them.
Re:Finally! (Score:5, Interesting)
So basically, Windows and iOS were protected for implementing 802.11 incorrectly.
While Android got screwed over by implementing it rigorously.
This should also become a programming example of the difference between setting something to NULL vs setting it to zero. Instead of implementing the encryption key as a string, it shouldn've been implemented as a pointer to the string. And when the standard called for the key to be cleared, the value shouldn've been zeroed out (to prevent it from being recovered in memory), memory released, and the pointer set to NULL (so the software would know the value didn't exist anymore and wouldn't try to use it).
Re: (Score:2)
Re: (Score:2)
Read carefully: He said that setting the pointer to NULL would be in ADDITION to zeroing the key, to reduce the risk of the key remaining in memory. Now, let's just hope the compilers don't pull any "clever" tricks to undo those measures.
Re: (Score:2)
Maybe he meant that, maybe he didn't.
difference between setting something to NULL vs setting it to zero
"vs" does not mean "in addition to"
the value shouldn've been zeroed out
Since "should've" isn't a word I know of, I'm assuming the typo was omission of the "t" not the addition of the "n".
Parent DOES say "and" later in that sentence, so as I read it he/she is +2 for meaning "instead of", +1 for meaning "in addition to", and +100 for just in general not forming a coherent statement.
Re: (Score:2)
You can attack his syntax all you want, but since he was clearly describing behavior different than the behavior of wpa_supplicant, the meaning is clear that he is suggesting the behavior he illustrates be used instead.
Re: (Score:2)
Re: (Score:2)
No matter how you represent the key syntactically (as a string, as a reference to a string, with an additional 'bool key_valid' parameter, in hex or in base64) the underlying bug is a state machine bug.
What you've said is true, because you are using the nullity of the key to represent state information (in fact, every mutable variable represents ...drumroll... program state). Specifically, you are definition a state transition rule that says that you cannot install a null key (OK) and that when you install
Re: (Score:3)
So, strangely, it almost seems like Windows and iOS are doing the right thing here. Allowing replay of packet 3 is the source of the attack and actually makes no sense from a cryptographic standpoint. Crap on MS and Apple all you want, but someone was paying attention and said "nooooope".
Yup. And they chose to not disclose the vulnerability they discovered.
This is where a guild system would be a useful overlay on the corporate system.
Re:How serious is this? How exploitable is it? (Score:5, Interesting)
it's an attack on the client machine, not on the access point. ...).
it means that any unpatched device connected to a wifi network with WPA2 encryption can expect the same security as being connected to an unsecured wifi (anyone can eavesdrop your communication, or could inject stuff,
how easy it is to do, don't know yet, but it seems to be a feasible attack to carry out.
Re:How serious is this? How exploitable is it? (Score:5, Informative)
No it is an attack on both. Though it appears that patched clients would be safe while connected to an upatched AP.
Re:How serious is this? How exploitable is it? (Score:5, Informative)
And vice versa, a patched AP can prevent a client from breaking. One or the other side needs to prevent it, but either side by itself is sufficient.
For now... (Score:2)
For now, WRT the phone, turn off your WiFi, use data, and keep the "media" uproar to a minimum unless you have an unlimited data plan. That means no video, no music, no heavy pages, etc. unless you're willing to eat your data allowance pretty quick (that assumes you've been using wifi to keep from stuffing your phone provider's pockets.)
In any event, watch your data consumption. Overages are a cash cow. And you are the cow.
WRT your home system, use ethernet, and turn off wifi until / unless you know you've
Re: (Score:3)
Tomorrow's news story: critical security flaw found in LTE!
Re: (Score:3)
an expect the same security as being connected to an unsecured wifi
Not quite that bad. An unsecured wifi can have packets manipulated, and can snoop both directions. Here the attack cannot change any of the data and can only read one direction of the communication. Still pretty bad, but no reason to suddenly not care about open networks versus secured networks.
Re: (Score:2)
Didn't catch the part about GCMP, hopefully for once sluggish wifi implementations being behind the curves mean most are using CCMP.
TKIP should already not be in use for many reasons.
Re: (Score:2)
Isn't that what endpoint vpn tunneling is for?
Re: (Score:2)
It's what layered security is for, sounds like yours is working if you use VPN tunneling over your Wifi...
It's still good to fix that bad layer before something else fails though.
Re: (Score:2)
It's not a single attack vector. There are multiple CVE's for this. Some attack vectors do involve the AP, most involve the client. Both should be patched.
Re:How serious is this? How exploitable is it? (Score:5, Informative)
Need to build a device with the special software and come within range of a router to sniff the keys. Then can eaves drop on communication between router and client.
It will take a day at least to build it and then one has to come physically close.
Vulnerable places will be coffee shops, malls, airports etc. Stores that use wi-fi between cash registers and router would be the primary target. BTW Target had security cameras and cash registers talking to the same router using same passwords. If I remember it correctly.
Re:How serious is this? How exploitable is it? (Score:5, Informative)
Note that I would *hope* point of sale equipment and security equipment would use TLS regardless of the media. If that were the case, then the WPA2 weakness would not suddenly provide access to that material.
For a private laptop connecting to public wifi-hotspots, this attack is harder than just setting up another credible wifi hotspot. Any place where the wifi password is well known knowledge is never going to be rigorous security.
Re: (Score:3)
For a private laptop connecting to public wifi-hotspots, this attack is harder than just setting up another credible wifi hotspot. Any place where the wifi password is well known knowledge is never going to be rigorous security.
The attack doesn't rely on knowing or compromising the password or securing the network at all. What happens is an attacker sets up "CafeNetwork" on a different channel than "CafeNetwork". A device can connect to rogue "CafeNetwork" assuming it is the real one. As a MITM attack, the rogue network can listen in on traffic. If the traffic was previously encrypted with HTTPS, it provides some security but it is not foolproof.
Re: (Score:2)
That's my point, that this attack is only valuable if you don't know the PSK. In most public wifi locations, you know the PSK. (Simplified to speak only to WPA-PSK).
So the juicy targets would mostly be home networks and corporate wireless that laptops get on. Practically speaking though it would be much easier for PoS to reliably be secure regardless of the user, they probably send credit cards through telnet or some crap.
Re: (Score:2)
Note that I would *hope* point of sale equipment and security equipment would use TLS regardless of the media.
If a server on a LAN doesn't have its own FQDN, what certificate would its TLS use? Well-known CAs require a FQDN.
Re: (Score:2)
Disclaimer, I *hope* but realistically these things may be lax.
TLS on private networks is a well known entitiy. The usual flow is using an extra CA to validate the certs that has no meaning outside that private network.
Re: (Score:3)
Many bar and restaurants have wireless card readers which use wi-fi.
Re: (Score:2)
and card data is never supposed to be transmitted in clear text, or they fail PCI DSS
Re: (Score:3)
Of course, I bothered to look at at least one version of the PCI DSS spec:
This means all CDE data must be encrypted as suggested in PCI DSS
Requirement 4.1. Section 4.4 described Layer 2 specific wireless encryption protocols such as
AES that is used within WPA2 to provide confidentiality and integrity at the wireless link layer.
Higher layer encryption methods such as SSL/TLS and IPSEC and could be used to provide endto-end
cryptographic protection of card-holder data.
So it *looks* like it may have considered WPA-2 built in encryption sufficient, but 'recommended' TLS/IPSEC.... So contrary to common sense there could be implementations with weakness...
Re:How serious is this? How exploitable is it? (Score:5, Insightful)
The lesson here may be to use the ethernet connection on your laptop when possible for sensitive data use until its WPA2 software is updated. Oh, wait, most new laptops and certainly phones don't come with ethernet connectors and would require a dongle. Ah, the wonderful advances brought to us by ultra thin, lightweight portable computing.
Re: (Score:2)
Re: (Score:3)
If it's not your wifi, it's not secure.
To be honest, I don't get this. Who cares if a network operator, or the person sitting next to you at a cafe next to you is snooping your data? With the advent of https everywhere, the data between my computer and the server is encrypted and secure, regardless of whether the underlying transport is compromised.
You always need to consider that the underlying network is insecure. I'll happily do my banking over public wifi, or satellite internet (where the packets are broadcast to the entire continent), becau
There is no TLS CA for DNS-SD (Score:2)
How would you go about encrypting communication between a browser on your desktop, laptop, tablet, or smartphone, and a web-based management interface on your router, printer, or network attached storage (NAS) device? These servers tend to lack a fully qualified domain name (FQDN), making them ineligible for a certificate from a major certificate authority (CA).
tl;dr: There is no TLS CA for DNS-SD.
Re: (Score:2)
If it's not your wifi, it's not secure. That should be a mantra for everyone.
Why would I trust "my" wifi either? There's too many devices in the house, some of which are unpatchable by everyone other than the vendor (ie, no patches, ever).
But that's not a concern: if you are already prepared for anyone outside trying to hijack your connection, the first hop is not any different.
Re:How serious is this? How exploitable is it? (Score:5, Insightful)
The security industry would define this as a remote exploit as it does not require physical access to any of the devices nor does it require the attacker to be logged into the target devices. While the attack would result in decrypting any clear text being sent over wifi, the saving grace is that an increasing amount of traffic is sent via HTTPS or SSL, which would provide an additional barrier to an attacker seeing login credentials for remote websites, etc.
The most dramatic concern here is that non-HTTPS traffic is prone to injection of malware and exploitation of vulnerabilities on the client devices. Even if a user doesn't browse a sketchy website, suddenly a site like slashdot.org might seem to send code to a user's phone or laptop that could perform a remote code exploit.
As 140Mandak suggests, it would be trivial to assemble a cheap box (think raspberry pi 3) that sits at a public wifi location and automatically attempts to hack all older Android phones that connect to the network.
Re: (Score:2)
Couldn't somebody do that with any public wifi network as soon as they get the password? I mean, this will make it harder for the wifi provider to shut the malware server down as changing passwords won't work, but it still only allows access to join the network.
Re: (Score:2)
Can anyone shed any light on how serious this actually is? How easy is it to exploit this?
I don't want some theoretical answer, either. I want to know in very practical terms.
Is this as bad as the "Shellshock" bash bug [wikipedia.org] and the "Heartbleed" OpenSSL bug [wikipedia.org] were, where systems were being compromised within hours of these bugs becoming widely known?
From the disclosure:
When a client joins a network, it executes the 4-way handshake to negotiate a fresh encryption key. It will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged. The same technique can also be used to attack the group key, PeerKey, TDLS, and fast BSS transition handshake.
Going back to WEP (Score:5, Funny)
Re: (Score:3)
Aircrack, which is pretty popular, can hack WEP in a few minutes.
Re: (Score:3)
Re: (Score:3)
For cracking WEP, all you need is to capture enough traffic. If the network isn't busy enough, replay ARP requests.
I'm saying the folks who are claiming it can *always* be done or suggest that it's super easy haven't actually tried it.
And I'm saying they folks who claim what you claim don't understand the attack in question and hence failed to pull it off.
Re: (Score:2)
Pretty sure they were making a joke, Admiral Aspergers.
Re: (Score:2)
Except that all WIFI hotspots announce that they have WEP or WPA2 so people would immediately know you're an easy target.
Internet of Things (Score:5, Insightful)
So which is it? (Score:5, Informative)
WPA2 enterprise doesn't use a pre-shared key. So which is it? Does the weakness lie with pre-shared key passwords? Or something else which also affects WPA2 enterprise?
Ah, here we go. The answer is "it's complicated." I'm reading through it right now, but as a PSA:
In the future can we link to original source articles or responses by authoritative organizations, instead of trade rags?
Re: (Score:2)
WPA2 enterprise doesn't use a pre-shared key. So which is it? Does the weakness lie with pre-shared key passwords? Or something else which also affects WPA2 enterprise?
The flaw has nothing to do with passwords or pre-shared keys. All WPA2 devices are affected because the flaw is in the WPA2 protocol.
Ah, here we go. The answer is "it's complicated." I'm reading through it right now, but as a PSA:
Because some of those links don't give you the overall summary but delves into details. As a security researcher you would might find those links useful. As a regular person, it doesn't help you understand the fundamentals like: Who is affected? Everyone using WPA2. Everyone.
Re:So which is it? (Score:4, Insightful)
Care to explain or are you using the opportunity to prove your account name?
Coming from an AC, that is ironic. How about: YOU FIRST.
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
TLDR; Replay packet 3 (Score:5, Informative)
Replay packet 3 in the 4 way handshake, and the client will encrypt two different payloads with the same key and nonce. A big mistake with most encryption methods.
Worse, linux wpa_supplicant nulls out the key memory but still processes the replayed packet, causing the client to use a known (zero) key.
Very cool paper (but something curious) (Score:2)
I wonder about an almost off-hand remark in section 6.2.
"6.2 Example Attack Scenarios
Among other things, our key reinstallation attacks allow an adversary to decrypt a TCP packet, learn the sequence number, and hijack the TCP stream to inject arbitrary data [37]"
This implies that a "read only" (decrypt only) attack allows attacker to hijack the TCP stream. Can someone with better understanding of the issue explain this point? How can TCP connection be hijacked/modified if attacker has no ability to insert
Re: (Score:2)
I suppose that *if*: you were snooping a network you could also spoof ip for without being in the middle, you could knock the legit user off the network and assume their identity to continue the tcp session as you spoof them.
Though in that scenario, I'd imagine it easier to just set up a fake hotspot that looks legitimate ,since that generally would be the case in say a public wifi spot. Also, not sure how many things in this day and age that are remotely sensitive would trust mere ability to continue a TC
Re: (Score:2)
The reason this is big news is because 'security' auditors love wifi: it's an easy way to attack the system, and even if they're too incompetent to find any other vulnerabilities, they can still 'prove' to the CxO team that they've found a vulnerability and made the
Re: (Score:2)
Re: (Score:2)
Interesting FAQ, but has nothing related to my specific question, unfortunately.
Re: (Score:2)
From the FAQ:
Q: What is the impact?
A: When used successfully against WPA2 with AES-CCMP (the default mode of operation for most Wi-Fi networks), an attacker can decrypt and replay packets in one direction of communication (from client to AP), but cannot forge packets and inject them into the network. When used against WPA-TKIP – an encryption scheme that already suffers from serious security weaknesses and is not recommended for use – an attacker can decrypt, replay, and forge packets
What about if using RADIUS? (Score:2)
Would it not be possible to prevent by setting up a RADIUS server?
And then, smart people never trusted WPA2 (Score:2)
Seriously, the whole design process of WIFI "security" is almost as badly broken as that of mobile phone security. Anybody sane tunnels over these connections, using a VPN or SSH, or the like for anything critical.
And for all those confused: No, this is not HTTP security, i.e. SSL or TLS on TCP-Level (ISO/OSI Leyer 4), this is link-level security for the WIFI connection, i.e. below IP layer but above hardware (ISO/OSI layer 2).
Debian fix? (Score:2)
Luckily my LMDE distro got a new wpa_supplicant this morning, I think this is to fix this, if yes, this is great!
Fix released for Linux (Score:3)
A fix was just released for Linux (e.g. Ubuntu [ubuntu.com] and derivatives).
The phones and tablets will be the hard part here.
Lucky me!!! (Score:3)
I have one of the TimeWarner (now Spectrum) wifi modems. The thing will barely reach across my apartment, so I'm safe.
Re: (Score:2)
Re: (Score:3)
P.S. The user authentication page does submit the user credentials via HTTPS: https://secure.zdnet.com/user/... [zdnet.com]
Re: (Score:3)
Well I have an ISP that likes to inject stuff into unencrypted connections is that not reason enough to prefer https sites?
Re: (Score:2)
Reading comprehension? Do you have it?
Re: (Score:2)
Not if the attacker was also able to man-in-the-middle attack you as well.
Re: (Score:2)
Maybe enable encryption in SMB? What you are still using SMB1, well more fool you then. It's 2017 the world has moved on.
Mario much? (Score:2)
What you are still using SMB1
People are still buying new NES-clone consoles to enjoy SMB1.
Re: (Score:2)
Not every networking protocol can be encapsulated in HTTPS ...
Exactly. I was going to mirror an above AC who said, "I'm surprised that this still needs saying on an allegedly technical forum", but he was implying HTTPS was all you needed (wrong).
... (just ask Active Directory)
OH FFS! That's one of the easiest ones to move to a secure protocol - LDAPS (it even has its own extra protocol version that adds the SSL/TLS, but can also upgrade an LDAP connection via TLSStart).
Plenty of traffic is sent in the clear, and those are all better examples than HTTP/HTTPS and LDAP/LDAPS.
SSL attacks generally req
Re: (Score:2)
Of course, strictly speaking LDAPS isn't over https. Of course it is over TLS which is the actual relevant part of the discussion (before someone goes off on insisting that LDAP needs to be over *http*).
Of course, it should be considered a grave problem if any sensitive data relies upon the security of the LAN, considering a large chunk of network access is over an untrusted hotspot (no, that WPA2-PSK in the store with a legit-looking captive portal or the passphrase on the wall, or really any internet con
Re: (Score:2)
Fnord fnord fnord!
Re: (Score:2)
Client side problem only? (Score:2)
That may be true, but it looks like a change to the WAP can prevent the attack too --- It would be good for someone like Apple to patch their router firmware as well as the clients. That way your macbook can be fairly safe regardless of where you connect it, and your unpatched IoT things strewn about the house can also be secure -- so long as they only connect to your patched router/WAP..
Re:MitM are not newsworthy (Score:4, Insightful)
Man In The Middle attacks are not newsworthy and should not be making the front page of Slashdot, these are the equivalent of anti-Trump garbage that floods #fakenews sources.
So a flaw that affects every single Wifi network isn't newsworthy? Repeat: Every single Wifi network. Facts don't matter then to you. From what I can tell not all vendors have supplied patches yet so most people are vulnerable as they are unpatched.
Re:MitM are not newsworthy (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
If the network is using TKIP there's a chance of content injection. AES-CCMP is safe from that, for now. More here [bfccomputing.com].
Re: (Score:2)
If the network is using TKIP there's a chance of content injection
No one does that.
Re: (Score:2)
Re: Looks like that CAT 5 is looking better every (Score:2)
Cat5 can do 1gbs, just not as far as cat6. Though last I looked into it cat6 was still an unofficial standard that guaranteed nothing.
Re: (Score:2)
Been hibernating a while? 6 and 6A have been ratified, 6e isn't a standard though.
Re: (Score:2)
What does this have to do with closed source code? In this case, the closed source implementations are less vulnerable than the open ones.
Re: (Score:2)
or you could join a GOOD network, with a BAD guy within range, able to receive your wifi packets.