In part 1 I outlined the many problems caused by wifi login pages that hijack your browser ("captive portals") and how to improve things.

Today I want to discuss the sad state of having security in WIFI in most of the setups used today.

Almost all open WIFI networks are simply "in the clear." That means, however you got on, your traffic is readable by anybody, and can be interfered with as well, since random users near you can inject fake packets or pretend to be the access point. Any security you have on such a network depends on securing your outdoing connections. The most secure way to do this is to have a VPN (virtual private network) and many corporations run these and insist their employees use them. VPNs do several things:

• Encrypt your traffic
• Send all the traffic through the same proxy, so sniffers can't even see who else you are talking to
• Put you on the "inside" of corporate networks, behind firewalls. (This has its own risks.)

VPNs have downsides. They are hard to set up. If you are not using a corporate VPN, and want a decent one, you typically have to pay a 3rd party provider at least $50/year. If your VPN router is not in the same geographic region as you are, all your traffic is sent to somewhere remote first, adding latency and in some cases reducing bandwidth. Doing voice or video calls over a VPN can be quite impractical -- some VPNs are all TCP without the UDP needed for that, and extra latency is always a killer. Also, there is the risk your VPN provider could be snooping on you -- it actually can make it much easier to snoop on you (by tapping the outbound pipe of your VPN provider) than to follow you everywhere to tap where you are.

If you don't have a VPN, you want to try to use encrypted protocols for all you do. At a minimum, if you use POP/IMAP E-mail, it should be configured to only get and receive mail over TLS encrypted channels. In fact, my own IMAP server doesn't even accept connections in the clear to make sure nobody is tempted to use one. For your web traffic, use sites in https mode as much as possible, and use EFF's plugin https everywhere to make your browser switch to https wherever it can.

These are all good steps but are not enough. An ordinary user will end up doing lots of unencrypted traffic on the typical access point, open to all.

Encrypting the open WIFI

Some open wifis use encryption, and put the password on the wall on a sign. This is a modest step up, but the problem is that with WEP (which is horribly broken in general) and WPA (which is modestly broken) and even WPA2, another person who knows the shared password can still listen in on your traffic. It's easiest, by far, with WEP, but even WPA2 has vulnerabilities. Another user on the network can watch your login and learn your "private" session key. If you get on the network first, they can't see that key, but if they can send fake packets to make your computer believe it was kicked off the network, it will just quickly reconnect -- and let the attacker listen and learn your key. These systems were designed to protect you from strangers who don't know the password, and did not presume that random attackers could read a shared password off a cafe wall.

There is some value in putting a publicly known WPA2 password on the wall in an open network, it harder to crack than a wide-open network or WEP, but there is still a false sense of security.

Some hope can be found in the much more rarely used "WPA2 Enterprise" authentication method for WIFI. With WPA2-Enterprise, you provide both a userid and a password, and these are passed on to a special login server known as the RADIUS server. Normally the RADIUS server is its own computer, and not part of the wifi access point, so this is only used in larger networks. As the name suggests, typically enterprise networks. It's useful because you can have lots of access points all using the same RADIUS and login database, and in fact that can be the company's general login database that assigns more than just WIFI access permission.

Setting up a RADIUS server, even the popular FREERADIUS, is hard work and only rarely done. This is the only way to truly secure a WIFI link. This works because the RADIUS server uses public key cryptography, and has a certificate for its key. The RADIUS tells you its certificate and public key, and that lets the program on your computer (known as the supplicant) create an encrypted TLS channel with the RADIUS. A snooper can't decode your traffic. Then you get a private key for the session to use in your radio packets with the access point, and you are safe from sniffers. (Of course, your packets are decrypted at the AP and somebody with an ethernet tap can still listen and play games.)

It is, in theory, possible to create a RADIUS serer that would just let anybody log in with any userid and password, or one common shared one. In that case, you could have a secured network that lets anybody on.

While I have not confirmed this, there is one vulnerability here. As far as I can tell, unless laptop and phone users go to extra effort on their own supplicants, these supplicants do not verify the certificate of the RADIUS. They have a field where they can insist the RADIUS certificate include a specific certified domain name. If this test is not set, however, any RADIUS with any valid certificate from one of the trusted certificate authorities will work. As such, if I set up a fake AP with its own RADIUS server, you might well connect to my fake AP and start using the internet through me. (If I have used a self-signed cert you will get a warning, though they often don't do much good as they are common and people click through them.) If I am already on the local network (because it allows open access) I can be a fake AP to you and make you appear to be on the local network, but I am watching your traffic. Fortunately, as long as you don't allow the plaintext password authentication protocols, I can't learn your password from your attempt to login.

Does anybody have information that this attack would not work?

To fix this without too much UI, it's hard because SSIDs are not unique, and many networks might accidentally use the same one. So while we might ask certificates to verify the SSID, somebody else could legitimately ask for a cert to use that SSID. Combining with the MAC would help but MACs can also be forged, though that causes collisions.

The supplicant should probably display both the SSID and the certified domain name when it offers a new wireless network to connect to. When connecting, you would want to make sure that both made sense, though there could be ways to trick you -- many of the standard phishing tricks could apply. Once you confirm a domain name you need not confirm it again for that SSID. (You can't do the reverse association as there can be multiple domains all using the same SSID.)

On the plus side, the "I am a fake AP" attack requires the attacker to transmit, so there can be other tools looking out for attempts to use this attack. Indeed, it may make sense for any AP to try to notice anybody else pretending to be them who isn't supposed to. (In a typical network, there will be multiple legitimate APs with the same SSID but different MACs.)

Unfortunately, any attempt to connect to a random, unknown open access point is vulnerable to the attack of creating a different fake open access point. An attacker can pretend to offer you free wifi but really just want to listen in on your traffic, and it's very hard to prevent that. In addition, unless you trust the open WIFI provider completely, they can still be sniffing at your traffic once it gets to the AP -- or somebody who has tapped their wires can do it. Still wise to encrypt as much of your traffic as you can over all networks.

With that in mind, it might make sense if the next generation of WIFI had no unencrypted mode. Instead, the WIFI would broadcast an uncertified public key, and any association dialog with the AP would begin by using that key to generate a private shared key. No passwords or certs, but a secure radio connection. Yes, you might be tricked into connect to a malicious AP, and we can't easily stop that, but at least nobody else would be listening in!

Until we get that, we would still be decently off if open WIFIs were able to easily offer WPA2-Enterprise, accepting either any userid/password, of a shared one written on the wall, or a standard default like "guest" and "password" (or blank.) They could use a special SSID that said they were an open network so clients could know they could connect. It would be better than in-the-clear, WEP or even WPA.

The problem is there are barriers in the way of this. You need a cert from one of the official CAs who charge money. You would need a version of Freeradius that is trivial to set up. Perhaps even a tiny one that could run on an AP (that's a tall order.) You could use a remote hosted RADIUS if somebody were generous enough to run one for free, but it would offer the risk of login being blocked if that server is unreachable. Support for multiple redundant RADIUS servers in AP firmwares would help. But again, it has to be trivial to configure, and nothing with certificates seems to be that way. So it's a stopgap until we can have a zero-user-interface (ZUI) encrypted open wifi protocol.

Part three will talk about how to make it easy to connect to open WIFIs without a lot of UI.