⋔ Blog ⋔ FAQ ⋔ Resources ⋔ GitHub ⋔ Contact ⋔ TDP Onion ⋔
The TDP Projects:
⋔ Tor Browser for OpenBSD ⋔ BSD Relay Guides ⋔ Corporate Relays ⋔ Ports for PETs ⋔ Statistics ⋔
Below are some typical questions about Tor BSD Diversity Project. Feel free to contact us for questions or comments not mentioned. Sooner rather than later this FAQ will need to be categorized for clarity.
To answer this question, we have to start with your particular skills.
TDP focuses on the BSDs due to our background and experience. It is critical to note that our code and materials respect established standards, and everything original we produce is under the ISC license, a simplified version of the BSD 2-clause license. TDP is commited to portability and interoperability. We are building an open ecosystem.
In other words, if someone wanted to take TDP code and materials and spawn a similar project based on another operating system, say Plan 9, with the same eye on Tor diversity, TDP’s groundwork should make that task easier. We are also open to hosting ports work to other BSDs under cover of our GitHub account if e.g., some enterprising FreeBSD ports person wanted to work on it.
It is important to note that unlike the GNU/Linux distributions, the BSD projects, FreeBSD, NetBSD, OpenBSD and DragonFly BSD, are distinct operating systems. While the Linux distributions share a reasonably common kernel, each BSD project maintains its own kernel and userland, and determines the third-party applications available. Each BSD project evolved independently even though each originates with 386BSD Unix from the early 1990s, or earlier, depending on how it’s measured. There is and continues to be a good deal of code-sharing between the projects, including many kernel features and device drivers. However over time, the major BSDs have chosen different focuses causing whole aspects of their systems to diverge. For instance, each of the BSDs has ported OpenBSD’s packet filter. Yet in the 1990’s, all the BSDs used ipf by default. FreeBSD continues to provide ipfw, and NetBSD developed npf, another firewall alternative.
The uniting aspects for all the BSDs is the preference for the simplicity of BSD/ISC/MIT licensing and adherence to the guiding tenets of classic Unix, such as portability, modularity and interoperability.
Ultimately diversity does mean asking much broader questions. More diversity in operating systems, hardware, SSL versions, geographical locations, etc., the list could continue endlessly. It’s the right question to ask, but TDP is only beginning to provide a small piece of a response.
Here is a list of country codes that do not have any public Tor relays. Please feel free to enlist any technically capable friends or family to start running Tor relays there.
The number and percentage of public Tor relays fluctuates, and this applies to BSD relays as well. As of September 2016, the percentage is just under 5%. Web sites such as BlutMagie provide a full list of public relays with a query function to determine the exact current number among other data.
Tor Metrics provides a clear graph that strikingly, and disturbingly in our opinions, illustrates the monoculture in relay platforms.
In reference to this Reddit thread, anyone technical enough to run a robust and secure Tor relay should stick with the operating system they are most comfortable with. Nothing is more dangerous than someone running a public anonymity server on an unfamiliar operating system. We are not interested in “moving Tor nodes from Linux to BSD.” We want more nodes, preferably by increasing the number of BSD nodes faster, not by converting anyone to anything.
The best recent example of what TDP achieved is in Brazil. Before BSDCon Brasil, there were 20 or so Tor relays, all Linux except for two Windows relays. After our presentation and discussions, there are around 5–9 operational relays, accounting for up to a third of observed bandwidth provided on the Tor network. The new relay administrators were BSD users with access to the necessary infrastructure, and their relays enhanced the Tor network.
To a large extent, TDP’s target audience is those already familiar with the BSDs. Significant numbers in the BSD community have access to data center space for running relays, are developers who hack code, etc. It’s about getting the BSD community engaged into the Tor scene, not so much vice-versa.
For those interested in running a BSD relay, command-line interactions are similar enough to the Linux distros. While not the default shell on any BSD, bash is available as a port and package on all of them, although shells such as tcsh and ksh are more than capable in themselves. As a matter of fact, migrating from bash might decrease security patching time compared to tcsh or even ancient, pre-OpenBSD versions of ksh.
The BSD install processes vary, but after a few tries, it’s hardly a difficult task. For the BSDs, there is no assumption that graphical installers are “easier” than non-graphical ones.
Installing a package isn’t difficult either. To install the rsync package on FreeBSD, for instance, the user just has to type “pkg install rsync.” For OpenBSD, it’s just “pkg_add rsync.” NetBSD’s pkgsrc also maintains simple syntax and is portable to a variety of other operating systems.
The important principle is to minimize the operating system footprint, including daemons listening, applications installed, etc. If it’s a Tor relay, it should not be multi-user system, and not a file server, web server, etc. Use the default shell, use the base utilities as opposed to third-party applications, keep the attack surface minimized. On that final point, virtualization tends to increase that attack surface, not decrease it.
With a little time and patience, running a BSD relay shouldn’t be an insurmoutable task for any Linux user beyond those brand-new to computing. For someone comfortable in the shell, editing files, and so on, it is simple enough.
FreeBSD may very well be more widely used, but operating system usage statistics are wildly untrustworthy.
While all the BSDs aim to be standards compliant, OpenBSD is the most orthodox in this respect. Therefore, if software runs on OpenBSD and is accepted into their base or ports trees, porting that software to another POSIX-compliant operating system is easier. There are popular examples to mention, such as OpenSSH, arc4random, OpenNTPD and for those who only read Slashdot.org over the past year, LibreSSL is quickly gaining momentum as another piece of easily portable code from the OpenBSD project.
With a production-quality OpenBSD Tor Browser, porting to other BSDs or any other POSIX-based systems should be relatively trivial task.
New OpenBSD ports are developed against OpenBSD -current. To maintain versions for anything outside of -current at this point is beyond our resources, unfortunately.
TDP is not an official project of Tor. We are merely long-time Tor users and relay operators whose preferred platform is BSD Unix. We do maintain regular contact with Tor Project staff.
First, some definitions. There are several different but related software packages that are often confused or called by the same name:
Users with no deep technical knowledge might refer to the TBB as “Tor”, since from their point of view it is: if you install the TBB on a supported operating system and double click on the resulting icon you are “using Tor” in some generic sense.
Nonetheless this is not exactly accurate. If you are using the TBB
you are not only using their fork of Firefox ESR (as opposed to
whatever other version of Firefox you might have installed), you are
also using the version of the tor daemon that comes with the TBB (as
opposed to whatever other version you might have installed), the
firefox add-ons that ensure your web traffic is proxied via Tor
correctly (which come with TBB, not Tor Browser), other add-ons that
are recommended to ensure safe browsing over Tor (as opposed to
e.g. whatever version of the noscript Firefox add-on you might have
installed otherwise) and, potentially, many other small programs that
implement the different facets of the Pluggable Transports concept.
All of these things go together, although not all of them are used by
all TBB users. Many users never touch Pluggable Transports although
for some Tor would be completely unusable without it. For instance,
the meek Pluggable Transport components allow potential Tor users
behind the Great Firewall of China and other, similar systems to get
around governmental blocks to using Tor.
The TDP is porting the entire TBB to OpenBSD, not just Tor Browser. Our goal is to provide users of OpenBSD (for starters) with a complete set of components equivalent to TBB that provides all of the anonymity and privacy under OpenBSD that TBB gives users under Linux, OSX and Windows. This means not only the Tor Browser, but all of the add-ons that are required for it to function as designed and all of the external components that make up Pluggable Transports.
This blog post by one of the TDP project members summarized many of the issues and problems presented by the TBB in the context of OpenBSD, but for the sake of completeness we will summarize here.
At the risk of putting words in other peoples’ mouths, we can say with some authority that many current trends in software packaging and development leave a bad taste in the mouths of BSD users. Most of us would prefer that third-party installed on our machines used 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 trend towards software that phones home to check for updates or, worse, which automatically updates itself is also viewed with some alarm: such software certainly won’t be using the native OpenBSD mechanisms to do this phoning home or updating, since that’s not how things are done in OpenBSD ports.
Instead we would prefer to update our software by installing packages based on ports created by OpenBSD ports maintainers after they’ve properly vetted things, sorted out issues with dependencies, etc… Philosophically the idea is 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 is in line with the broader BSD philosophy that the operating system, C runtime library, compilers and toolchain used to produce them and third-party packages based on all of the above form an organic whole, not a pile of disconnected components. The core of any of the BSDs is not released or developed piece-meal.
All of the BSDs have settled on a model where third-party packages can be posed as “ports”. Although the ports systems on the various BSDs differ substantially, they have a common ancestor (FreeBSD’s original ports system) and a common goal: create a sane, well-documented mechanism that (nearly) any user can use to produce a native port of a piece of open-source software.
This is the end-goal of the TBB work.
18 MAY 2015: The only component of the TBB that is not finished is Pluggable Transports, which comprises several subcomponents and presents a few packaging challenges.
As for the rest our status is more or less still as described in this blog post: the OpenBSD ports are for version 4.0.8 of the TBB and include the Tor Browser itself, the torbutton and tor-launcher add-ons that are required for proper functioning of Tor Browser and the NoScript and HTTPS-Everywhere add-ons that are also used outside of Tor Browser but which are packaged with TBB. The exact NoScript configuration tweaks present in the TBB release are still not reflected in our ports.
We are working on moving to the latest release (4.5.1 as of this writing). Beyond that, the Pluggable Transport components must be finished and then we’ll have a complete set of TBB ports. We are not committing to dates for any of these milestones just yet but most of the hard work for everything but PT has already been done.
We have a long list of potential projects, some of which commenced years ago. This is a list in flux, and we only consider it a loose guide.
A Presence at BSD Events There are a number of BSD conferences that take place around the globe, such as BSDCan in Ottawa, Canada, AsiaBSDCon in Tokyo, Japan, EuroBSDCon, MeetBSD in California and which alternates with MeetBSD in Polska and finally NYCBSDCon in New York City. These are opportune places to interact face-to-face with the broader BSD community with presentations and birds-of-a-feather sessions (BoFs). To date, BoFs has been conducted at vBSDCon in the fall of 2013 and NYCBSDCon in February 2014. A very successful BoF was conducted at BSDCan in June 2014. There were around 50 people in the room during this lunchtime session, and many were running Tor relays. Considering just under 300 people registered for BSDCan, this was a huge accomplishment.
BSD Relay Configuration Video Tutorials Written tutorials are a useful medium for assistance in configuring BSD relays. For some, especially groups of people, professionally produced video tutorials are more appropriate.
Relay Guide Translations While English remains the de facto language of technical documentation, it is hardly the only language. We are looking to keep current translations of the ‘production’ versions of our relay configuration guides online and available. This could also increase the geographical diversity of the Tor network beyond its concentrations in the US, Canada and Europe.
High-Bandwidth BSD Relays An immediate way to diversify available Tor relay bandwidth is to operate several high-bandwidth relays. At a certain moment in May 2015, only two of the top thirty relays, in terms of bandwidth, are not running GNU/Linux. Both are running FreeBSD. Building and maintaining at least two high-bandwidth “bare metal” relays, one running OpenBSD and the other FreeBSD, with a minimum bandwidth of 20Mbps, would change this situation in the short-term. But we don’t aim to individually act as a band-aid to the diversity problem. These relays would allow further testing and optimizing of high-bandwidth Tor relays running BSDs, and ideally become a model for others.
Corporate Tor Relays While volunteer relays represent the majority of Tor nodes, we are approaching BSD-using firms to ask about them running high-bandwidth Tor relays on a BSD. Mozilla nows runs several relays as of December 2014. Firms have the staff, hardware and bandwidth to significantly contribute to the Tor network. Additionally, such firms further legitimize Tor and anonymous communications.
A FreeBSD Port of the Tor Browser Bundle After the OpenBSD Tor Browser port is completed, the next client software target would likely be be FreeBSD. Note that PC-BSD’s Kris Moore has created a “Tor-Mode” for their desktop’s browser.
We have additional ideas in consideration for TDP, and will regularly assess and reassess both old and new ones. Ultimately, TDP needs broader BSD community involvement of both users and developers to have the impact we are aiming for.
Copyright © 2018 by The Tor BSD Diversity Project (TDP). All Rights Reserved.
last updated: Tue Jun 13 19:25:38 2017 UTC