Wednesday, November 10, 2010

PSK doesn't mean Public Shared Key

It's recently been suggested that free hot-spots should switch to WPA with a known passphrase to help protect against attacks like Fire Sheep, a clever tool which integrates sniffing auth credentials from the air with your browser.

Short version: This won't work.

Long version:

There's a bunch of ways this reasoning is flawed:

  1. 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.
  2. 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.
  3. [Edit] As pointed out by Zero_Chaos on IRC... "free" isn't even a valid PSK since it isn't at least 8 characters!
So what's the solution?

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:
  1. Every cert signed by that authority is accepted as a valid chain, and I can just go get one myself for $n
  2. 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"
Ultimately, sites will have to protect their users by forcing SSL logins, but even this is still vulnerable to an attack like MSF::AirPwn on the http page which redirects to https, which would allow the attacker to redirect the user at will - including to a proxy server with a self-signed certificate (or even just an iframe proxy) which leads back to the mutual trust problem.

I need a drink.  Again.