Short version: This won't work.
There's a bunch of ways this reasoning is flawed:
- WPA-PSK offers no validation of the access point other than the PSK.
What does this really mean? As soon as you give out the PSK, you've got zero protection from "evil twin" impersonation attacks.
When you are the AP, you already know all the magic. The traffic is decrypted and shows up on a local interface. Sure, this makes running Firesheep marginally more difficult, since it requires setting up an AP, but... it's not all that more difficult.
It does require the attacker take an active role.
- Slightly more esoteric, but fundamentally the same: The PSK is meant to be private.
When the PSK is known, the PMK (Primary Master Key) is known. When the PMK is known, the PTK (Temporal Key, which actually encryptes the users traffic) can be snooped, and when the PTK is known, the traffic can be decoded directly, yielding the same problem.
- [Edit] As pointed out by Zero_Chaos on IRC... "free" isn't even a valid PSK since it isn't at least 8 characters!
I don't know. We have no (current) mechanism of mutual authentication with the access point which precludes users subverting themselves.
WPA-EAP? Sounds good, you get per user keys where the exchange is encrypted via TLS, so even using the same user/password doesn't lead to snoopable keys...
Except we need to protect the radius exchange with a SSL certificate. How many users (who we have already established don't know how to use https) are going to be able to authenticate a certificate fingerprint?
"Ah" you say, "I'll just use a cert signed by a public certificate authority". Sure. And then either:
- Every cert signed by that authority is accepted as a valid chain, and I can just go get one myself for $n
- The user is prompted to accept this specific certificate, leading right back to the same problem with "can a user be expected to validate a certificate themselves"
I need a drink. Again.