OnionUp: Uptime Checker for Tor Onion Services

GitHub | Live

As an extension to the Tor project, three collaborators and I built a tool to automatically check the ping response and load time of Tor hidden services (.onion sites).

Description

Onion services are websites that are accessible through the Tor anonymity network. These services are gaining popularity among journalists and people in repressive countries. In fact, major companies like the New York Times and Facebook recently launched Onion services for their content. By going through Tor, users gain superior encryption relative to unencrypted, or “clearnet,” websites. In order to maintain anonymity, there are certain tradeoffs Tor users are accustomed to. Onion services are much slower than their clearnet counterparts and they go offline frequently. Thus, Tor users would benefit from a utility to check which sites are online before they devote a substantial amount of time and effort connecting. OnionUp is a Pingdom-inspired uptime checker that displays the health of both Onion services and clearnet websites. As an added feature, OnionUp allows users to easily keep track of their favorite Onion services. You can also see handy metrics like average load time, maximum response time, etc.

Metrics!

Project Details

The idea for this project came from asking an experienced Tor user and cyber security advocate what we could do to help the Tor project. He pointed us to the service Pingdom and explained that it would be nice to have that  utility for Tor. After all, it takes a ton more effort to load up a hidden service, so a user dashboard with all your Tor sites would be phenomenal. We sketched out a rough outline of the models: users have many sites, sites have many pings, and got to work filling out the details. After a lot of trial and error with the ruby gem Socksify, we eventually pulled together a proof of concept bare-bones rails app.

(It looked nothing like this…)

A few weeks later, we decided to revisit this project and ‘build it right.’ The biggest issue with the initial application was pinging multiple sites simultaneously. To solve this, we leveraged ruby’s ability to add multiple ‘workers’ to run tasks concurrently (or is it “in parallel?”). The other issue was the cookiecutter 90s looking HTML we hadn’t bothered to style.

We took this opportunity to build out a Single Page App (SPA) using Vue with Vuex for state management. This had the benefit of 1. keeping state manageable, 2. helping us work on separate tasks simultaneously, and 3.  preventing pull requests from causing merge conflicts. We had all built projects with React + Redux before, so it did not take long for us to integrate Vue into this project. The bigger (and unforeseen) roadblock was getting Yarn and webpacker, not webpack, configured properly. It wasn’t until we had to push this to our EC2 instance that we actually started to understand out how the Rails 5.1 webpacker  gem was handling our asset pipeline.

We also popped in the Vuetify plugin to get some fancy spinner animations, important because Tor sites take forever to ping.

Ignore the weird jump at the end

Conclusion 

At its current state, there are still so many things we want to do. Currently, sites come in batches. It would be much nicer if sites updated as soon as they respond, not once the slowest site responds. If Pingdom’s ginormous userbase is any indication, there’s plenty of demand for this tool.

Leave a Reply

Your email address will not be published. Required fields are marked *