Chris MacNaughton currently works at Lambda, working on public cloud and focusing on automated testing and storage. Previousle, he worked at Canonical, leading the Ceph Engineering team and focusing on improving testing as well as making Ceph easier to deploy and consume.

2 minute read

Why Use a Hidden Service?

While building TorSearch, I have encountered some interesting reasons why Hidden Service owners would create and run a hidden service. The primary argument I’ve seen for running a web service as a hidden service is so that the owner can maintain anonymity. Given my tendancy to talk about TorSearch, I’m clearly not doing it for the anonymity.

What other reasons could there be for running a service as a hidden service? Personally, I’m taking advantage of Tor’s hidden service architecture to allow Tor users to search Tor without their traffic leaving the Tor network. Additionally, by only supporting Tor to connect, I gain the encryption that Tor hidden services use without having to setup and use SSL certificates.

Challenges

The decision to provide access to TorSearch through a hidden service has brought its own set of challenges. One of my largest challenges has been how to properly setup a highly available web service. With a traditional web service, I coud setup round-robin DNS or even broadcast an IP address from several different data centers to ensure availability even in the face of some trouble.

Availability

With a Tor hidden service, I cannot get around needing to run a single instance of Tor on a single internet connection to broadcast my hidden service descriptors. The best solution that I have found for handling hidden service load is to have a server running Tor and a proxy server, in my case Nginx, that distributes load to N backend application servers.

While I would like to have multiple instances of Tor to distribute the incoming load, the Tor service has been fairly reliable and capable of serving plenty of connections. Nginx also has had no issues handling the requests but it is possible that one of these pieces may have issues if the load gets high enough.

Latency

Running a Tor hidden service comes with an undeniable cost in network latency that isn’t present for most web applications. While my appplication can serve non-Tor requests in under 1 second, the average request to my application finished in around 6.5 seconds due to the network time.

Because of the high network time, I have to consider asset size dramatically more than more modern web application do because the Tor network tends to serve hidden services at something barely more than dial-up.

Marketing

How do you market something that a large protion of the people who would pay for your service can’t access (without extra work)? Considering that I am trying to make TorSearch profitable for me by selling pay per click advertising, I need for companies that are interested in advertising to be able to access my advertiser interface; therefor, I am finally announcing the new TorSearch.es!

Let me know your thoughts in the comments!

Updated:

You May Also Enjoy

Namespacing Zaza

3 minute read

TLDR: Almost1 all of the actual charm tests have been removed from Zaza and moved to a new package in the openstack-charmers namespace: zaza-openstack-tests....

Adding Zaza Tests to a Charm

6 minute read

Migrating from Amulet to Zaza can seem like harrowing experience, but it doesn’t have to be! In this post, we will take a charm written with Amulet tests and...

Security Scanning Rust Dependencies

less than 1 minute read

Gitlab has added support for dependency scanning to their CI system. The recommended method for enabling this support is to enable their CI step that detects...

Rust CI on Gitlab

1 minute read

Setting up Rust CI on Gitlab is a fairly easy task, until you want to actually use it ;-) Throughout my time developing Rust libraries and applications, I’ve...