Muni Wi-Fi security – Part II
In a previous blog I wrote about security in municipal Wi-Fi networks and talked about what I called network identification. I wanted to talk a little more about that now. I think this is actually one of the hardest problems to deal with.
Just to recap, the problem is that when you attempt to connect to a wireless network, you do so based on the network name (the SSID). That name, however, is a very poor identifier. The administrator of the access point can name it whatever they like. So, if I want to setup an access point and name it "GoogleWi-Fi", I can. And now when anyone in range attempts to connect to a wireless network they will see one called "GoogleWi-Fi". So, how do you know who you're connecting to?
People have suggested a number of approaches. I've heard some suggestions around educating users about what names to expect. This only avoids accidently connecting to the wrong name and does nothing to prevent connecting to fraudulent access points with the *right* name. There's also been discussions that say we police the network names, perhaps using some kind of registry. Personally, I don't see this scaling very well or being very easy to enforce (not to mention questions about legality). Other approaches advocate using VPN technology so that it doesn't matter which access point you're using. My own experiences with VPNs make me think that this approach would be too difficult for the average user to deal with. Plus, I would still be uneasy communicating through a potentially malicious access point. Finally, some people have considered using real authentication technologies to enable the client (the laptops) to authenticate the access points. Technically, this is pretty sound but it runs into major problems in terms of deployment and maintainability.
Of course, details on what the various cities are going to rollout is still a bit scarce, so it's hard to know for sure how this will be handled. Google does have some information available. It doesn't really address the identification issue but does explain that their network is unencrypted and they recommend using a VPN or at least sending personal information only to encrypted sites. They also provide a VPN client that routes through them. So, there’s no great solution yet (although Symantec is currently developing some). For the moment, the best way to solve the identification problem is to learn to recognize the name of the network you’re using. It’s not perfect and it is vulnerable to deliberate spoofing, but it does prevent some things. There are other ways to limit risk, based on protecting the data you send across the network. I’ll talk about those more in my next post.