Raspberry Bridge Project

Jul 13 2014

Over at rbb.antitree.com, you’ll see the details of a new project of mine: To build a Raspberry Pi environment to make it easy for anyone to run a Tor Bridge node. The goal here has been to release an RBP image that is minimalist (in terms of storage consumption as well as resource consumption) and provides the necessary tools to run and maintain a Tor Bridge Node on a Raspberry Pi.

Bridges

A reminder, a Bridge Node is a type of Tor node (like relay, exit, entry) that is a way of evading censorship to join the Tor Network. This is done by secretly hosting bridges that are not shared with the public so there’s no way for a censoring tool to merely block all Tor nodes. On top of that, an Obfuscated Bridge is one that further defends against various fingerprinting attacks of the Tor protocol. With an obfuscated bridge, communications from the client to the bridge appear to be benign traffic rather than Tor traffic.

Challenge Installing Tor

It’s odd how less-than-simple the process of running a relay on a Pi is. If you want to run a relay on a RBP, some sites will merely say install Rasbpian and run apt-get install Tor. The problem with this is that the Debian repos are very far behind from the latest version of Tor (like at least one major revision behind). The logical conclusion would be to use the Tor Project’s debian repo’s then. The problem here is that there are no repos for Rasbperry Pi’s ARM architecture. One solution was to use something similar to the Launchpad PPA hosting that lets you run a simple repo to deliver a .deb package. But launchpad does not support ARM architecture (and doesn’t seem to plan to do so in the near future).

So the result is I’ve built a github repo that hosts the Tor .deb packages for the latest stable release. It’s not pretty, but it does the job and I know that it will work well. That was the first piece of the puzzle.

Host Hardening

The Raspberry Pi images out there are designed for people that want to learn programming in Scratch and play with GPIO pins for some kind of maker project. They’re not ideal for providing a secure operating environment. So I built a Debian-based image from the ground up, with the latest packages and only the required packages. I’ve customized the image to not log anything across reboots (mounting /var/log as a tmpfs). You can read most of the design of the OS here.

I’ve also secured SSH (which many of the Raspberry Pi images don’t do) by autogenerating SSH keys the first time it’s boot. The alternative is to ship an image that has the same SSH keys allowing MITM attacks. Again, these images are designed for makers.

Torpi-config

The part I spent the most time on, and is hopefully the most useful, is I took the structure of the raspi-config tool that is shipped with Raspbian, and I convirted it into a Tor configuration tool. This will give you a text-based wizard to guide users through configuring Tor, keeping obfsproxy up-to-date and perform basic systems administration on the device.

screen1[1]

Roadmap

It’s fully functional but there are a lot of things I’d like to improve upon. I’ve released it to solicit feedback and see how much more effort is necessary to get it where I want. Here are some of the other items on the roadmap:

  • Add the ability to update Tor to the latest stable release over github (securely)
  • Improve torpi-config to cover other use cases like configuring WiFi or a hidden service
  • Print out the specific ports that need to be forwarded through the router for the obfuscated bridge
  • Clean up some of the OS configuration stuff

 

 

XKeyScore

Jul 05 2014

If you’re like me, you’re probably getting inundated with posts about how the latest revelations show that NSA specifically tracks Tor users and the privacy conscious. I wanted to provide some perspective of how XKeyscore fits into an overall surveillance system before jumping out of our collective pants. As I’ve written about before, the Intelligence Lifecycle (something that the NSA and other Five Eyes know all to well) consists more-or-less of these key phases: Identify, Collect, Process, Analyze, and Disseminate. Some of us are a bit up-in-arms, about Tor users specifically being targeted by the NSA, and while that’s a pretty safe conclusion, I don’t think it takes into account what the full system is really doing.

XKeyscore is part of the “Collect” and “Process”  phases of the life cycle where in this case they are collecting your habits and correlating it to an IP address. Greenwald and others will show evidence that the NSA’s goal is to, as they say “collect it all” but this isn’t a literal turn of phrase. It’s true there is a broad collection net, but the NSA is not collecting everything about you. At least not yet.  As of right now, the NSA’s collection initiatives lean more towards collecting quantifiable properties which have the highest reward and the lowest storage cost. That’s not as sexy of a phrase to repeat throughout your book tour though.

52164288[1] OR 52164332[1]

 

The conclusion may be (and it’s an obvious one) what you’re seeing of XKeyscore is a tiny fraction of the overall picture. Yes they are paying attention to people that are privacy conscious, yes they are targeting Tor users, yes they are paying attention to people that visit the Tor web page. But as the name implies, this may contribute to an overall “score” to make conclusions about whether you are a high value target or not. What other online habits do you have that they may be paying attention to. Do you have a reddit account subscribed to /r/anarchy or some other subreddit they would consider extremist. Tor users aren’t that special, but this section of the code is a great way to get people nervous.

As someone who has worked on a collection and analysis engine at one time, I can say that one of the first steps during the collection process is tagging useful information, and automatically removing useless information. In this case, tagging Tor users and dropping cat videos. It appears that XKeyscore is using a whitelist of properties to what they consider suspicious activity, which would then be passed on to the “Analysis” phase to help make automated conclusions. The analysis phase is where you get to make predictive conclusions about the properties you have collected so far.

intel_lifecycle_xkeyscore

Take the fact that your IP address uses Tor. Add it to a list of extremist subreddits you visit. Multiply it by the number of times you searched for the phrase “how to make a bomb” and now you’re thinking of what the analytics engine of the NSA would look like.

My point is this: If you were the NSA, why wouldn’t ‘you target the privacy aware? People doing “suspicious” (for some definition of the word) activities are going to use the same tools that a “normal” (some other definition) person would. We don’t have a good understanding of what happens to the information after it’s been gathered. We know that XKeyscore will log IP’s that have visited sites of interest or performed searches for “extremist” things like privacy tools. We know that there have been cases where someone’s online activities have been used in court cases. But can’t connect the dots.  XKeyscore is just the collection/processing phase and the analytic phase is what’s more important. I think the people of the Tor Project have a pretty decent perspective on this. Their responses have generally just re-iterated that this is exactly the threat model they’ve always planned for and they will keep working on ways to improve and protect its users.

 

 

Private Tor Network: Chutney

Apr 15 2014

Chutney is a tool designed to let you build your own private Tor network instance in minutes. It does so by using configuration templates of directory authorities, bridges, relays, clients, and a variety of combinations in between. It comes with a few examples to get you started. Executing this command, for example

will build a ten client network made up of three directory authorities, five relays, and two clients. Each of which have their own TORRC file, their own logs, and in the case of the relays and authorities, their own private keys. Starting them all up is as easy as

Capture

So bam! You’ve created a Tor network in less than a few minutes. One item to note, the configuration options in the latest version of Chutney use initiatives like “TestingV3AuthInitialVotingInterval” which require you to have a current version of Tor. In my case, I compiled Tor from source to make sure it included these options.

Building custom torrc files

It’s first job during configuration is to build a bunch of torrc files to your specification. If you tell it you’d like to have a bridge as one of your nodes, it will use the bridge template on file, to create a custom instance of a bridge. It will automatically name it with a four digit hexadecimal value, set the custom configuration options you’ve dictated, and place it into its own directory under net/nodes/.

The very useful part here is that it builds an environment that is already designed to connect between one-another. When you create a client, that client is configured to use the directory authorities that you’ve already built and that directory authority is configured to serve information about the relays you’ve built. The real value here is that if you were to do this manually, you’d be left to the time consuming process of manually configuring each of these configuration files on your own. Do-able, but prone to human errors.

Running multiples instances of Tor

Chutney builds a private Tor network instance by executing separate Tor processes on the same box. Each node is configured to specifically be hosted on a certain port, so for a ten node network, you can expect 20 more more ports being used by the processes.

CaptureUse case

Chutney is perfect for quickly spinning up a private Tor network to test the latest exploit, learn how the Tor software works, or just muck around with various configurations. Compared to Shadow which focuses more on simulating network events at a large scale, Chutney is more of a real-world emulator. One weakness is that it is not a one-to-one relationship between The Tor Network’s threat model and a Chutney configured one. For example, the entire network is running on a single box so exploiting one instance of Tor would most likely result in the entire network being compromised. That being said, depending on your needs, it offers a great way of  building a test environment at home with limited processing power. It’s still a rough-cut tool and it sounds like NickM is looking for contributors.

 

Older »