haqistan

⋔ home ⋔ about ⋔ links ⋔ license ⋔ archives ⋔ rss ⋔

Adventures in Ports: Tor Browser

3085 words by attila written on 2015-03-12, last edit: 2017-05-30, tags: open-source, openbsd, pets, ports, tor, tor-browser ⋔ Previous post: Adventures in Ports: Parsing Expression Grammars ⋔ Next post: Things I Wish I'd Seen When They Were Posted

Give Me Your Hackers, Your Journos, Your Activists Yearning To Be Only Lightly Surveilled

The NYC BSD User's Group (NYC*BUG) is full of firebrands and malcontents. This is why I like them, even though I haven't met any of them in person or even set foot in NYC in well over a decade (more like two).

They count among them many hard-core supporters of privacy and anonymity online, obviously all from a BSD perspective. One of them, who goes by the mysterious handle of gman999 is clearly as contrarian as I am, and we have frequently bitched privately (hey, we're allowed) at how BSD has been more or less left out in the cold when it comes to the Tor Browser. The server side? No worries, handled. The client side? OSX, Windows, Linux or Android.

I don't have any of that. I don't want any of that. I don't care what that makes me, especially since I'm already it. My OS of choice is OpenBSD and I'm committed to the idea that whatever I want to do should be doable there.

Now the uninitiated reader might have formed the impression that the Tor Browser was just some sort of slick repackaging of Firefox plus some add-ons, and that you can just use the browser of your choice with a suitable proxy setup and quit your BSD.whinging. They might assume that. I used to think that long ago but then I started to look into it and realized it's a little more involved...

The Tor Browser: Why?

The best place to start is the original tor browser design document, where the patches they felt were necessary are spelled out. This gives you a sense of why the Tor browser needs to exist and isn't just a bunch of customization tweaks. Some of these changes can only be made by modifying the source. Beyond that document the Tor project has continued working on things like anti-fingerprinting measures. I recommend reading this tor project blog post and following some of the links there. The Mozilla wiki page on fingerprinting is especially recommended. I also recommend reading the equivalent page on the WebKit wiki to get a sense of how deep this is and how many details there are to keep track of if you really want to know your browser won't screw you over Tor (the answer is almost certainly it will unless it has been hacked not to and you modify your own behavior).

We need something like the Tor browser if we are to surf safely on Tor. I will leave discussion of what I feel about Tor more completely for another time but suffice to say I feel it is a necessary evil of the day. Anonymity and privacy online are more essential now than they have ever been for many reasons and the Tor overlay network is the best thing going right now. Since there's no point in bothering with it if you're just going to screw yourself over with your browser, you need a browser that deals with it. Since I'm not interested in using Linux or any of the other choices this means I need a port of the Tor browser for OpenBSD.

There are quite a few other people, like gman999, who also desire this, and ports to other BSDs as well. After poking around a bit I came to the conclusion that nobody was seriously pursuing this so after some goading from gman999 I decided I would port the Tor browser to OpenBSD and see where that leads. Yay: a new Adventure in Ports.

Bundle of Trouble

The Tor browser is not intended to be used without the other elements of the Tor Browser Bundle (you can see more details on what's actually in the bundle if you are interested). Problem is: the whole "bundle" idea doesn't really work in the BSD context, or at least not for me it doesn't. I would prefer to use OpenBSD's native packaging system to produce signed packages with proper dependency meta-data in them for all of the components of any multi-component system, the way other things are done in ports. I also don't want software I install phoning home to check for updates or automatically updating itself, since it certainly won't be using the native OpenBSD mechanisms to do so. I would prefer to update my software by installing packages created by OpenBSD ports maintainers after they've properly vetted that the update is good and sorted out issues with dependencies, etc... but, then, I am of the opinion that the standard set of packaged 3rd party software available is something that organically belongs with the operating system, and that the release cycle of the OS naturally drives forward subsequent releases of the packaged software. When there are critical bug fixes or security patches then, again, the mechanism native to the OS for dealing with them should be used.

This, at least, is what I'm comfortable with. I think many BSD people share my point of view but I don't pretend to speak for anyone but me. I also have to note that many of the Cool Kids are definitely not in agreement with me, cranky old man that I am. The trend seems to be towards self-updating/phoning-home stuff. This really rubs me the wrong way and I suspect many older BSD hands, anyway, feel the same.

When I need to build stuff from source then fine, I do that, but there's a difference between stuff I'm screwing around with and stuff I expect to work. In any event the Tor Browser is not the kind of thing you want to build from source all the time. Trust me, I've done it a ton now. You really want to install this as a package that someone else built, or eventually a set of packages.

So the obvious starting point is to produce that first package that is the foundation of all of it, and that is the Tor browser itself. I now have a port for OpenBSD that produces a working tor-browser binary under OpenBSD-current on amd64. It is still a work in progress. If you want to play along then do something like this (again, remember: must be running -current):

# mkdir -p /usr/ports/mystuff/www
# cd /usr/ports/mystuff/www
# ftp -o - http://bits.haqistan.net/~attila/tor-browser-2.tgz | tar zxf -
# cd tor-browser
# make install

Be prepared to wait a while. Also it would help if whatever partition your /usr/ports tree is on has at least 10G of disk space free. In my case I keep /usr/ports on /home, since by the standard auto-partitioning scheme from the OpenBSD installer this ends up being the largest partition. I then symlink /home/ports to /usr/ports. If you don't do something like this you might run out of disk space trying to build tor-browser. You also probably want a lot of RAM.

Once you have tor-browser built you also need to do a couple of things before you can use it properly:

Either change the port that tor listens on in /etc/tor/torrc from the OpenBSD default of 9050 to 9150, or start up tor-browser and change the socks proxy port in Preferences from 9150 to 9050; a subsequent release of the port will change the default.
Install the torbutton extension, at least. It looks like the Tor project doesn't want to make an XPI available on their site, as they prefer you to install the tor browser bundle, which comes with it. Of course this doesn't work for us in BSD land, and torbutton is not in the normal add-ons database that the add-on manager's search lets you peruse. To facilitate things for early OpenBSD adopters I've cooked an XPI here: torbutton-1.9.0.0.xpi (SHA1 3280e8141c150a76287a2ada2a4625ad8bb07859). You can also check out the source from the torbutton git repo and cook the XPI yourself, then use a file: URL to install it.

This is as far as I've gotten. We are still a way from having the entire TBB on OpenBSD but the first major hurdle has been cleared, or at least breached...

A Word on Monocultures

One thing I haven't touched on above but which might be the most important point about this whole effort is that, if nothing else, we are pushing back against an emerging monoculture, and this is always a healthy thing. Monocultures are dangerous for many reasons, most importantly to themselves. This has been discussed extensively as it applies to software (and obviously in other fields as well). It is a point upon which gman999 and I agree and are adamant.

I went fishing on the net for a pointer to a 2003 paper where Bruce Schneier, among others, argues against the Microsoft monoculture, to bolster my point here. Instead I found something more interesting: a piece he wrote in 2010 debunking his earlier position that software monocultures are dangerous, which I think ends up making the point that monocultures are dangerous even stronger when read in context. He ends this piece as follows (but really just read the whole piece and note that it is from 2010):

Species basically have two options for propagating their genes: the lobster strategy and the avian strategy. Lobsters lay 5,000 to 40,000 eggs at a time, and essentially ignore them. Only a minuscule percentage of the hatchlings live to be four weeks old, but that's sufficient to ensure gene propagation; from every 50,000 eggs, an average of two lobsters is expected to survive to legal size. Conversely, birds produce only a few eggs at a time, then spend a lot of effort ensuring that most of the hatchlings survive...

Our IT infrastructure is a lot more like a bird than a lobster. Yes, monoculture is dangerous and diversity is important. But investing time and effort in ensuring our current infrastructure's survival is even more important.

Okay so this is fine so far as it goes: birds vs. lobsters. Maybe I agree, maybe I don't, or maybe I think the analogy is fatally flawed because software isn't hatched from eggs of any kind (Python not withstanding). What bothers me about his argument (and again, remember: 2010) is that nature is not our adversary here: people are our adversaries, and some very well-funded, heavily resourced, highly intelligent and motivated people to boot. The CIA has been actively trying to break the security of iOS forever. Thanks to the Snowden disclosures we now have some public information about the amount of resources at the disposal of those most likely to target you on Tor. We're not talking about natural immunity here, we're talking about a threat model that includes human adversaries with unlimited resources. In this context it is hard to make the keep all your eggs in one basket and watch that basket argument hold water. It certainly holds no water with me. It may be that the effort needed to maintain diversity in the IT ecology reduces the speed at which we make "progress" (whatever that is) and our reach in general, but compared to the cost of losing all privacy and living in perpetual fear of a front-running, corrupt police state/corporate complex it really seems like no trouble at all.

Even more to the point: "ensuring our current infrastructure's survival" sounds a little different to me post-Snowden than it did before. Is that really what we want? Who does it benefit most? How much of it is just there to watch us?

I say: let a thousand flowers bloom. Not only should there be a diversity of operating systems on the client end of connections over Tor, there should be diversity in the servers that make the network, and a diversity of systems on the net in general. Encouraging diversity in this sense greatly increases the difficulty of subverting the network and de-anonymizing individual users.

Back To The Adventure

I can understand that things like Tor Browser on BSD are not on the Tor Project's radar and I'm not going to harsh out on them for this. If I am right then time and interest from other BSD users will make the point for me and if I'm wrong then: tempest, meet teapot. Beyond simply porting the browser I am pushing forward with making the rest of the components available somehow on OpenBSD. I welcome any assistance anyone wants to give in this regard and am working on getting this into shape so that it could be proposed on ports@openbsd.org for inclusion into the ports tree (I'll certainly send a shout out there for help). To me at least this means assuring myself (and having many others assure themselves) that when you run tor-browser under OpenBSD you are getting all of the anonymity and privacy protection that you get when you run the TBB under Linux or any other supported platform.

As for my adventure in ports, this one is leading me a lot of places. Much of the actual furrowing of brows came from getting my head around how the OpenBSD ports system works in more detail. I've been involved in complex build systems and ritual makefile abuse for decades now and I have to say: bsd.port.mk is a thing of beauty. I considered myself an expert in make before I started working on tor-browser but have revised my opinion: this is way better than anything I've ever done. In the end all I had to do was patch things up a little in the source tree after extracting it (via one of the many handy hooks that bsd.port.mk gives you for this purpose) and ride on top of all the stuff that Landry Breuil and gang did in the firefox-esr port and in the mozilla port module (modules are nice).

Beyond the OpenBSD specifics, however, this effort is leading me into some dark little valleys, where the sun has not shone for a long time. In the antediluvian past I was interested in and played with the Mozilla source code, but we're talking back when it was first released. I hadn't looked at it in a long time and now that I am I'm finding a lot of things that bother me. It also bothers me that the best we can do right now to protect our privacy online seems to be to layer new features on top of a bloated and ancient codebase. #ifdef OS2, anyone? How about #ifdef VMS? And then there's the profusion of calls to things like sprintf and strcat that are frequently the cause of serious problems. Also there's the issue of the known bugs, some of which languish for years. Here's one from 2008 which is the reason for the existence of some of the functionality in torbutton.

It bothers me that the approach that is frequently taken is to patch around problems like this instead of fixing the bugs. This bothers me generally but specifically in this case, since we're talking about something as important as protecting your privacy, it feels wrong to me. Obviously there are other people who feel the same. Efforts like xombrero come to mind and I've heard of others. I too am tempted to say screw Tor Browser and Mozilla in general, there are just too many problems with the underlying code base so let's start over with something simpler and Get It Right.

My trepidation at breaking that way is that I now am starting to get my head around just how much work has gone into the Tor Browser, how long it's taken and why. This whole thing is not just a moving target, but more like a desert of shifting dunes dotted with quicksand and maybe the occasional oasis. How much effort would it be to convince myself that, for instance, xombrero surfing over Tor doesn't make it easier for a TLA to fingerprint me than Tor browser, or that all of the issues covered in that original Tor browser design document are handled? I'm not saying it isn't worth doing that, and maybe that's what I should be doing. I'm deeply ambivalent about all of this.

I am however also inspired by this post: Ted Unangst on improving browser security. This is great news that everyone should cheer. I don't know what browser's JIT he plans on attacking first but I would definitely be into working on making whatever browsers benefit from his effort (1) Tor-capable (really more anonymity-preserving) and (2) more secure generally (as in: FIX BUGS).