Poojan (Wagh) Blog

I use Google Talk at work mainly to post to social networks (army.twit.tv, identi.ca, twitter.com, yammer.com). It is possible to receive notification using Google Talk (which is just a Jabber/XMPP instance), but I find that too intrusive to what little work I get done.

1. Run pidgin (if not already) and select Accounts->Manage

   

2. Select Add to add another account:

   

3. Select XMPP for the protocol type:

   

4. Fill out the form as follows with gmail/gtalk username & password; domain is gmail.com; Resource is (optionally) Work:

   

5. Click advanced button. Select old (port 5223) SSL. Select 443 for port number. Server is talk.google.com. Fill out http proxy (for example, wwwgate0.example.com, port 1080) & http-proxy username & password (not likely the same as your gmail username/password):

   

This works because http proxies generally allow ports 80 (http) and port 443 (SSL/https) through. They generally disallow other ports. Luckily, google’s jabber server (talk.google.com) accepts connections on port 443–and they are SSL (encrypted) connections, so that’s good, too.

I was a little worried about WordPress login’s, and about whether the data was sent in cleartext. Besides this point, was it possible for snoop on my traffic, steal my session cookie, and then impersonate me? It turns out the answer is yes. So, I wanted to lock down my blog to prevent traffic snooping and to encrypt the login.

This class of problems has been solved. The preferred method to do this would be SSL.

To use SSL, you need two things: a unique IP and an SSL certificate. Dreamhost charges around $4/month for a unique IP. You can get an SSL certificate for around $10/year. I don’t mind paying these charges. However, I have serveral blogs at different domains. I didn’t really want all the blogs to be SSL. However, I did want to protect my logins from being sniffed/hijacked.

Note that there were a couple of ways I was accessing my blog. I use the regular WordPress web interface (which calls for a method to encrypt traffic through FireFox) and I use Winodws Live Writer (WLW). Firefox lets you use either a SOCKS proxy or an HTTP proxy. WLW allows you to specify only an HTTP proxy. However, I found that Privoxy can act as an adaptor, converting HTTP proxy traffic into SOCKS traffic.

I came up with several solutions. In chronological order:

SSH

By far the easiest and best way to get security without paying for SSL is SSH. This has been well-documented elsewhere. You can tunnel your web (http) traffic in SSH. Your traffic then inherits the encryption and authentication features of SSH.
The best way to tunnel SSH is to set up a dynamic tunnel; this is the same as a SOCKS proxy. If you’re using the command-line on UNIX/Linux, this can be done with a:

ssh -D :1080 -N @.dreamhost.com

This will only listen for connections on the current machine. (The machine in which you type the above command). If you want to set up this machine as a secure SOCKS server for other machines to connect to, you type:

ssh -D *:1080 -N @

I did this on my FreeBSD machine once. I can then connect to it from other machines on my network (Windows machines for example).
I use this SSH-based SOCKS proxy in combination with the Firefox Add-On FoxyProxy. FoxyProxy lets you set pattern-based rules to determine whether to send traffic through a proxy (and which proxy).

HTTP-Tunnel

The SSH method works very well from home. Unfortunately, my employer doesn’t allow SSH traffic through its firewall. In fact, the only traffic that is allowed is HTTP traffic, through their own HTTP proxy.
I found a very promising and powerful program called HTTP-Tunnel. This program lets you set up a SOCKS server that translates all your traffic into HTTP requests.
The program is composed of a client (a Perl script running on your machine at work) and a server (which can be a perl script or a PHP script). Since the only access Dreamhost gives is FTP/SSH/telnet/HTTP, I ran the PHP version (which runs as a PHP CGI script). (The perl version listens for traffic on a specific port.)
To get this to work on Windows, I installed CygWin. I tried ActiveState Perl. However, I found the necessary packages for encryption (MCrypt & OpenSSL::RSA::Crypt, available from CPAN) difficult to find & install using ActiveState.
It was difficult to get the parameter sets (& Perl modules) set up correctly for HTTP-Tunnel to work. However, in th end, it did work. I was able to get data from firefox (once again with FoxyProxy) through the tunnel to DreamHost. Note that once I was in DreamHost’s network, I wasn’t as worried. At some level, you have to trust DreamHost not to spy on your traffic. In my case, there’s not a a lot of interesting stuff to look at. I just want unauthorized users getting access to my blog.
The main difficulty with HTTP-Tunnel is that it seems to be unmaintained for quite a while. In addition, I’m not qualified (nor do I have the time) to analyze the code to verify its security (and uncover any vulnerabilities).
One final note: I wasn’t able to use HTTP-Tunnel as a SOCKS server for SSH. (Don’t be confused with using SSH to create a SOCKS tunnel.) What I was trying to do here is run an SSH session which used the SOCKS tunnel (created by HTTP-Tunnel) as a communications channel. I tried both OpenSSH and PuTTY. Both failed because they for some reason, the HTTP-Tunnel program just stalled during SSH key negotiation.

WordPress Plugins

I found two excellent plugins that took care of web logins to WordPress.

Restrict WordPress cookies by IP

One thing about TCP/IP is that due to the 3-way handshake, you cannot spoof an IP. (You can send a SYN packet, but you can’t negotiate a link from a bogus IP address.) So, if we restrict the cookie to come from a specific address (by encoding the IP address in the cookie), we can verify that the person making a request using this cookie is the real person (i.e. has the correct IP address).
In fact, w-shadow wrote a WordPress plug-in that does exactly this. It’s even up-to-date for WordPress 2.6. Note, however, that this plug-in won’t prevent man-in-the-middle attacks. I’ve concluded that such attacks are pretty difficult to to orchestrate, since you need to be upstream from the victim.

Use OpenID

The WP-OpenID plugin allows you to associate a WordPress user with an OpenID account. I have an OpenID provider. Associating with OpenID allows me to login (using SSL) to OpenID first. Then, I automatically get access to my blog account.
Unfortunately, this scheme does nothing to help with hijacking the session. So, it should be used in combination with w-shadow’s plugin.

Encrypt the login

I found another jewel of a plug-in: Semisecure Login Reimagined. This plugin sends a public RSA key to the client (via Javascript). It encrypts (using Javascript in the client) the username/password using this public key. The server (and only the server) can decrypt the username/password.
So, merely logging in does not send your username/password in the clear.

Summary

Obviously none of the above is as good as SSL. Pretty much everything supports SSL (including the HTTP proxy at my work). However, given the cost of SSL (unique IP & certificate), I feel that the WordPress plugins (when I am not at home) and tunneling over SSH (when I am at home) give my username/password & cookies fairly sufficient protection from being sniffed/hijacked.