41

Is it possible for multiple Tor clients, running on different machines or even networks, to publish the same Tor hidden service using the same private key to load balance requests between them?

Improve this question

6 Answers 6

Reset to default
23

Yes, but it may not provide the sort of load balancing you have in mind.

See http://archives.seul.org/tor/relays/Apr-2011/msg00022.html

The answer if two different Tors have the same hidden service private key is that they will each publish a hidden service descriptor. Whichever one published more recently is the one that a user accessing the hidden service will probably find and use.

This approach can provide a very crude load balancing. More interesting, it can also provide a very crude failover, where if one of them disappears, an hour or so later the other will publish and the hidden service will become reachable again.

Improve this answer
1
  • 2
    Multiple hidden-service instances can synchronize through side channels, such as openvpn through Tor. Alternatively, multiple hidden-service instances can serve merely as reverse proxies for the true hidden service.
    – mirimir
    Commented Sep 29, 2013 at 5:51
10

If your goal is load balancing, and the concern is the CPU usage of your machine, another option is to run the Tor Hidden Service on a machine with a load balancer like HAProxy installed. HAProxy will transfer the requests to one of several beefy webservers to handle the request, leaving the load balancer running (only) Tor and HAProxy.

Another thing to note that hidden services have authentication built into the hidden service address, and the link is encrypted end-to-end, so running SSL over hidden services is unnecessary.

Improve this answer
4

Running multiple Tor instances with the same private key will not provide reliable load balancing as normally only one instance descriptor is listed in the Tor hidden service DHT at a time.

However I've created a tool named OnionBalance which allows Tor hidden services to be load balanced at the Tor protocol level. By working at the Tor level, hidden service requests can be distributed between up to 60 back end Tor instances while removing single points of failure.

OnionBalance works analogously to round-robin DNS for Tor where OnionBalance is updates the A records. However the actual implementation is quite Tor protocol specific. The DNS system is not involved at all.

Multiple instances of OnionBalance with the same configuration and keys can be run simultaneously. By running instances in separate physical locations you can have fully redundant Tor onion service hosting.

Using a traditional load balancer like HAProxy behind a Tor hidden service will be limited by the rate of traffic through the single core Tor process.

OnionBalance is now available in the Debian Jessie backports repository so it should be easy to get started with.

Improve this answer
2
  • 2
    How does OnionBalance remove a single point of failure? Would it be more accurate to say that the single point of failure is now the server running OnionBalance?
    – IceyEC
    Commented Jul 29, 2016 at 14:06
  • This is the only answer that actually answers the question of how to load balance a hidden service across several tor processes. OnionBalance is still maintained in 2020, and now supports v3 onions.
    – Steve
    Commented Oct 18, 2020 at 16:22
3

If you wanted to host a hidden service on multiple servers each with different introduction points then couldn't you have each hidden-service instance publish their own set of hidden-service descriptors? You could distinguish between them by assigning each instance a different set of replica numbers to use when generating hidden service descriptor-ids.

Although now that I think of it there would probably be problems with the clients not knowing how many replicas there are (think it's currently hardcoded to 2).

Improve this answer
3

I know that the #1 answer to this question is from arma himself, one of the creators of the Tor protocol, but he is wrong.

While the current Tor code does not support load balancing, the protocol itself allows for it. For example, a single node could handle the "announce" part and then delegate the actual "rendezvous" to other nodes.

He is, however, correct in describing what will happen with the current implementation: one will be chosen as primary node and the other will serve as a backup. But that's not something a bit of coding can't fix.

Improve this answer
0

File hosting could in theory be done distributedly by using Tahoe-LAFS: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2144

Improve this answer
1
  • Please provide some detail on how one might actually set this up.
    – Andrew Lott
    Commented Dec 29, 2013 at 7:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .