Archive for August, 2010

phone home

Sunday, August 29th, 2010

Google’s chrome browser first appeared back in 2008, since when many commentators have sung its praises. Apparently it is “blindingly fast” (well, let’s face it firefox can be a tad slow, particularly if loaded down with a swathe of plugins) “clean”, and “simple”. Until recently I had not tried chrome (for some fairly obvious reasons) but I thought it might be interesting to fire up a copy in a VM just to see what all the fuss was about. So I did. And whilst I was doing that I ran tcpdump and etherape to see what was happening under the hood. What I found intrigued me.

First I spun up a completely new clean install of ubuntu in a virtualbox VM. Then I downloaded the latest chrome .deb from the google site and installed it. Before launching chrome for the first time in the guest system I fired up the sniffers in the host system. This is what I found:

image of etherape capture

Note that etherape shows five connections which are instantly recognisable as going to google servers (the 1e100.net domain), three to verisign, and a further three to IP addresses with no associated names (these appear to be either youtube or google image cache machines – also owned by google of course). You can ignore the rlogin.net servers, they are all mine.

A quick look at the tcpdump record shows that the verisign connections all check for SSL certificates and/or revocations – perfectly sensible and understandable. But the google connections are less illuminating until you follow the tcp streams. Two of the connections are SSL encrypted so it is not possible to be certain what is carried in them, but they appear to be certificate exchanges (or updates), a third gets a certificate revocation list whilst two more get simple html or xml schema probably associated with building the welcome screen (I didn’t explore in detail). One connection gets a shockwave flash file and two get and set cookies in the youtube domain. At least one of the google connections also gets and sets cookies in the google domain.

Now none of this is inherently suspicious (well, alright, it might be) but the point is that all this happens upon first connection and without reference to the user. And if you don’t want google (or youtube) cookies on your machine you will have to delete them when first you use the browser. I have an instinctive (OK, partly irrational) dislike of software which “phones home” without telling me – and chrome does that on quite an impressive scale. I’m not sure what would happen in prolonged usage of the browser because I wasn’t impressed enough to want to use it in anger.

I’ve trashed the VM of course.

update to autossh – or how ServerAliveInterval makes this unnecessary

Friday, August 27th, 2010

I had a couple of comments on my earlier post about autossh which suggested that I should look at alternative mechanisms for keeping my ssh tunnel up. Rob in particular suggested that setting “ServerAliveInterval” should work. Oddly I had tried this in the past whilst trying out various configuration options and I swear it didn’t work for me. But since the autossh mechanism felt inelegant I thought I’d revisit my ssh_config file as Rob suggested. And indeed setting ServerAliveInterval to 300 (i.e. 5 minutes) solved my tunnel drop problem. I’d guess that other intervals of less than 1 hour would equally work but I haven’t checked.

I have no idea why my earlier experiments failed.

they are taking over the entire net

Monday, August 2nd, 2010

Some time ago I disabled my wp-recaptcha plugin because it had the unfortunate side effect of marking all comments as spam. I don’t have a particularly high comment rate, but the ones I do get, and which get past akismet, are usually OK. Apparently a flaw in version 2.9.6 surfaced when wp-recaptcha was used in conjunction with wordpress 2.9.2. I obviously got caught with this when I updated my wordpress installation so when I noticed the problem I just disabled wp-recaptcha. Of course I have since updated wordpress again and I noticed that the plugin had also been updated to 2.9.7 so I thought I would upgrade and reactivate. Upon doing so, however, I discovered that my public/private key pair had disappeared as a result of the deactivation and I was invited to apply for a new set. OK, no problem, happy to do so but a bit peeved that the keys seemed to be deleted when the plugin is deactivated. This strikes me as unnecessary.

But, and this is now a big but, this is what I was greeted with when I attempted to get a new set of keys:

“reCAPTCHA is now part of Google. In order to use it, you must create a new Google Account or sign in with an existing Google Account.
If you are a previous user of reCAPTCHA, you can migrate your old account after signing in with a Google Account.”

Yikes! It seems that re-captcha is now part of google. The chocolate factory have bought yet another piece of internet infrastructure which will no doubt feed the maw of the advertising goliath with statistics gained from my site.

Well bollocks to that. It can stay disabled. I’ll look for another captcha mechanism.

autossh – or how to use tor through a central ssh proxy

Sunday, August 1st, 2010

Since I first set up a remote tor node on a VPS about this time last year, I have played about with various configurations (and used different providers) but I have now settled on using two high bandwidth servers on different networks. One (at daily.co.uk) allows 750 Gig of traffic per month, the other (a new player on the block called ThrustVPS) allows 1000 Gig of traffic. These limits are remarkably generous given the low prices I pay (the 1000 Gig server cost me £59.42, inc VAT, for a year. OK, that was a special offer, but they are still good value at full price) and they allow me to provide two reasonably fast exit servers to the tor network. Both suppliers know that I am running tor nodes and are relaxed about that. Some suppliers are less so.

I fund fast exit nodes as a way of paying something back to the community – but as I have pointed out before, they also allow me to have a permanent entry point to the tor network which I can tunnel to over ssh, thus protecting my own tor usage from snoopers. For some time I used a configuration based on tyranix’s notes documented on the tor project wiki. But eventually I found that to be rather limiting because it meant that I had to remember to run an ssh listener on each machine I used around the house (my laptop, netbook, two desktops, my wife’s machine etc) and to configure the browser settings as necessary. Then I hit upon the notion of centralising the ssh listener on one machine (I used the plug) in a sort of ssh proxy configuration. This meant that I only had to configure the local browsers to use the central ssh listener as a proxy and everything else could be left untouched. It also has the distinct advantage that my wife no longer has to worry about anything more complex than switching browser when she wants to use tor.

But I hit a snag when initially setting up ssh on the plug. For some reason (which I have never successfully bottomed out) the ssh process dies after an hour of inactivity. This is not helpful. Enter autossh. Using autossh means that the listener is restarted automagically whenever it dies so I can be confident that my proxy will always be there when I need it.

Here’s the command used on the plug to fire up the proxy:

autossh -M 0 -N -C -g -l user -f -L 192.168.57.200:8000:127.0.0.1:8118 tornode

That says:

- M 0 – turn off monitoring so that autossh will only restart ssh when it dies.
- N – do not execute a command at the remote end (i.e. we are simply tunneling)
- C – compress traffic
- g – allow remote hosts to connect to this listener (I limit this to the local network through iptables on the plug)
- l user – login as this user at the remote end
- f – background the process
- L 192.168.57.200:8000 – listen on port 8000 on the given IP address (rather than the more usual localhost address)
- 127.0.0.1:8118 tornode – and forward the traffic to localhost port 8118 on the remote machine called tornode

Of course “tornode” must be running ssh on a port reachable by the proxy. Again, I use iptables on tornode to limit ssh connections to my fixed IP address – don’t want random bad guys knocking on the door.

Now on tornode I have polipo listening on port 8118 on localhost. I used to use privoxy for this, but I have found polipo to be much faster, and speed matters when you are using tor. My polipo configuration forwards its traffic to the tor socks listener on localhost 9050. I also disabled the local polipo cache (diskCacheRoot = “”) because leaving it enabled means that the cache (by default /var/cache/polipo) directory will contain a copy of your browsed destinations in an easily identifable form – not smart if you really want your browsing to be anonymous (besides, my wife deserves as much privacy as do I).

The final bit of configuration needed is simple. Set your chosen browser to use the proxy on port 8000 on address 192.168.57.200. Since I use firefox for most of my browsing, I simply use opera for tor and I have that browser stripped to its basics and locked down as much as possible. Using tor is then simply a matter of firing up opera in place of firefox. This means that I always know when I am using tor or not (and just to reassure myself, the opera homepage is the torcheck page).

You can’t be too careful.