Thursday Sep 24, 2009

The Onion Router (Tor) in OpenSolaris

Build 116 (back in June, 2009) the Onion Router software was put into OpenSolaris (Tor) as the SUNWtor and SUNWtor-root packages.  Quoting from the Tor website :



Tor is especially relevant today in countries that heavily censor internet usage and traffic.  It allows one to browse anonymously and obscure your location as well as your destination.    There are 2 sides to the  use of Tor - using it as a client to obscure your internet activity, or running a relay to add to the tor network.  If you want to anonymize your own browsing and NOT run as a relay, you can install the torbutton Firefox extension and start browsing anonymously.  Note that your pages will load much slower since your data is passing through various Tor relay nodes located all over the world.

The packages that were put into OpenSolaris allow you to set up your OpenSolaris system as a tor relay node and thus allow others from around the world to relay traffic through your system.  Installing and running a Tor relay on OpenSolaris is very easy:

  1. install the SUNWtor and SUNWtor-root packages if they are not already on your system.
  2. Edit /etc/torrc and make any desired changes.   This configuration file only needs minor modifications from its default installation profile to make it useful.   You will probably need to change the following parameters:
    • Nickname - give your node a unique name.  This does not have to be a hostname, it can be a nonsense word, a funny name, or anything you want.  It is used to uniquely identify your relay node and is useful to use when you want to check on the various Tor relay node status pages to see if your system is properly registered.
    • RelayBandwidthRate, RelayBandwidthBurst - These 2 parameters allow you to limit how much bandwidth your relay will be allowed to consume.
    • ExitPolicy - If you don't want your relay node to be the final stop before the end user connects to a site (making your tor node IP the one that the website records), set up a "no-exit" policy by setting the ExitPolicy to be "reject \*:\*".  There are other examples of ExitPolicy entries in the config file and also on the tor website.
    • HardwareAccel - This is particularly useful on SPARC Enterprise T2 systems with the Niagara 2 processor.  When this is enabled (set value to "1";), the Tor relay will take advantage of the AES encryption provided by the onboard cryptographic module which results in a huge performance boost for the code that is encrypting the relaying the data between nodes, thus allowing your node to process more data much faster.  See the "Enhanced Crypto Support" section below for more details.
  3. Start the tor relay node using SMF (as root): $ svcadm enable tor
  4. That's it!

Once your relay is configured and started, you can use a tor node status page such as this one - to see if your node is recognized and registered (search for your node using the Nickname you provided when you configured it (step 2 above).

Enhanced Crypto Support for Tor in OpenSolaris

As mentioned above, when Tor was being integrated into Solaris, a couple of enhancements were applied to the code to allow it to take advantage of the Solaris Cryptographic Framework. Specifically, when the "HardwareAccel" option is enabled, the tor code will check to see if the AES CTR mode mechanism is supported by the crypto framework.  If so, it will use the crypto framework APIs (PKCS#11) to perform the AES encryption and decryption operations.   Normally, the AES crypto is done in software either using OpenSSL or a native implementation of AES.   Because the current OpenSSL encryption in Solaris does not support AES CTR mode in hardware, the standard Tor encryption operations see no benefit from the HardwareAccel option on the Niagara 2 systems.  The additional PKCS#11 crypto support was added to the Tor code in order to provide access to the hardware accelerated crypto engine.  As a result, when running on a system with hardware support for AES CTR mode such as the Sun SPARC Enterprise servers with Niagara 2 chips (T51XX, T52XX, etc)  the results are significant (an improvement of 25x or more was observed while running the relay in a live environment on an internet facing server.

I suggest configuring a local zone and dedicating it for the tor service.  This allows it to have it's own IP address and additionally gives the  administrator more control over the resources that the relay node is allowed to consume.  The tor configuration file allows you to limit the bandwidth, but by putting it in a container, you also get the ability to control other factors such as memory use, cpu use and privileges.

I documented the work done and the results in a brief paper that can be downloaded here.




« July 2014