Usually I like to post about topics that are specific to the AIS audience — data center, cloud, CIO/CTO, IT security, etc.
This time, however, I’m posting about a topic that is specific to nearly everyone on the planet with a wireless device: public Wi-Fi security.
Think of this as a periodic “public service announcement” akin to being aware of who is in the vicinity when you are talking on a cell phone in a public place.
The article was written by Larry Seltzer in InformationWeek. Larry is the editorial director for BYTE, Dark Reading and Network Computing.
Emphasis in red added by me.
Brian Wood, VP Marketing
———-
Open Public Wi-Fi: How To Stay Safe
Using open public Wi-Fi networks is dangerous business; if you’re not careful, your communications are open to everyone else on the network. But there are ways to protect yourself.
If you have the option, you should use an encrypted network. In the alternative, if you use an open, unencrypted network, use a virtual private network to protect your communications. Failing even that, be sure to use only HTTPS sessions.
When you look at a list of available Wi-Fi networks, like the one nearby, there are basically two types: those that are encrypted (with the lock icon) and those that are unencrypted.
If you connect to an unencrypted network all of your traffic is open for all the world to see, unless you take other measures to encrypt it. On such a network, all users can see all other users’ traffic. Worse still, other users can hijack your session and communicate with the website you were on as if they were you, or redirect your computer to a site you didn’t intend to visit. These attacks, while not strictly new at the time, were made widely known by the release of Firesheep, which made it easy to do.
Even if you are forced to log in to a web page or check a box after you connect to an open network, your traffic is not being encrypted. The login merely controls your access outside the wireless gateway to the Internet.
There are three main encryption standards supported by the networks with the lock icon: WEP, WPA and WPA2. WEP is an old and broken protocol, easily cracked. WPA is strong, but WPA2 is the state of the art. A properly-implemented WPA2 network gives you protection strong enough for all but secret agent work.
But even more important, both WPA and WPA2 support session isolation. Other users on the network can’t see your traffic. For this reason it’s better to offer a WPA2-protected network and publicize the password, perhaps with a big sign on the wall, than to offer open Wi-Fi. Another possibility is to include the password in the SSID, such as “WiFi-pw-is-ChakaKhan.”
What if encrypted Wi-Fi isn’t available? Your best option is to use a VPN or Virtual Private Network.
Most users who have a VPN get access to it through their business, but there are private VPNs for individuals, too. Many are free or low cost. I use HMA! Pro VPN (HMA stands for Hide My Ass). It has a free web proxy and there are free VPNs, but I pay for the Pro version of HMA because I like the fact that it protects my entire network stream. Any application I use that communicates on the Internet uses strong encryption talking out to its network, at which point it is proxy-ed out to its final destination. The site I’m talking to doesn’t know who or what I am based on network traffic; it only sees HMA’s network, so I’m also anonymous to these other parties.
The other option you have on an otherwise open network is to make sure to use HTTPS websites only. When you use HTTPS, all communications are encrypted using TLS/SSL. Well, almost all. Sometimes a site will say HTTPS and you’ll get the lock icon, possibly even an EV-SSL site with the green address bar, but some elements on the page, such as some graphics, are transported on HTTP. This is an opening for an attacker.
Back when Firesheep came out, many large and popular websites like Facebook and Twitter offered HTTPS, but didn’t force it on users. Since then both have changed to switch the user to an HTTPS session if they attempt to connect to HTTP.
After Firesheep, a standard was also developed for web servers to force clients to interact with them only over HTTPS. HSTS (HTTP Strict Transport Security) is implemented through the HTTP header “Strict-Transport-Security,” but I can’t find any good numbers on how widely it is implemented. The Qualys SSL Server Test allows you to test an HTTPS server for many characteristics, including support for Strict Transport Security.
So you have many ways to ensure that when you are surfing in dangerous waters the sharks don’t see you. One day our systems will be built to default always to secure configurations, but we’re not there yet. We do know how we can protect ourselves and it’s our job to do it.
