Today, I’m offering you a challenge. Go out and find a public wifi network that offers encryption without making you log in. I dare you. Unfortunately, this endeavor is doomed to failure. WiFi as it exists today makes it virtually impossible to offer such a thing.
I find myself in the business of managing a reasonably-sized wifi deployment (about 80 access points over 19 buildings). I would really love to offer open encrypted wifi on this network, but I can’t.
What I want to provide is an HTTPS-like experience for my users that just works: an SSL layer that doesn’t care who you are, but still provides meaningful encryption for the last 50 meters where your traffic is moving through the air for anyone nearby to snoop.
I’m annoyed that so many encryption solutions are coupled to both authentication and authorization. These don’t need to be linked. You don’t have to log into an https site to get encrypted traffic, and you shouldn’t have to log into a wifi network to get encryption either.
My ideal scenario is that someday I’ll be able to install the same wildcard ssl certificate that we purchase for our web sites to each access point or at a controller, change a setting for an SSID to use this certificate for encryption, and as long the certificate is from a well-known/reputable vendor, user devices will just work.
I include guest devices in this category. I want someone — anyone, but especially our visiting admissions candidates — to be able to turn on their device for the first time and have the experience be easy: no capture, no guest registration, no prompt to agree to terms of service, just choose the SSID and they’re online.
Sure, I could use a shared key scenario and just publish the key, but that’s not the same thing. If anyone knows the key, anyone can decrypt the traffic. And this still requires an extra step to get online.
I honestly couldn’t care less about the authentication part of this. I don’t need to know right away that it was Jane Smith’s computer committing whatever nefarious deed. The immediate reaction to that kind of thing is the same regardless of the name of the person behind it. As long as I can target a MAC address or have reasonably static IP addresses (I do), I’m happy enough using a captive portal rule on a specific machine after the fact to identify a user for those times when enforcement issues come up. Our college-owned machines here do log user names all the time, so it’s just student-owned devices where this is necessary.
Sadly, I don’t believe this kind of wifi exists today. Certificate-based 802.1x comes close, but the need to install/configure devices with a supplicant breaks it. Even so, I would settle for 1x… if only I could count on it working. The truth is that too many devices, especially things like smart phones and game consoles, fail to have adequate support for this, and will fail to give users any information about why network association fails, or how to fix it. Personally, I place blame on the WiFi Alliance, certifying devices that don’t work for this feature as well as they should.
Currently, we’re working to provide two WiFi options: one that’s completely open (and I mean completely), and one that uses 1x and prompts for a user’s Active Directory login. Anyone can walk on campus and get online at a basic level. Really. I don’t care. Guest (and even neighbor) use is a drop in the bucket compared to what our regular students demand. But if a guest needs encryption, they’d better hope the site or service supports https. We encourage students to use the 1x SSID whenever they can, and try to educate them about the importance of encryption. Most don’t care, and choose the open network, but at least the option is open to them.