In the endless spy vs spy game of net security there have been two recent setbacks for the good buys.
One is the rise of the keystroke logger. That's how I suspect my Google account was hacked from an insecure machine - a corporate laptop running XP. The best response to the keystroke logger is either to carry the 11" MacBook Air -- or to establish disposable network services for use on untrusted devices.
The other setback is the very recent emergence of trivial sidejacking.
Sidejacking is the theft of network credentials, and particularly cookies, by intercepting unencrypted WiFi network traffic. It's been a commonly recognized and widely ignored problem for about three years, but now a security researcher has decided to make ignorance impossible. He's released Firesheep (my 11yo says it should be called "Firerat") to make Sidejacking a trivial task bored kids (emphases mine. He's yelling at Facebook here.)...
... When logging into a website you usually start by submitting your username and password. The server then checks to see if an account matching this information exists and if so, replies back to you with a "cookie" which is used by your browser for all subsequent requests.
It's extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called "sidejacking") is when an attacker gets a hold of a user's cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy.
This is a widely known problem that has been talked about to death, yet very popular websites continue to fail at protecting their users. The only effective fix for this problem is full end-to-end encryption, known on the web as HTTPS or SSL. Facebook is constantly rolling out new "privacy" features in an endless attempt to quell the screams of unhappy users, but what's the point when someone can just take over an account entirely? Twitter forced all third party developers to use OAuth then immediately released (and promoted) a new version of their insecure website. When it comes to user privacy, SSL is the elephant in the room.
Today at Toorcon 12 I announced the release of Firesheep, a Firefox extension designed to demonstrate just how serious this problem is.
- Witopia VPN ($40/year for good-enough PPTP). I used them for twoyears, after I first worried about sidejacking in 2007, and they provided good service. I'm cheap though, and didn't need them that often, so I decided to wait until the sidejacking problem got worse.
- Various solutions that get you into your home network and let you use those presumably secure resources. Too much trouble for me, and too likely to be flaky.
- SSH tunneling - aka the poor man's VPN. This forces all traffic through an "SSH tunnel".
I tried Witopia VPN before and I'd recommend them (though I did have technical problems) - but I'm feeling cheap these days. I decided to try SSH tunneling because I already pay for full service hosting through DreamHost; so I have what SSH needs.
(BTW, I love DreamHost. If you sign up with my promo code of KATEVA I get a $50 kickback and you get $50 off your 1st year fee. Today, however, they're offering $110 off -- a full year of service for $9.25. To put it mildly, this is unbeatable.)
This is how the DH wiki describes their SSH tunneling SSH Tunneling
Your Dreamhost account can be used to create a secure tunnel to circumvent firewalls that prevent access to particular websites. This isn't recommended as a replacement for a VPN or similar service, but if you need the occasional ability to reach sites that would otherwise be unreachable *or* need secure access because you are using an unsecured access point, this might be an appropriate solution for you.
SOCKS is the name of the protocol used. SSH is the name of the software used to create the tunnel. There are a number of GUI options available for Windows, Mac OS X, and *nix, but using SSH usually demands a command-line environment. This article will assume that it is installed and configured appropriately. Practically speaking, this information is not that important. You just need to know the magic incantations.
Note: This is a great temporary solution if you need to view something your ISP has blocked for unknown reasons. It should be considered a temporary solution, as it will definitely use bandwidth on your account. When you are on a shared server, it's nice not to abuse the system.
The wiki page provides some Windows instructions using Bitvise (Free!) Tunnelier, but Mac users can get by with the command line (though I will also test OS X Meerkat separately). Here's what I did at DreamHost to get the SSH tunnel working on my 10.6 machine:
- Using DreamHost Control Panel:Users:Manage Users confirm account has a user setup with a shell account.
- IN OS X Terminal type: ssh -D 9999 email@example.com
- jgordon is not my true username, it's just an example
- trafficante is my DreamHost server. Yours may be different.
- 9999 is the port number
- -D turns on compression
- Some documentation says to use the N switch for non-interactive, so it would be ssh -ND 9999 firstname.lastname@example.org
- Enter this user's pw on request
- You now have an SSH connection.
To use this SSH connection you have to configure a proxy in OS X from the Network Preference Panel like this:
Of course you don't want to keep having to turn SOCKS on and off in Network Preferences depending on your settings, and you don't want to use SOCKS unnecessarily. That burdens DreamHost, and it slows your network traffic. I created a new OS X network "Location" that has the SOCKS Proxy turned on.
Also, when your done with your connection, please type "exit" in terminal to close it. That's just politeness.
Here's how you can test if the configuration is working:
- Change your "Location" to the one you setup with a SOCKS proxy (I call it Google DNS SOCKS).
- Try to open a web page. Nothing should come up, you'll get an error message.
- Now run the SSH command to create a connection.
- Retry your browser - now it should work.
I wonder if I should use a different DNS provider when I do this, currently I'm using Google DNS. For now however that seems to work.
Update: I tested Meerkat. It's a very powerful networking tool; it's not designed primarily for this problem. I can just barely follow the very sparse documentation. Really, a commercial product deserves a bit more documentation.
I think it's easier to just type the ssh command and change Location settings! If you want to try Meerkat as a sidejacking prophylactice, start with this vendor blog post. Note that in this example Meerkat uses 6666 for a proxy.
I'm going to stick with the command line and using OS X native Location settings.