[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.