Friday, December 27, 2013

23 -- Movie Subtitles

Movie subtitles on a computer security blog? Yes. Because it's my favorite hacker movie, it has only been published in German(y), and I wanted to share it with my English-speaking friends.

The movie is called 23 -- Nichts ist so wie es scheint. (Nothing is the way it appears to be.) Directed by Hans-Christian Schmid, it is based on the KGB Hack that originated in Germany in the 1980s. It tells the story from the view of one of the German hackers involved, Karl Koch. Non-German security geeks might be more familiar with Clifford Stoll's book The Cuckoo's Egg, which describes how Cliff, based in the US, pioneered some computer forensics techniques to contribute to tracking the hackers down.

I started looking for English subtitles on the Interwebs and found some here. (This page also has some great background and trivia for the movie.) I decided to make a pass through them and improve the translations a bit -- some of them had a very heavy German accent. ;-) I tried to contribute the update back to the source of the subtitles, but never got a response. To get this project off my to-do list I have finally decided to just make them available as a download myself. They still aren't perfect, but I believe they are good enough to follow and enjoy the plot. Enjoy:

The subtitles are for the DVD of the movie. Many common software players can render them for you from the ASCII file while playing the DVD. And no, I won't be able to help you with obtaining a copy of the movie itself. ;-)

Tuesday, November 12, 2013

Preparing for the Loss of Your iOS Device

Imagine you lost your wallet, or even worse, you are pretty sure it has been stolen. Are you able to remember which credit cards were in it and how to revoke them? Other credentials? Your AAA card, drivers license, ... Maybe an access card for work, etc.? Probably you can scrape those bits and pieces together. Now try the same thought experiment for your smartphone.

Imagine somebody stole your smartphone or tablet. Which apps are on your it that are linked to online services you are signed up for, and that you should really reset your password for now? iCloud, Dropbox, eBay, Facebook, Google, Skype, Twitter, your bank accounts, your airline accounts, ... I counted over 150 apps on my phone the other day, linked to 69 unique accounts.

Sure, you hopefully had a PIN or passcode (or fingerprint ;-)) set to protect access to the apps and data on your phone. And it only took you an hour to realize that it was stolen and to attempt using Apple's remote wipe functionality. But depending on the thieves' determination, those things won't stop them. There are forensic tools out there to circumvent them, or maybe your PIN is easy to guess. The iPhone 5S's fingerprint usability feature was "broken" days after the phone hit the market.

My point is that I personally wouldn't want to rely on just the access protection that my phone offers. If I lost my phone, I would probably want to go ahead and change passwords for my most important accounts, or even all of them. And I'd rather have a list handy of what those accounts are, rather than trying to piece them all together from memory. And what about data that is stored on your phone? Do you have a backup for it? Might be worth thinking about that ahead of time.

Your mileage may vary, obviously. Everybody's risk profile and appetite is different (see Threat Modeling at the end of this blog entry). But if you feel like spending an evening geeking out on preparing for that eventuality, read on...

Threat Modeling
So what threats are we preparing ourselves for by going through this exercise?
  1. An attacker obtains your smart device with an interest that goes beyond just reselling it on the black market or eBay. The bad guy is somehow able to circumvent the access protection that is provided by the device, and then:
    1. Uses your social media apps to post damaging statements on your behalf; or maybe, to collect your or your friends' personal information in order to facilitate sophisticated social engineering attacks or identity theft. Or maybe just use the data in your calendar...
    2. Uses passwords (or credit card numbers!) found in the cache of poorly written apps to log into your bank or whatever accounts and wreak havoc (or go shopping ;-)).
    3. Uses second factor authentication credentials generated by your Google Authenticator (or similar) app on the phone to access accounts that the attacker already obtained the password for through other means. Maybe you accessed your email on an Internet cafe computer that had a key logger installed?
    4. Use the VPN credentials on your phone to remotely connect into your employer's network and access corporate data.
  2. Your device is lost/broken/stolen. It has data stored on it that you need. You thought for sure it was backed up somehow, but it wasn't.
How likely any of this is to happen and how big the consequences of it would be for you is for you to determine. (Let me just say that none of this is impossible or unheard of.) As a result, you might decide to take some of the precautions we discuss above, or decide that you don't have anything to worry about. ;-)

Making an App Inventory
I suggest creating an inventory of the apps that are on your device, what kind of data they store, which online service they are linked to, etc. You could just jot something down on a piece of paper. Or you could use this handy spreadsheet template I made for you [Excel Template | CSV].

App Inventory Spreadsheet
Here are instructions for the individual columns in the spreadsheet. I also pre-populated the template with some common apps as examples:
  • App: The name of the app, obviously. How to best get a complete list of the apps on your device? For iOS, the best approach I could figure out is to either access the device information in iTunes (the Apps tab lists all apps installed on the device), or to use iExplorer and explore the apps folder on the device.*
  • Critical Data: Make a note here if the app stores data that might either a) be sensitive, in the sense of an attacker being able to exploit it and cause damage with it (credit card numbers? bank statements? your company's trade secrets?), or b) cause you distress in case you loose it and won't be able to recover it.
  • Password / Associated Service?: If the app uses a password or passphrase, write down the name of the service the password is associated with. (Don't write down the password itself. I am assuming here -- and you can use the spreadsheet as an aid to double-check -- that some sort of password manager is used to keep track of the passwords, for example LastPass. The primary purpose for this entry is to help us identify the online services that we will want to change our passwords for if we loose the device.)
    • There will be some dupes in this column: For example, Google Drive and Google Mail both use your Google password.
    • There may be apps that are authenticated to more than one service. For example, you may have authorized your favorite News app to post on your behalf to Facebook and Twitter. List both.
    • In rare cases in today's connected world, there might also be an app that does not connect to any online service and still requires a password for access to its data on the device. Maybe your password manager?
    • Application-specific passwords: If you happen to remember that you didn't just enter user name and password for whatever service into an app, but instead used an application-specific password or a service's authorization mechanism to authorize the app, then make a note on that. It's not too important, but if you manage to read through the rest of this blog post, you will understand why it helps.
  • Crypto Keys?: There may be some apps that use cryptographic keys for authentication rather than (or in addition to) passwords. If the device gets compromised, we will want to change those keys, and thus list them here. Examples are "certificates" (and their associated private keys) for VPN connections, or apps that connect to Amazon cloud storage using an AWS Access Key. If you don't know, then leave it blank, maybe?
  • 2nd Factor (Type)?: Some services offer two-factor authentication these days, which you have hopefully enabled if they do. If so, list the type of second factor being used, or rather the service that provides the second factor. A popular example is Google Authenticator, or RSA hardware tokens. Apple also offers two-factor authentication for your Apple ID (enable it here), which is associated with the Find My iPhone service...
  • Credential Priority?: How important is it to change the password / revoke the crypto material if your device gets compromised? For example, I'd want to focus on changing passwords for services like Google and my bank accounts first, before dealing with photo sharing or fitness tracking websites. I suggest sticking to two categories, maybe "high" and "low"?
  • Data Backup?: This entry helps you think about whether you have a backup for any of the critical data you don't want to loose. Turns out that in my case, there were only a handful of things that weren't automatically synchronized with some sort of online service. And most of those that weren't I don't care too much about. But one or two I was glad I caught.
  • 2nd Factor Backup?: This is an interesting one. It is supposed to help you think about whether you've got a backup for when you loose your soft or hard token for two-factor authentication. I discuss this in detail further down in this post. Maybe fill this column out last. ;-) 
  • Notes: Any notes you want to keep. :)
*There are a few apps that you won't catch by doing this, namely the ones that are included with iOS, rather than installed through the App Store. This includes Contacts, Messages, Mail, etc. Most of these use your Apple ID for authentication. But there are some exceptions: iOS integrates several social networking accounts into its core without a separate app having to be present. Namely, as of iOS 7.0.3, those are Facebook, Flickr, Twitter, and Vimeo. (Those can be found in the iOS Settings, scroll down a few pages. If you don't use the service-proprietary, say, Facebook app, but are logged into Facebook through iOS, then capture this somehow in the spreadsheet to remind you to change your Facebook password if the device gets lost.)

You may want to update this spreadsheet occasionally with new apps that you installed. One way to keep track of that might be to access the purchase history for your Apple ID in iTunes. If anybody has a better way of doing this, please post a comment!

Other Things To Take Into Account
Now that we know which passwords we will want to change if we loose our device, and we have thought about whether our data is backed up somewhere off-device, let's consider a couple additional things:

Credit Card Numbers
Some apps store your credit card number on your device. They shouldn't, it's bad architecture for almost any use case. But if they do, they might be coded sloppily enough as well to not encrypt it in any sensible fashion, either. If our device thief manages to access the device's file system, he or she might find those numbers.

I am personally not to worried about credit card numbers, in particular if it's not a business card (which are not covered by consumer protection laws in the US). But if you are, and this thought sounds concerning to you, then having a separate card for use with your device might be a good idea. That way, you just have to monitor/cancel that one card if you suspect that your device might have been compromised.

Password Managers
These days, the security community has widely accepted that dealing with the industry headache that is password-based authentication in a way that allows us to use passwords that are hard to crack, and use different passwords for different services, exceeds the capabilities of a human's memory by far. Paper doesn't seem to be a great solution. So we use password managers. All of our passwords in one and the same database. Scary.

There are different architectures for password managers. Some store just local copies of your passwords. Maybe on the device you are about to loose? Others can sync between mobile devices and PCs. Yet others, like LastPass, store an encrypted master database with your passwords on their servers, and allow you to access it and decrypt it from various devices.

Whatever type you use, make sure the only copy of your password manager's database isn't located on a device that you might loose. Keep backups. Use a very strong passphrase and pray that its encryption is implemented properly. If you use a password that can be guessed (there are sophisticated tools to automate this), it might have disastrous consequences.

Keychain'ed Data
Similar to those password managers above, iOS implements a data store for sensitive data. One thing that our inventory above does not take into account is the data stored in the keychain. When Safari, for example, asks you whether it should remember the password for a website you are visiting, or the credit card number you entered on a web page, then this ends up in the keychain.

It depends on your paranoia whether you want to rely on the protections for the keychain that Apple has implemented, or not. If your keychain is not synchronized with another device, it might be time to think about how to inventory its content as well, so that you can make sure you have a backup of those passwords somewhere. (How to do this for Safari auto-fill information is described here. For content that other apps store in the iOS keychain, I'm not aware of a user-friendly way to do this -- not all apps support keychain syncing with OS X, where Apple supplies an app to browse keychain content.)

Two-Factor Authentication
Of the dozen-or-so apps on my phone that support two-factor authentication (see the 2nd Factor spreadsheet entry above), all but one either use an app on my phone (like Google Authenticator) or my phone number (by sending text messages) to communicate that second factor to me. If I don't have access to my phone, I won't be able to derive that second factor from it. 

Pretty much all of those services, though, offer a backup for that case. Often, that involves printing out some backup or recovery codes that can only be used once, and storing them someplace that you will be able to find (and access) them at when you need them years later. This can take some time to figure out, but may save you some headaches if you ever end up in that situation.

What To Do When You Loose Your iDevice?
Well, let's assume you are sure it's lost or stolen. When, exactly, you pull the trigger on assuming that it might have fallen into the hands of a bad guy rather than just sitting underneath a pillow on your couch depends, again, on your personal risk management. But hopefully all that preparation we went through above won't let you hesitate just because you don't have a plan on how to recover from the loss of your device.

Attempt to locate (and potentially remotely wipe) the device.
This may or may not work. The device obviously needs to be online for this, and still be associated with your Apple ID. Go to the iCloud web interface to give it a shot. All this assumes that you have set up FindMyiPhone in the first place.

Notify your employer.
If you use your personal device to access your organization's data, for example the corporate calendar and mail, or other resources through a VPN connection, let them know. Don't wait with this. Any organization that is serious about their security management will appreciate you letting them go through the effort of revoking your remote access and activating whatever other procedures they may have rather sooner than later, also if it turns out later that it was a false alarm.

Notify your network operator.
Report your phone stolen and ask them to deactivate the SIM card in the phone, so that no further two-factor authentication credentials can be sent to that phone by text message. (Be aware that at that point in time, the phone will also loose any cellular data connection, which might hinder any remote tracking attempts a la Apple's Find My iPhone. Maybe just remove text messaging from your plan, instead?)

Change high-priority passwords.
Luckily, you have a list of those.

There are some additional considerations to be taken into account, though: You may be well familiar with various apps asking for authorization to post on your Facebook, Google+, LinkedIn, Twitter, etc. accounts. These authorizations are not necessarily tied to the password you use for the respective service -- each app may have been issued its own authentication credential to use with the service. In other words: That PDF reader app on your device might still be authorized to access your Dropbox account, even though you changed your Dropbox password. (If you use Dropbox, check out the "My apps" menu under Settings to see which apps are authorized to access your account.)

For various reasons, this is usually a good thing. But what this means is that for those cloud services with a more sophisticated authentication architecture, you may need to look through the list of authorized apps for your account and revoke authorizations for the apps that reside on your lost device.

Other things
Now it may be time to:
  • Review the list of critical data stored by apps on your device, and decide whether there is any other action you oughta take. Notify somebody that the confidential data they shared with you might have been compromised, for example.
  • Change lower priority passwords. See the note above for high-priority passwords.
  • Cancel your credit card(s), if that worries you. (See above.)
Things You Won't Be Able To Do
Data that's on your lost device is, well, lost. At least the particular copy of that data that was on the device. This also means that if you have reason to believe that somebody might undertake the effort to access this data on the device, you need to accept that they might succeed. As mentioned above, all you can do is to review the type of data that might be compromised, and try to be pro-active in remediating the potential effects of that compromise.

...if anybody actually ends up using this, post a comment or drop me a note. I'd be curious to know how many people bother. ;-)

Thanks to Auston Holt (@c3llardoor) for feedback!

Tuesday, April 16, 2013

Collecting Rainy Entropy

Somebody in a rainier climate than central Texas should try this. (If they haven't already. I suspect this isn't a new idea, but as I am writing this I'm sitting in the communal tent of a base camp of Puebla's mountains, waiting for days of rain to end, and don't have Internet access to check...)

Most reliable entropy sources, in particular as input for the generation of "random" numbers used in computing and cryptography, are of physical nature and derived from some natural phenomena. Rain appears to me to be such a source. I would suspect that the exact location of where a rain drop (in a region sufficiently covered by clouds emitting rain, obviously) hits the surface of an object on earth is pretty random and unpredictable. If we sample a bunch of those rain drop events with sufficient precision, say by recording where they hit within a defined boundary (a square meter? ten?), that should be a decent source for filling up our entropy pools.

I can't think of a method to directly sample the location of where a single rain drop hits the earth with sufficient precision, though. But what occurred to me the other day is that indirectly, this could be accomplished by recording their sound when hitting a surface:

Say we take an umbrella (think restaurant outdoor-space-sized) and outfit it with a number of strategically placed microphones. Given sufficient sensitivity of the microphones and their appropriate spatial distribution, with sufficient digital sampling capabilities it should be possible to write a piece of software that derives randomness from the sound of a rain drop hitting the umbrella: Depending on where the drop hits, some microphones will record it with more intensity than others. If it's raining sufficiently hard, we have a whole bunch of these events creating noise in random locations on our umbrella that we can sample.

Sketch of a free-standing umbrella with microphones (indicated by X'es) sampling the noise created by rain drops hitting the surface of the umbrella.
Some spontaneous thoughts on things to keep in mind, without any claim of completeness:
  • The object that collects the noise events should probably be of symmetric shape, and not store water. (The rain should be free to run off the surface rather than creating puddles that may alter/harmonize sounds as they fill with water.)
  • Our collection device should be free-standing from other structures. If, for example, trees are intercepting rain drops that are originally headed for our collection surface, or concentrating rain so that it drops down from leafs in the same location a lot, we probably loose entropy?
  • The capturing devices (microphones) sampling the events should probably be arranged in some symmetrical or otherwise evenly spaced way. If they all hang out in the same spot, they won't help us distinguish between the location of different rain drops hitting our surface.
Too much coffee to late in the afternoon made me lay awake in my tent for a while one night, listening to the rain hitting the tarp above it and inspiring these thoughts. (That tarp structure obviously didn't survive the heavy winds that followed the days of rain and needed some upgrading. ;-))
Obviously, this all only works when it rains heavily enough. No rain, no entropy.

Instead of using microphones to sample the sound and infer the location of rain drops hitting a surface, I can think of sampling vibration instead, too. If our surface is flexible enough, like a tarp, spacing out vibration sensors should have a similar effect?

Which makes me wonder whether we can use the existing network of sensors to measure earth quakes across the world to derive entropy from those events, too?

Monday, September 17, 2012

Hardening Mountain Lion

After spending some time installing Mountain Lion (OS X 10.8), from scratch rather than over my old Lion installation, the usual question arises: How to harden it?

Of course, I can't find my notes from hardening Lion back in the days. I guess I'll use the blog as an excuse to keep notes this time. Feel free to use my notes and reasoning as an inspiration or motivation, but keep in mind that everybody's risk profile differs. I may prefer paranoid settings over convenience and you don't, or vice versa.

Also, most certainly, my considerations below are incomplete. And for the most part, I'm assuming a single user (myself) and don't bother too much with defining password policies, etc.

The Obvious

There are some obvious security settings - those that you can find by clicking through the System Preferences options. Here are my thoughts on those:
  • Users & Groups
    • I set passwords for my users. I also use a non-admin user for my daily work. The OS X elevation mechanism seems to work just fine for installing software, etc., although non-admin users are not in /etc/sudoers by default. So I create a separate user that has "Allow user to administer this computer" enabled, and disable it from the one that I use on a daily basis. Or the other way around.
    • Strangely, it seems like the guest user came enabled by default. Disable it.
    • "Set Master Password" for encryption under Preferences (the little wheel below the user list). Probably not a bad idea if you are prone to forgetting your account passwords. Now you have one more to forget. ;-)
  • Desktop & Screen Saver
    • Mine starts after 20 minutes.
  • CDs & DVDs
    • I usually ignore them.
  • Bluetooth
    • Uncheck "Discoverable". Turn it off if you don't use it.
  • Sharing
    • I don't enable any sharing unless I specifically want to use it for something.
  • Software Update
    • Automatically check for updates.
  • Security and Privacy
    • General
      • "Allow applications downloaded from:" - This pertains to Apple's Gatekeeper functionality. Of course, there's (still) software out there I'd like to use that hasn't been officially signed, so I ended up choosing "Anywhere". But I am usually pretty aware of what I'm installing and where it comes from, and don't have other users using the laptop.
    • FileVault
      • I don't see a reason not to use this. Maybe a little performance hit? Ah well.
    • Firewall
      • Enable it. "Block all incoming connections" is always a tough call when you use the system in a hostile environment. I leave it unchecked, most of the time, and check the list of applications that have been added with individual settings every now and then.
      • Disable "Automatically allow signed software to receive incoming connections".
      • Check "Enable stealth mode".
    • Privacy
      • Personal preference, I suppose.
    • Advanced… (the button on the bottom)
      • I let it "Automatically update safe downloads list" and "Disable remote control infrared receivers" (don't have any). 

Existing hardening guidelines

It's a little early to expect that anybody has analyzed Mountain Lion to the extent that they can publish a comprehensive hardening guide. Apple has not published Security Configuration Guides or Common Criteria guidance material since Snow Leopard. Sadly, since they used to be well-written and useful. So, let's see what we can scavenge from the Snow Leopard Security Configuration Guide:
  • Setting an EFI (Extensible Firmware Interface) password to prevent unauthorized booting into single-user mode
  • you can use 'sudo visudo' to add non-admin accounts to /etc/sudoers (like the unprivileged one you are using for daily work)
  • pwpolicy lets you define a password policy
  • stripping suid bits from executables (pg. 151 ff.), I did it for the following (if anybody has taken the time to investigate what Apple has added since Snow Leopard that might be worthy of disabling, let me know :)):
    • /System/Library/CoreServices/RemoteManagement/
    • /bin/rcp
  • chmod 700 for users' home folders (supposedly breaks Apple file sharing and web sharing?)
  • block Bonjour advertisements, and use ipfw to block incoming Bonjour traffic
The University of Texas also has a nice compilation of useful tips:

Other things

I use a virus scanner, always have. I don't believe in the immunity of OS X from malware. I use eset.

OpenDNS is also a great idea.

Safari has additional security and privacy settings to consider, if you use it.


It might be worthwhile to reason about ipfw rules to further tighten down the OS X firewall. The Snow Leopard Security Configuration Guide contains instructions on how to do that. Similarly, going through the list of daemons and user agents on the system and determining which ones could be disabled should be interesting.

Saturday, August 11, 2012

Safer Internet Cafe Access for Your Email

I'm a big fan of one-time passwords for (email) accounts when I am traveling without my own laptop / tablet / smartphone. If you are in some part of the world perusing a computer in an Internet cafe to access your email account, there might be / likely is (depending on your level of paranoia) at least some sort of spyware or keyboard loggers hanging out on that PC, ready to steal your password when you type it in.

The next best thing is some sort of two-factor authentication. Many services offer this these days (Google, eBay, some OpenID providers, like Symantec's (ex-Verisign) Personal Identity Portal). Depending on one's needs, this doesn't even involve carrying a RSA SecurID token in your pocket. It could just be a soft token on your phone that generates time-sensitive codes. Logging into an account then typically requires your password (one factor) and something else. Something else involves a factor that is different in nature from the first one. The different categories include knowledge (like, your password), possession (a token that generates codes or holds a cryptographic key, for example), and a person's individual properties (such as fingerprints or the iris pattern of your eye). But I divert. Really, in my internet cafe scenario, two-factor authentication is just a means to an end. I care less about having two factors, and more about having any factor at all that cannot simply be recorded and reproduced without having my token or my biometric properties. The problem with this is that biometric authentication isn't ripe for use over the Internet, and that I don't necessarily want to drag an (electronic) token of some fashion on the trek with me.

So, one-time passwords. A list of passwords that can each only be used once, and can be carried around on a piece of paper. My mail host, Tuffmail, which I love for its reliability and geek factor, doesn't support any. My backup solution for accessing emails while traveling in remote parts of the world is forwarding my email to Gmail, and (mis-)using Gmail's two-factor authentication.

You should use Google's 2-step authentication anyway. (Enable it in the authentication settings.) With that comes a list of "Backup verification codes", 10 of them, that are - essentially - one-time passwords that can be used in lieu of the regular second authentication factor. (In other words: if you aren't carrying your phone with you or don't want to pay for receiving text messages abroad.) So, you've got ten logins to your Google account with your regular password and one of the backup verification codes each. If somebody intercepts a logon on a borrowed computer, they won't be able to re-use those credentials after you have logged out. Without the second factor, your password won't help them. (Make sure you uncheck the box that designates the current computer as a "trusted" computer when logging in. And change your regular Google password when you get home.)

Thursday, July 19, 2012

Securing Your Public WiFi Usage with pfSense IPsec Tunnels

Coffee shops, airports, and other public areas are dangerous places, as far as using their wireless Internet hotspots is concerned. This article is a mixture of both telling you about some of the philosophy I apply toward using public wireless networks, and providing some actual technical references for setting up the particular solution that I have implemented to address it. Pick whichever pieces you are interested in and skip through the rest of it.

Most of us have heard at least a little bit about the potential for random folks being hooked into the same WiFi network as ourselves at the coffee shop, and intercepting our devices' communication with the rest of the world. If the network sessions established by the individual apps and web browser on my laptop or smart phone are not properly secured, they might be able to read my email, intercept the password my banking app sends to my online bank, or make me think that I'm talking to the server I intended to reach while it's really the attacker on the couch across the room that I am handing my personal information to.

A prominent example of this is Firesheep, which was created in order to demonstrate how easy it is for someone else connected to the same WiFi network to hijack unprotected HTTP sessions between your web browser and, say, Facebook. Granted, many of the larger service providers have addressed this problem by now, but as an end-user you don't really know that every app you use implements proper encryption (and server authentication) technology. In particular when we are talking about mobile devices like my iPhone. Unless you are geeky enough to hook up a network sniffer and know how to figure it out on a technical level, you are dependent on the app developer doing the right thing, which doesn't always happen.

This is less of a problem for my network at home, where I likely have the local loop between my Internet Service Provider and my wireless router to myself, making it harder (but of course not impossible) for somebody to get into the middle of things. It's easier to sit in a coffee shop and fish for random network connections of interest, rather than getting close to my home and hooking into a "properly secured" wireless network or my DSL wires.

My remedy? I have a separate firewall device sitting between my DSL router and my home network. For one, it allows for more control of the network traffic that's happening between my home network and the Internet. But in the context of this article, it also allows me to set up VPN connections from my mobile devices (phone, table, laptop, ...) to the firewall, and from there not just into my home network (if I wanted), but also back into the Internet. The trick is to configure my mobile devices in a fashion that ensures that all traffic originating from the device is routed through the encrypted VPN tunnel to my firewall, and from there enters the spheres of the Internet. All that the attacker sitting in the coffee shop then gets to see is an encrypted connection between my device and my firewall, with no opportunity to get into the middle of it.
Purple connection can be intercepted by the bad guy. The blue one is encrypted by an IPsec tunnel to my firewall, and then forwarded from there (without the IPsec encryption) to the App / Web Servers. The bad guy can't read it.
Technically, this works for me as follows: A while ago, I came across the open source firewall software pfSense, based on the FreeBSD operating system. In order to install it, you need dedicated computer hardware, not just your WiFi or cable/DSL/whatever router. Fortunately, there is an extremely slick solution to this, if you are willing to invest about $200. ALIX systems are micro boards with AMD CPUs designed in Switzerland to run network devices, like wireless routers. I ordered mine from, which also sells aluminum enclosures for the boards. All you then need is a CF card (remember, those big cards used in early digital cameras?) to store your operating system on, which you can get from Amazon or the like.

My ALIX box, housing my pfSense firewall. CD-ROM for scale.
I'll spare us all the basics of setting up a pfSense firewall. There is plenty information out there on the Internet, and I have to admit that you should have a basic idea of what it is that I am talking about before you commit to setting up your own firewall. The remaining question that I had to piece together was how to set up a VPN server on the pfSense box that would forward all the traffic from my mobile devices (which, shockingly, are all Apple devices - an iPhone and iPad, and a MacBook Pro) to the firewall and from there to the Internet, and how to configure VPN clients on said mobile devices.

I chose to look at IPsec, one of several VPN technologies that pfSense supports, because there seems to be wide-spread, built-in support with many client operating systems. In particular, it appears that pfSense will work with Cisco IPsec clients, and everything that emulates such clients. There is a great how-to on the pfSense website, which includes both instructions for setting up an IPsec server on your pfSense firewall, and configuring the client side of things. What it doesn't tell you is that when defining the Phase 2 of the IPsec tunnel, you need to select "none" for the local network in order to force the client to route all traffic through the VPN server, and that you need to disable the advertising of available networks to clients. (Otherwise, the client will connect to the VPN server on the firewall, but will only route traffic to it that is destined for the local home network, rather than all traffic that is originating from the client.) At least those were the configuration settings that I was initially missing for success.

Now, whenever I'm using a wireless network that I don't trust (which are most of them ;-)), I'll use the native iOS or OS X client to establish an IPsec connection to my firewall at home, and can care a little less about who else is connected to the same hotspot. (Somebody should comment here on how to set up clients on other operating systems, like Windows and Android...)

Other side effects? Circumventing filtering mechanisms of whoever is controlling the part of the Internet that I'm currently connected to. As long as I can establish the VPN tunnel to my home firewall, all traffic channeled through it is (only) subject to the filtering that my home network is exposed to. Which, in the US, is to date rightfully not much.

There are, of course, some unknowns remaining. If my mobile device isn't protected properly against active attacks from the network I'm connected to, establishing a VPN tunnel won't help me with that. A personal firewall (on full-fledged devices) or faith (in case of mobile devices) may. And attackers can still get to me in other ways. And of course, if somebody is motivated enough to actually infiltrate more central parts of the Internet in order to get to my networking sessions, this won't help either. My IPsec tunnels are just addressing one particular risk out of many.