Larry Seltzer is the former editorial director of BYTE, Dark Reading, and Network Computing at UBM Tech and has spent over a decade consulting and writing on technology subjects, primarily in the area of security. Larry began his career as a Software Engineer at the now-defunct Desktop Software Corporation in Princeton, New Jersey, on the team that wrote the NPL 4GL query language.

By now, any sentient IT person knows the perils of open Wi-Fi. Those free connections in cafes and hotels don't encrypt network traffic, so others on the network can read your traffic and possibly hijack your sessions. But one of the main solutions to this problem has a hole in it that isn't widely appreciated.

Large sites like Twitter and Google have adopted SSL broadly in order to protect users on such networks. But for broader protection, many people use a virtual private network (VPN). Most people, if they use a VPN at all, use a corporate one. But there are public services as well, such as F-Secure's Freedome and Privax's HideMyAss. Your device connects with the VPN service's servers and establishes an encrypted tunnel for all your Internet traffic from the device to their servers. The service then proxies all your traffic to and from its destination.

It's a better solution than relying on SSL from websites for a number of reasons: with a VPN, all of the traffic from your device is encrypted, whether the site you are visiting has SSL or not. Even if the Wi-Fi access point to which you are connected is malicious, it can't see the traffic. Any party that is in a position to monitor your traffic can't even see the addresses and URLs of the sites with which you are communicating, something they can do with SSL over open Wi-Fi.

But there is a hole in this protection, and it happens at connect time. The VPN cannot connect until you connect to the Internet, but the VPN connection is not instantaneous. In many, perhaps most public Wi-Fi sites, your Wi-Fi hardware may connect automatically to the network, but you must open a browser to a "captive portal," which comes from the local router, and attempt to gain access to the Internet beyond. You may have to manually accept a TOS (Terms of Service) agreement first.

In this period before your VPN takes over, what might be exposed depends on what software you run. Do you use a POP3 or IMAP e-mail client? If they check automatically, that traffic is out in the clear for all to see, including potentially the login credentials. Other programs, like instant messaging client, may try to log on.

I tested this scenario at a Starbucks with Google Wi-Fi while running Wireshark. Thousands of packets went back and forth on the open network before the VPN attempted to connect. A quick scan of the list found nothing that looked dangerous, and in fact the software on my system used TLS 1.2 in almost all cases, which was quite a relief. But your configuration may be different from mine, and even if your software attempts to use HTTPS, it could be vulnerable to attacks like SSLStrip, which tricks the software into using open HTTP anyway.

This gap in coverage may only be a matter of seconds, but that's enough to expose valuable information like logon credentials. Try running a network monitoring tool like Microsoft's TCPView for Windows or Little Snitch for Mac before you establish your Internet connection and see what happens in those first few seconds. The information may be protected by encryption, but it can carry details about your system configuration that could be used to identify it—or provide clues for an attacker.

Even beyond this time gap, sometimes VPN connections go down. At least in the default configurations of most operating systems, the applications on the system will fail over to the open Wi-Fi connection. Don't blame just the public VPN vendors. The same problem is true of corporate VPNs, unless they go to the trouble of configuring the system around the problem.

So, how do you do that? Shaun Murphy, a founder of PrivateGiant (www.privategiant.com), which makes products to protect the security and privacy of online communications, suggests that you do it with a software firewall, either one that comes with your operating system or a third-party one:

The basic approach is to prevent all inbound and outbound connections on your public networks (or zones) with the exception of a browser that you use to connect to captive portals and such. That browser should be one you only use for this purpose and, perhaps, some lightweight browsing (certainly not email, social, or any other personally identifiable purpose.) Using that same firewall, set up a profile/zone for VPN traffic where inbound / outbound traffic are less restricted (I recommend blocking outbound connections by default and then adding in programs as needed, it's surprising how many programs call home... all the time.) The nice thing about this approach is your email client, primary web browser, and other applications you use will be useless unless you are actively connected to the VPN.

Sean Sullivan, security advisor at F-Secure, gave us the same advice with the useful addition that "...you'd want to launch the browser [for the captive portal] in 'safe mode' so the plugins are disabled." If you're a Firefox or Google Chrome user, then Internet Explorer and Safari should fit the bill. You've got them on the system anyway.

Configuring firewall software on your PC to block non-VPN traffic isn't all that easy. It varies across operating systems and products, and it may not even be possible in Windows 8.1. On Windows, here's a summary of what you'd need to do:

Connect to the VPN of your choice using the normal procedure for that product.

In the Network and Sharing Center in Control Panel, make sure the VPN connection is set as a Public network, and the home or public Wi-Fi network is set as Home or Office (Home is better). (In Windows 8 and later this can be problematic u nless the network connection is brand new, because Windows 8.x provides no user interface with which to change the location type—so the whole exercise may be impossible—unless you first delete and recreate all your network connections.)

Finally, i n the Windows Firewall in Control Panel go to the Advanced Settings. Create a rule to block all programs from connecting on Public networks. Then create a rule to allow both the VPN program and the browser you want to use for the captive portal to be allowed to connect on Public networks. You will need to set these rules both for inbound and outbound connections.

BolehVPN of Hong Kong has produced a more detailed set of instructions for using the Windows Firewall in Windows 7. On a Mac, you can achieve the same results with the aforementioned Little Snitch firewall. And Douglas Crawford at BestVPN.com has instructions for the Comodo Firewall on Windows, but says that he couldn't get the procedure to work on the standard Windows Firewall in Windows 8.1.

All in all, it's a fair amount of trouble to go through, and it's a configuration you'd only want on open Wi-Fi. If you work where there is secure WPA2 encryption on the Wi-Fi, then the VPN is probably not worth the overhead and the reduced network performance.

The real solution to this problem isn't hacking with firewalls, it's providing encryption by default in public Wi-Fi. This isn't done much now because that would mean supplying passwords, and the support overhead would just be too great for a cafe. The result is that we have an insecure situation with bad, but adequate, usability.

The Wi-Fi Alliance has had a solution for this problem nearly in place for years, called Passpoint. The Passpoint protocol was created to allow for Wi-Fi "roaming" by creating a way for access points to grant access by way of a third-party credential, such as your Google ID or your ISP account. When you connect to a public access point through Passpoint, it authenticates you and establishes a secure connection using WPA2-Enterprise, the gold standard in Wi-Fi security—instead of leaving your traffic unencrypted or visible on the shared wireless LAN.

The reason that you don't yet see Passpoint everywhere is that it requires the Wi-Fi provider—such as a consumer ISP, Google, or Boingo—to trust certain authentication providers and to advertise a list of them to connecting devices—the longer, the better. And users would need to configure Passpoint on their system to use one or more of their credentials when connecting to such a network. There hasn't been wide adoption of Passpoint yet—while it's been put to use in certain high-volume locations, such as many airports, it's still pretty uncommon.

The Wi-Fi Alliance now says that Passpoint is gaining traction in the enterprise as a way to handle BYOD. That's interesting if true, but it doesn't address the pain point of public Wi-Fi privacy. Passpoint has the potential to close the VPN data leakage window and make public Internet services far more secure. In its absence, there is no good solution.