Cooking with Onions: Finding the OnionBalance
This blog post is the first part of the Cooking with Onions series which aims to highlight various interesting developments on the .onion space. This particular post presents a technique for efficiently scaling busy onion services.
The need for scaling
Onion services have been around for a while. During the past few years, they have been deployed by many serious websites like major media organizations (like the Washington Post), search engines (such as DuckDuckGo) and critical Internet infrastructure (e.g. PGP keyservers). This has been a great opportunity for us, the development team, since our code has been hardened and tested by the sheer volume of clients that use it every day.
This recent widespread usage also gave us greater insights on the various scalability issues that onion service operators face when they try to take their service to the next level. More users means more load to the onion service, and there is only so much that a single machine can handle. The scalability of the onion service protocol has been a topic of interest to us for a while, and recently we've made advancements in this area by releasing a tool called OnionBalance.
So what is OnionBalance?
OnionBalance is software designed and written by Donncha O'Cearbhaill as part of Tor's Summer of Privacy 2015. It allows onion service operators to achieve the property of high availability by allowing multiple machines to handle requests for a single onion service. You can think of it as the onion service equivalent of load balancing using round-robin DNS.
OnionBalance has recently started seeing more and more usage by onion service operators! For example, the Debian project recently started providing onion services for its entire infrastructure, and the whole project is kept in line by OnionBalance.
How OnionBalance works
Consider Alice, an onion operator, who wants to load balance her overloaded onion service using OnionBalance.
She starts by setting up multiple identical instances of that onion service in multiple machines, makes a list of their onion addresses, and passes the list to OnionBalance. OnionBalance then fetches their descriptors, extracts their introduction points, and publishes a "super-descriptor" containing all their introduction points. Alice now passes to her users the onion address that corresponds to the "super-descriptor". Multiple OnionBalance instances can be run with the same configuration to provide redundancy when publishing the super descriptor.
When Bob, a client, wants to visit Alice's onion service, his Tor client will pick a random introduction point out of the super-descriptor and use it to connect to the onion service. That introduction point can correspond to any of the onion service instances, and this way the client load gets spread out.
With OnionBalance, the "super-descriptor" can be published from a different machine to the one serving the onion service content. Your onion service private key can be kept in a more isolated location, reducing the risk of key compromise.
For information on how to set up OnionBalance, please see the following article:
OnionBalance is a handy tool that allows operators to spread the load of their onion service to multiple machines. It's easy to set up and configure and more people should give it a try.
In the meanwhile, we'll keep ourselves busy coming up with other ways to scale onion services in this brave new world of onions that is coming!
Take care until the next episode :)
Millions of users beg to differ, and the only thing that is dead is democratic ideals based on the actions of three letter agencies gone wild.
We should welcome a battle-scarred Tor network and browser being attacked constantly by the Feds, as it just pushes developments further e.g. onion balancing, increased scaling of the onion network, greater adoption by websites of .onions that solve the CA debacle, quantum computer-resistant cypher development, (eventual) padding of Tor traffic and more.
If the retards running major internet infrastructure and websites actually invested heavily in the Tor network and shifted operations to .onions, the Tor network can be the blueprint for the new and vastly improved internet that is required, because the http/https model right now is f**ked security-wise.
To extend your response to the OP:
Let us not forget that most if not all of the LE hacks we know about have been compromises on endpoint security (compromising the server at the application level, exploiting browsers and distributing a malicious payloads, or often both), and not at the transport layer. The biggest compromise of the Tor protocol I can think of off the top of my head was the CMU hack that abused the RELAY_EARLY flag. That one was serious indeed, and did result in some arrests, but these kinds of attacks seem relatively rare so far.
> Tor and Tor browser are not going anywhere,
I believe that increasing pressure will be placed on relay operators. They will become more liable for the traffic they carry. It may even become a crime to knowingly help others to remain anonymous.
I already carry a biometrically verified identification card with a number to use in online transactions. I believe it is planned that that number will be used as a login to access the Internet from within my country.
Unique, trackable, and revocable licenses that are necessary to get online are coming.