Wireless Security on the Road Without a VPNby FJ de Kermadec
A few days ago I was visiting Lyon, a rather large, lively city in the south of France. Among its many enjoyable traits, Lyon features a long tradition of hospitality and cuisine, making it a premier destination for conscious travelers. It so happened that I had been invited to a rather nice hotel on business -- the kind of hotel where an army of impeccably groomed staff attends to you and fresh flowers seem to bloom everywhere you turn.
Unfortunately for me, this hotel is set in a historical building and, hence, cannot really afford to drill holes in every room and run CAT6 cable. In other words, it is WiFi or nothing, something proudly mentioned on an avant-garde orange card sitting on the desk next to the services directory.
WiFi is a wonderful technology in many regards, providing high-speed, cost-efficient, and still relatively reliable networking without the need for expansive or expensive remodeling works. Unfortunately, because of its very nature and its need to broadcast everything at large (you cannot "draw a line" between your computer and the access point like you would pull a cable in the air), WiFi is also a highly insecure means of connecting to a network. That is, of course, unless you apply proper encryption and authentication to your network, which public access points almost never do, out of a mix of cost-consciousness, technical uncertainties, and good old lack of care.
What, then is a traveler to do? In most cases, a security professional would recommend using a VPN, a sort of all-encompassing, encrypted tunnel that "cuts through" the network, so to speak, providing you with encryption and authentication, even over the weakest of links. If you have ever been to a computer conference, you have probably seen people run around with little chips displaying blinking numbers: these are part of a complex but common system that allows access to corporate VPNs.
A properly configured VPN without doubt provides its users with a level of security that would be otherwise extremely difficult, if not impossible, to attain. In fact, most companies sending executives on the road now impose the use of a VPN to connect to the corporate network from the outside (e.g., hotel rooms and coffee shops).
There is only one problem with VPNs and it is a rather big one: although relatively easy to use on the client side, VPNs can be a headache to setup and configure. This leaves most users with two choices: purchasing special equipment at a relatively high price or hiring a third-party commercial service that provides them with what we will call a "VPN server." Indeed, a poorly configured VPN can actually facilitate intrusions in a network and leak data, making relying on DIY open source solutions something of a challenge for the non-technically inclined.
Hence the big question: what is a user supposed to do when he finds himself on a public wireless network, wishes to maintain proper security and doesn't have the time, money, or will to invest in a VPN solution? Impossible I hear you say? Not really!
As usual, the first step is to get ready for the travel. Although you certainly could do all that on location, it is never advisable to plan at the last minute, especially when one deals with a lone laptop on the road. Those of you who travel frequently may have learnt this the hard way -- I know I did.
Also, security is an ongoing process that is challenged with each update, meaning you need to get into a "secure mindset" progressively. There is no way to apply a coat of attack-proof varnish hoping it will solve problems; corporate firewalls around the world are a prime example of that fact. That would be the virtual equivalent of putting icing on a sponge cake hoping to turn it into a brownie.
Anything That Goes Out...
...needs to be detected and listed. Unfortunately, with the great many ways and great many reasons that exist for establishing a connection to the Internet, pinpointing what exactly makes use of your Internet connection might prove difficult.
Luckily for us, the good people at Objective Development (Obdev for friends) have provided the Mac community with an excellent tool, Little Snitch, a kind of reverse firewall that notifies you of all outgoing connections. The first thing here will be to install Little Snitch or another similar application and to put your computer through its paces for a bit. Every time a window pops up notifying you of an outgoing connection, write down the application, server, and protocol. You may then dismiss the window "For ever" but be sure to only use the "Same server and same port" option when doing so, lest you want to skew the results of this experiment.
After a few days, and provided you have gone around your entire installation, it is relatively safe to assume you will have a good overview of which applications and operating system components make use of the network and which do not. This is where you will want to take your list and separate it in two columns: those that use secure protocols and those that do not.
What do we mean by secure protocols? Protocols that provide both encryption and authentication, preventing malicious users on a network from reading the content of your transactions and providing you with the warranty you are connecting to the right server on the other end. A malicious network can be reconfigured to trick you into thinking you are connected to a legitimate machine but actually direct you to a rogue server.
Such protocols are HTTPS, SSH, POPS/IMAPS, SMTPS, and SFTP -- lots of "s" for "secure." Indeed, insecure protocols include HTTP, POP/IMAP, SMTP, and FTP. Since Little Snitch always tells you which protocol is used (at least when it can tell), that distinction should be relatively easy to make.
...Needs to be Secured
With your list in hand, discard the secure column. Anything that is already encrypted and authenticated shall provide you with reasonable security over a public network. However, there are four points to consider:
- Any content that is served as "partially encrypted" (indeed, such as the Mac login page) shall be considered as insecure, since the non-encrypted, non-authenticated part of the transfer could be used to launch an attack.
- Any content that is served with a weak encryption should be regarded as non-secure. How do you know? Many browsers nowadays will tell you, including the latest version of Opera, which has an unparalleled ability to sniff out weakly protected sites (to the point of sometimes being a bit annoying). Just load your usual pages in it to ascertain their situation.
- Be very wary of applications that switch from encrypted to non-encrypted transactions (or the reverse). iChat, for example, might send your password in an encrypted fashion but will then send your chat in the clear. Encrypted chats will start in an unencrypted fashion before being encrypted in a second time. In most cases, this is a Very Dangerous Thing, unless perfectly implemented -- and we will never know.
- A very Web 2.0 thing to do is to hand out special URLs instead of passwords, betting on the fact nobody will be able to guess the URL. This is as bad as passing a password in a URL, as our Web 1.0 founding fathers used to do. Remember: the URL to an encrypted page is, itself, not encrypted unless you use a VPN or an SSH tunnel. As such, these URLs should be discarded and this includes those in your RSS aggregator!
Should you notice that you still rely on insecure protocols to connect to your servers or check your emails, it is essential you switch to their secure versions right now. Yes, right now. That means no POP, no IMAP, no non-authenticated SMTP (outgoing) servers, and no HTTP logins. Never. The reasons for this are easy to understand: insecure protocols transmit your password in the clear, a password which, in turn, allows users to use your accounts, impersonate you, and potentially gain access to your data. Most providers now offer secure alternatives to these aging protocols and some even insist on them: ask them if you are in doubt and leave them in the dust if they say "This isn't much of a concern to our users." Such answers are unacceptable on the Internet of today.
Pages: 1, 2