[ambrop7]

Most people don't understand the WPA PSK security model and its insufficiency for anything but private networks where every device is trusted. When you give someone the PSK, you give them the capability to impersonate the access point.

That being said, is there any better solution for public networks? One where giving someone a password doesn't let them impersonate you. I'm not sure how good support for EAP-TLS is on common client devices. To actually make it secure the device would not only need to support it but also validate the AP's public key some way.

[eeZi]

> When you give someone the PSK, you give them the capability to impersonate the access point.

And to passively decrypt all network traffic.

[zobzu]

since theres no url associated any trusted ca-signed cert is valid (for example a cert from startssl).

if you use self signed that actually protects you since then the client complains. SOME clients pin the certs (thus you cant impersonate the AP even with a trusted CA-signed cert) but its still quite rare.

[ambrop7]

But in theory the same CA infrastructure as used for the web could be used. The SSID of the network would be interpreted as the "domain".

So if I try to connect to SSID example.com securely, I would verify that the AP can identify itself as example.com (based on the CA roots which I trust) - exactly the same way as a web browser would if I tried to connect to https://example.com.

Or is this already supported but nobody uses it?

[wiml]

I think there are a couple of things that would have to happen in order for that to work:

1, we would have to set up a global registry for SSIDs, like we have for domain names. (Otherwise, what's to keep someone else from using a colliding or misleading name and getting a certificate for it?) And even then you run into the problem that the CA infrastructure used for the web is pretty terrible.

2, clients would need some kind of policy database to know what kinds of traffic must go over a "secured" AP and what kinds, if any, can go over the local coffeeshop's or convention hotel's wifi.

And all of this to secure just one link of the communication— all the rest remain vulnerable. Really what we want is end-to-end encryption, not link-by-link encryption. If you have #2, for example, you could instead use that policy database to implement mandatory IPsec (or equivalent end-to-end encryption; MinimaLT if you prefer) for all sensitive traffic, and bingo, you're secure against whole classes of attack even when you are using unknown APs.