Run a private tor network using Docker

Jul 01 2016

I’ve made a scalable way of building a fully private functioning tor network using Docker. Why give any back story, if it’s useful to you, then here you go:


Docker Hub:


All you really need to do is clone the git repo, build the image (or download from Docker Hub) and then spin up a network to your liking. What’s nice about this is you can use the docker-compose scale command to build any size network that you want. Eventually, when in the next version of Docker you’ll be able to scale across multiple hosting providers. But the current RC is too sketchy to invest any time in.

Anyways, here’s how to spin up 24 node network. That’s 15 exits, 5 relays, 1 client, and 3 dir authorities.

Using It

To use this, there is a port listening on 9050 (you can change this in the docker-compose.yml file). If you point your browser to the Docker host running your containers and, in the same way you would connect to Tor, use it as a SOCKS5 proxy server, you will suddenly use it.

If you aren’t sure if it’s working, you check out the logs


Or, if you want to get cool information, try setting up a depictor container that will give you data about the DA’s.

Now what?

To answer the “now what?” question, this is a clean way of getting a tor network running so you can do your research, learn about how it works, modify configurations, run some third party tor software… whatever. If you’re not into this, there is always Shadow and Chutney or just manually configuring hosts/processes your self.

B-Sides Rochester: Plans

Jan 25 2016

It’s another year of BSidesROC, a local hacker con that we put together. Our sixth year actually. Not everyone really cares about how BSidesROC has changed over the years but it’s hard not to at least mention them for posterity and laugh at our failures.

I think that BSidesROC has evolved with the times or at least updated their memes. Year one was all about the memes and just messing around and to be honest, we didn’t care if anyone even showed up. We were going to have fun and hang out whether people attended. Today, here we are with a big group of organizers, 3 tracks of presentations, and hopefully even a keynote. We’ve gone from un-conference to regular conference and I think that’s OK. It’s what people told us they wanted.

After the fist year we started doing surveys to figure out what people actually wanted. Turns out a lot of people liked BSidesROC and looked forward to it, but didn’t really care about whether we made it an un-conference. I think we were trying so hard to make it like BSidesLV but really not that many people went to BSidesLV to care. So we built our own thing.

The Challenge of Finding Sponsors

There are inherent challenges with running a local con on a shoe-string budget. I say this every year, “We can’t do this without our sponsors.” I know this is a line that sounds robotic and everyone says it but I lack the ability to express this. It’s not the easiest thing for a bunch of hackers to go out and try to pitch this conference as something they want to advertise in. One quick story about someone that gets it though.

Secure NetworksIn the first year, Jason Ross and I were coming up with names of people we should talk to about sponsoring. We had seen this pretty awesome skull logo with keyboards, and concluded that whoever these guys were, they get “it”. (Honestly if you put skulls in anything I automatically want to be your friend.) So I nervously called Steve Stasiukonis (who I affectionately now call “Secure Steve”) and tried to give him my pitch. I don’t remember exactly what was said but it was something like this:

“Yeah, we’re like, a free and open hacker con and we’re all about having fun and we just want to build a hacker community…”

And he jumped in with, “Cool, but I’ll only do it if you make sure it’s not some kind of vendor fest. I’ll send you a check.”

This was the first time that I think someone figured out what we were trying to do and our first sponsor. Not only has he and Secure Network Technologies been sponsoring us for every year since, he’s given some of the most entertaining presentations, hooked us up with presenters, and provided us with gear.

The Horizon of 2016

Every year, we almost start from scratch. You may think we have some scripts that run like ./ --year=2016 graphics=random_meme.jpg  but we put a lot of time and effort to come up with something that we think is better than last year or meets our interests. Being at a big venue like RIT affords us some options in terms of better presentation equipment and grabbing local college kids and just makes us seem more “legit” somehow. I’m sure we’ll fix that, don’t worry. 🙂


The last few years we’ve had an anti-surveillance undertone that I think most of the industry has shared. This year, I’m stepping it up with an idea I call “Cryptobar.” It’s a dedicated area that attendees can go to learn how better to  lock down their gear and learn about the latest ultra-secure operating systems like Qubes and Subgraph.

New Designs

Last year was the first year we asked a local artist to build what they saw as a hacker con art piece. It was used on our shirts and badges and the entire process was a lot of fun. We’re hoping to do something similar this year.


I’m hoping that the people I’m talking to come through on a keynote. My underlying motive is to give students some perspective on the industry outside of what their school provides. We’ll see how it goes.


We have a new team working on the CTF this year. Hacker Battleship remains the theme but expect more interesting challenges that you’ve never seen before. Also expect more shell code exploits. 🙂

Actionable Visualizations And Silo Breaking

Dec 12 2015

This post on hackernews  got my attention. It’s a IoT based visualization showing your activities and health metrics. It’s very flashy and interesting looking, like you’re going to see it in an episode of CSI Cyber. The term “actionable” I’ve usually applied to government types discussing the latest threat intel but we can also take it to apply with our visualizations.

Actionable visualizations, should provides the viewer with brand new information that could not have been easily concluded before. This was a common problem with threat intel practices in years past. You would collect tons and tons of information and render it into a beautiful graph and then look at it and go, “Yup, there’s a graph of all the stuff I already knew.”

Street Corners

Along the lines of circular information collection, I’ve always thought that one of my generation’s problems is how easy it is to never have to listen to disparate positions. I’m able to hide in my corner of the Internet and learn about only the things that I need, and you sit in your corner and we never have to interact. It’s a perspective I took away from the book, Amusing Ourselves To Death.

In my city, like your city, there are lots of different meetup groups and interest meetups and meetups related to meetups. We have programming languages, maker group, security groups, whatever, and they all operate in their own “silos” to take a corporate reference. There are a few outliers that will cross-pollinate by visiting each of the groups when possible and we consider them community advocates.

Where am I going with this?

I’m part of a few groups that will often throw events. We’ll do classes or social events that are open to the public and we want to get the word out but you know what, I just end up telling my own silo about an event that they already knew just like the IoT visualization that tells me what time I ate dinner. How do I stop telling people (and myself) about information that we already know?

Thus, my tryst into visjs to attempt to apply some of the threat intel type relationship modeling (like Maltego) to community outreach. The goal being: (just like how social media analysts and intelligence operatives) try to identify “key influencers” in the area. I’m trying to identify various active communities to make sure that they’re involved when trying to do outreach.

Silo Sociogram

To self-criticize using my beginning premise, this is far from actionable at this point. I haven’t learned anything that I did not already know. I’ve sent out a comment to a few friends to try to expand this to get their perspective on relationships and see if 2600, Interlock, and other community groups might be able to try to break out of their own circular communications.

New Project:

Jul 22 2015

I don’t remember the exact conversation, but Jason Ross inspired me to buy, as in Drone + PWND = DRWND. I’ve owned it for a bit waiting for some specific data so that I could use it as an informational site about DRWN attacks. As IANA web developer, this has been interesting and terrible but simple enough to share.

I won’t assume the site makes any sense right now so I can summarize it like this:

  • It takes a data feed of all known locations of drone strikes and plots them
  • Circle size reflects the number of people killed
  • Circle color reflect the percentage of the deaths that were civilians and/or children in an RGB manner
    • Red – civilians
    • Green – expected targets or unknowns
    • Blue – children
  • For example the done strike in Pakistan that is purple reflects that people were mostly civilians and children

All this being said, the data comes from which attempts to be honest but there’s no way that it can be complete nor totally accurate.

Browser fingerprinting attack and defense with PhantomJS

May 18 2015

PhantomJS is a headless browser that when you use Selenium, turns into a powerful, scriptable tool for scraping or automated web testing in even JavaScript heavy applications. We’ve known that browsers are being fingerprinted and used for identifying individual visits on a website for a long time. This technology is a common feature of your web analytics tools. They want to know as much as possible about their users so why not collect identifying information.

Attack (or active defense)

The scenario here is you, as a privacy conscious Internet user, have taken the various steps to hide your IP, maybe using Tor or a VPN service, and you’ve changed the default UserAgent string in your browser but by using your browser and visiting similar pages across different IP’s, the web site can track your activities even when your IP changes. Say for instance you go on Reddit and you have your same 5 subreddits that you look at. You switch IP’s all the time but because your browser is so individualistic, they can track your visits across multiple sessions.

Lots of interesting companies are jumping on this not only for web analytics, but from the security point of view. The now Juniper owned company, Mykonos, built it’s business around this idea. It would fingerprint individual users, and if one of them launched an attack, they’d be able to track them across multiple sessions or IP’s by fingerprinting those browsers. They call this an active defense tactic because they are actively collecting information about you and defending the web application.

The best proof-of-concepts I know of are and the EFF’s Panopticlick project. These sites show what kind of passive information can be collected from your browser and used to connect you to an individual browsing session.


The defense to these fingerprinting attacks are in a lot of cases to disable JavaScript. But as the Tor Project accepts, disabling JavaScript in itself is a fingerprintable property. The Tor Browser has been working on this problem for years; it’s a difficult game. If you look through BrowserSpy’s library of examples, there are common and tough to fight POC’s. One is to read the fonts installed on your computer. If you’ve ever installed that custom cute font, it suddenly makes your browser exponentially more identifiable. One of my favorites is the screen resolution; This doesn’t refer to window size which is separate, this means the resolution of your monitor or screen. Unfortunately, in the standard browser there’s no way to control this beyond running your system as a different resolution. You might say this isn’t that big of a deal because you’re running at 1980×1080 but think about mobile devices which have model-specific resolutions that could tell an attacker the exact make and model of your phone.


There’s no fix. But like all fix-less things, it’s fun to at least try. I used PhantomJS in the past for automating interactions to web applications. You can write scripts for Selenium to automate all kinds of stuff like visiting a web page, clicking a button, and taking a screenshot of the result. Security Bods (as they’re calling them now) have been using it for years.

To create a simple web page screen scraper , it’s as easy as a few lines of Python. This ends up being pretty nice especially when your friends send you all kinds of malicious stuff to see if you’ll click it. 🙂 This is very simple in Selenium but I wanted to attempt to not look so script-y. The example below is how you would change the useragent string using Selenium:

Playing around with this started bring up questions like: Since PhantomJS doesn’t in fact have a screen, what would my screen resolution be? The answer is 1024×768.

This arbitrarily assigned value is pretty great. That means we can replace this value with something else. It should be noted that even though you set this value to something different, it doesn’t affect the size of your window. To defend against being “Actively Defended” against, you can change the PhantomJS code and recompile.

This will take a few extra screen resolutions every time a new webdriver browser is created. You can test it back at BrowserSpy.



And so on…

And we’ve now spoofed a single fingerprintable value only another few thousand to go. In the end, is this better than scripting something like Firefox? Unknown. But the offer still stands that if someone at Juniper wants to provide me with a demo, I’d provide free feedback on how well it stands up to edge cases like me.


Updates to Raspberry Bridge

Sep 21 2014

I’ve updated the Raspberry Bridge build to 1.5.1Beta to update a few things and address a couple issues. The main changes are:

  • updated Tor to latest stable release
  • updated obfsproxy
  • updated OS including some security patches

Download Torrent:

More info:

Meek Protocol

Sep 07 2014

The Meek Protocol has recently been getting a lot of attention since the Tor project made a few blog posts about it. Meek is a censorship evasion protocol that users a tactic called “domain fronting” to evade DPI-based censorship tactics. The idea is that using a CDN such as Google, Akamai, or Cloudflare, you can proxy connections (using the TLS SNI extension) so that if an adversary wanted to block or drop your connection, they would need to block connections to the CDN, like Google; mutually assured destruction. The goal being, a way of connecting to the Tor Network that is unblockable even from nation state adversaries.

SNI and Domain Fronting

SNI is a TLS extension that’s been around for about nine years, and has been implemented in all modern browsers at this point. This is the TLS version of virtual hosting where you send an HTTP request to a server, and inside is a request to another host. Similar to virtual hosting’s host headers, SNI provides a host inside it’s extension during the client hello request:

This would be a request to but the server receiving this request would look up the record to to see if it was fronted, and forward the request to that host.

You can try this using the actual Meek server that Tor uses:

You should get a response of “I’m just a happy little web server.” which is what the meek-server default response is.

In terms of Internet censorship, the idea of using SNI to proxy a request through a CDN is called Domain Fronting and AFAIK, is currently only implemented by the Meek Protocol. (That being said, the idea can apply to just about any other protocol or tool. I’ve seen other projects use Meek or something like it. ) What Meek provides is a way of using Domain Fronting to create a tunnel for any protocol that needs to be proxied.

Tor and Meek

The Meek Protocol was designed by some of the people involved with the Tor Project as one of the pluggable transports and is currently used to send the entire Tor protocol over a Meek tunnel. It does this using a little bit of infrastructure:

  • meek-client: This is what a client will use to initiate a tunnel over the Meek protocol
  • meek-server: corresponding server portion that will funnel requests and responses back over the Meek tunnel
  • web reflector: In its current form, this takes an SNI request, sees that it is a Meek request, and redirects it to the meek-server. This also makes sure that the tunnel is still running using polling requests.
  • CDN: the important cloud service that will be fronting the domain. The most common example is Google’s App-Spot.
  • Meek Browser Plugin: In order to make a meek-client request look like a standard SNI request (same TLS extensions) that your browser would make, a browser plugin is used.

Here’s a diagram of it all wrapped together:



This is how just a request is made to a Tor Bridge Node that’s running the meek-server software. Right now, if you download the latest Alpha release of the Tor Browser Bundle, this is how you could optionally connect using Meek.


You might notice, that due to the fact HTTP (by design) doesn’t maintain any kind of state to keep a connection open for as long as you would like to tunnel your Tor traffic, the Meek protocol needs to compensate. It does this by implementing a polling method where a POST request is sent from the client to the server at a specified (algorithmic) interval. This is the main way that data is delivered once the connection has been established. If the server has something to send, it’s done in the POST response body, otherwise the message is still sent with a 0 byte body.

Success Rate

You might notice that there are a few extra hops in your circuit and it’s true that there is a decent amount of overhead, but for those in China, Iran, Egypt or the ever-expanding list of other nations implementing DPI based blocking as well as active probing, this is the difference between being able to use Tor, and not. The benefit here is that if you’re watching the connection, you’ll be able to see that a client IP made an HTTPS connection to a server IP owned by Google or Akamai. You cannot see if TLS handshake decide to support the SNI extension, and you cannot see whether or not the client HELLO contained a SNI “server_name” value. Without this, the connection is indistinguishable from a request to say Youtube or Google.

As of now, there does not seem to be a lot (compared to all Tor users) of users connecting over the Meek bridge but it does seem to be increasing in popularity.


Updated Graph


While no known attacks exist (besides an adversary blocking the entire CDN), there are some potential weaknesses that are being reviewed. One of the interesting ones is if an adversary is able to inject a RST packet into the connection, the tunnel would collapse and not re-establish itself. This is unlike a normal HTTP/S request that would just re-issue the request, and not care. This may be a way of fingerprinting the connections over time but there would be a fairly large cost to other connections in order to perform an attack like this. The other attack of note is traffic correlation based on the polling interval. If the polling interval was static at, for example, 50ms, it would be fairly easy to define a pattern for the meek protocol over time. Of course that’s not the case in the current implementation as the polling interval dynamically changes. The other attacks and mitigations can be found on the Tor wiki page.

Resources: – main wiki page documenting how to use Tor with Meek – in depth explanation of the protocol compared to a standard Tor connection

Raspberry Bridge Project

Jul 13 2014

Over at, 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.


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.


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.



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




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.


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


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 »