Here’s a cheat sheet that I wrote up for myself about two weeks ago after I’d gotten my bearings with the basics of Tor.  I actually wrote it as an informal status update to my mentor and realized that if it was helpful to me, it might be helpful to someone else.  If you see any errors, don’t be shy about setting me back on the right path!

First, though, please bask in the glory of this super awesome clickable graphic that demonstrates what network traffic is and isn’t obscured by Tor and HTTPS (encrypted HTTP).  This snippet below is just a teaser.  Click it to go to a page where you can click buttons for Tor and HTTPS and see how they work.

After a visit to the OTI offices and an overview of Commotion with my project mentor Will Hawkins, I felt like the fog had parted a bit on the Commotion side so I moved over to get the same level of clarity with Tor.  That’s most of what I did that week.  The Tor IRC channel has been unexpectedly not-unpleasant and I have a basic grasp of the vocabulary and principles.I learned that all Tor-enabled machines use the same code, and they are differentiated by changes to the config file.  All Tor network participants (machines running Tor) are either clients or relays. Clients just connect to a stable entry, or “guard” node, and get on their merry way.

As for the rest, all relays are entry relays; some entry relays are guards (once they are proven to be stable via analysis of a descriptor that is pushed from the node once an hour); some entry relays are unlisted (therefore not publicly known) and they are called bridges; and finally only a relative few Tor nodes are configured as exit nodes.  Exits have specific policies that allow and disallow traffic to various places, allowing exit node operators to be choosy about what kind of activity they allow on their node.  Relevant ports on *nix machines include 9001 (data) and 9030 (directory).

         Tor
        /   \ 
  Client     Relay (Entry)
            /      |      \
        Guard    Bridge    Exit
   (if stable)  (unlisted)  (configurable rules)

I learned about verifying that your Tor relay is working correctly.  The easy way is to go to check.torproject.org and see if it says that you are routing through the Tor network.  But all it does is check whether you arrived at that page from one of the published exit nodes.  You can find the code in SVN here, and the code for a newer TorCheck utility is on Github.  Digging a little deeper, you should see Tor running if you do a ps -ef, and your Tor log file should have something to say about whether it is running properly or not.  More on logging and *nix behavior in a later post.

I looked at a list of ISPs that are Tor-friendly and Tor-unfriendly.  I found that mine probably is friendly, i.e., it was before it was acquired (twice).  But in talking to folks on IRC I was reasonably well assured that for the purposes of testing, especially if I’m running a bridge, I should be fine.

Before I came to that conclusion I kind of spun off into a swirl of what-ifs, wondering how safe it was to test Tor on my home IP.  I thought through scenarios where I might test on a hosted server, on a new and separate Internet connection to my house, and internally on a fake network of physical or virtual machines in my house.  I may revisit those options once I’m really moving with testing, depending on how informative I think my testbed seems to be, and for what use cases.