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):

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 2010debunking 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).

Further Reading

If any of this interests you at all then I suggest the following
links, in addition to the stuff I’ve already pointed at:

The counter-piece by Marcus Ranum that goes with Schneier’s 2003 piece on monocultures and which argues that there’s no issue here for software. You decide;

Originally I tried doing the tor-browser port as a set of patches against firefox-esr, since there was already a port for Firefox ESR and theoretically Tor browser is just that: patches against Firefox ESR. I abandoned this approach after it became obvious it was kind of nuts, but I’ve preserved the set of patches I created in case anyone is interested. I found it useful to get a sense of the scope of the changes made to Firefox ESR by Tor browser. YMMV.