Published on MacDevCenter (
 See this if you're having trouble printing code examples

Wireless Security on the Road Without a VPN

by 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!

Getting Ready

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Be Strong

Anything that you cannot secure should not be used during your travel. Why? Because any information can be used, whether it is against you or not. That family site login you do through HTTP (why enable SSL on such a site, right?), that XML-RPC posting interface for your blog, that special FeedBurner URL, all allow an attacker to learn something about you.

Forget about them, update them, do whatever you need to but do not assume that something is "unimportant." Open the service door and the entrance hall will get invaded, one way or the other -- many a castle was burned down that way in the Middle Ages.

Of course, sometimes, there is nothing to be done. Most applications, for example, will always contact their update servers over HTTP as part of their daily or weekly "phoning home" scheme. If you do not wish to block these connections with LittleSnitch (or disable the corresponding preference), systematically refuse any update that is offered to you while browsing on the untrusted network.

Make It a Snap

Of course, we all know that security exists. But being secure is a different matter. This is why it is important to make it easy for you to use these secure protocols: update your Mail configuration, update your browser bookmarks to point toward to the HTTPS URLs, and setup your weak email accounts to forward to stronger ones.

With the exception of public site browsing (such as the O'Reilly Network,,, etc.), no insecure URLs should subsist in your bookmarks or aggregator. It takes a while, of course, but it is worth it!

The idea here is to "port," so to speak, your entire computing routing into the secure area without changing your habits. Whatever cannot be secured needs either to be disabled during your travels or altered so that you can secure it somehow.

The most careful among us will want to keep two user accounts on their machines, each with a matching application selection in the dock. Others will simply want to remove their chat application, XML-RPC blog updater, etc. from their dock while traveling so as to avoid opening them by mistake.

Protect Yourself

Securing your communications with the outside won't do you much good if your computer and the servers you connect to are full of holes. In that light, be sure to secure your Mac properly (but prefer a more modern anti-virus solution to what is described in our 2004 article).

If some of the servers you connect to are yours, make sure they are up to date and patched. Remember that anyone who wants to can see what you are connecting to and even get a list automatically compiled on his machine. Hence, every time you make a connection to a server that looks interesting, so to speak, you are offering good target points to your neighbors on a silver platter. In circumstances like this, you often wish you hadn't named a server "" or "," since such names are the equivalent of leaving a cherry pie to cool down on the window ledge -- cartoon fanatics will understand.

Before leaving, it may be a good idea to rotate all your passwords too and make sure they would resist a brute force attack. Keychain Access' Password Assistant will help you greatly in that task. The same should be done once you come back. If someone gained access to some of your passwords, the good rotation at the end will help kick them out, unless, of course, the account they gained access to has administrative privileges. If that is the case, they could just use it to open an account of their own or, worse, a backdoor somewhere.

Mind the DNS

Although some may deem this precaution exaggerated, it cannot hurt to rely as little as possible on the DNS of the network you are connecting to. Indeed, it is not out of the realm of possibilities that someone would poison the network's DNS to redirect popular banking or auction sites to a destination of their own.

Of course, the use of authenticated protocols should raise an error or a warning, which you should read especially carefully when traveling. But what if something fails? What if the attack is particularly well executed and relies on a weakness within the legitimate site? For such attacks, using your own DNS server might help.

Some companies provide high-quality hardened recursive DNS services that may be worth looking into. Once subscribed, you usually need to keep your Mac pointed toward these DNS servers, which you do through the "Network" preference pane (the TCP/IP tab of your port configuration of choice, more precisely). Most such systems require that your computer sends an authenticated message to the servers first to ascertain that you can use the account you subscribed to, which, as long as no passwords are transmitted in the clear, should be reasonably safe.

If at all possible (and especially if using an updating mechanism as described above), try replacing URLs by IP addresses. For example, if you connect to your server through "," try replacing this line in your SFTP client with the IP address of that machine. The most reliable way to know the address is to ask the machine's administrator, although LittleSnitch and the Terminal's "dig" command should provide you with this information too.

When you are not traveling, a good recursive DNS service may considerably speed up your connections since most ISPs do not invest heavily in the DNS service they provide to their users.

Before returning to your wired network, quit all your web applications and enter lookupd -flushcache in your Terminal, which will clear your Mac's DNS cache, potentially leaving in the dust any incorrect entries it may have handled.


In most WiFi-enabled areas, you will see little signs inviting you to "just open your browser" or, worse, you may be tempted to go ahead and pick a plausible-sounding network in your AirPort menu at random. This, unfortunately, is the wireless equivalent of Russian Roulette since absolutely nothing guarantees your computer is using the right network. Even I can, on a whim, create a network called "T-Mobile", "Orange," or "O'Reilly's Free WiFi" wherever I go.

Hence, it is essential you rely as much on alternate means of authentication before connecting to the network for the first time. This is not always possible but there are a few simple ways to go about it.

First, ascertain the name of the network you need to connect to -- and once again, don't make any assumptions. Although someone could indeed create a rogue network with the same SSID (name) as the one of the legitimate network, it would require using antennas powerful enough to fool your computer into thinking their network provides a better signal than the genuine one. Doable, certainly, easy if someone wants to target you personally (they could rent the room next door) but then, if you are working for the Secret Service, you're probably not strolling around a hotel using their WiFi network.

What is one supposed to do? In some places, the name of the network will be written somewhere on a plaque or a sign. Most of the time however, you will have to locate the customer support phone number printed on whatever leaflet the hotel has given you or left in your room and ask the friendly attendant. Sounds silly? Well, it often helps avoiding mistakes and it doesn't cost much to place a 10 second call. Some companies operate under different names at different locations so, again, knowing the name of a network in one place doesn't mean you know what it is called in others.

Then there is the question of purchasing your access. Usually, you are instructed to login, let the provider's catch-all firewall block you, and instruct you to punch in your credit card number. Very convenient indeed -- to steal credit card numbers, that is. Instead, prefer purchasing a pass at the front desk or through the telephone. Also, pay cash if you can since your credit card number will not be kept on file. Then, should the catch-all fail to accept your login, this may well mean you have hit a fake login page but all your attacker will have in its possession are 90 minutes of wireless access.

Of course, this changes dramatically if your login is linked to an email service or offers personalized pages, in which case your attacker could gain access to those too. Another reason to not use an ISP's email servers.

Sure, one could create a successful man-in-the-middle attack by creating a fake login page then passing the login on to the real one and transparently routing your connections. This is why it is essential you make sure the page uses SSL -- here comes Opera again. Also, verify that it is a catch-all. If the leaflets left in the hotel room specify you should type "" to login, try entering something else like "" Yes, any pirate worth its salt could operate its own catch-all system but that is one extra step to go through and it is a lot more difficult than enabling web sharing and setting up a website that answers to the correct URL.

Final Thoughts

We have, in these few lines, brushed the surface of precautions that should be taken when using WiFi networks. These are inherently insecure and, unless you invest in a VPN, any attempt to turn them around will fail. However, you can make them more secure, perhaps even secure enough to work for you, at least from time to time.

All in all, the best advice I can give you is to be on the lookout. Social engineering with a dash of technology can be highly effective, especially on networks where the vast majority of users just do not care. Hence, a little thinking will go a long way, especially as you login.

When in doubt, think tarsier and snails. Oh, and have fun!

FJ de Kermadec is an author, stylist and entrepreneur in Paris, France.

Return to the Mac DevCenter.

Copyright © 2009 O'Reilly Media, Inc.