[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] scaling .onion site?
> Hypothetical further idea:
> - Server A is reachable through a.onion. This is the domain which every
> user has to know and which every user is supposed to use.
> - On server A runs only a load balancer.
> - The load balancer redirects the client to server B, server C or server
> D etc.
> - Server B, C, D etc. run in other locations, on different physical
> servers on other networks and have their own b.onion, c.onion, d.onion
> address etc.
> - Those servers B, C, D. etc. serve the actual content.
> Does that sound useful?
> How could server B, C, D. etc. show the a.onion domain, to have only one
> domain and to unconfuse users?
There's a couple of problems with this approach:
* HAProxy doesn't know how, nor do I think nginx would know how to
resolve and send traffic to a .onion domain
* The amount of time required to negotiate an HTTP request being proxied
from A.onion -> B.onion and then sending a request from B.onion ->
A.onion -> Client would very likely brush up against HTTP timeouts (120s)
I'm not sure what additional security or "enhancement" one might get from
such a set up, other than being able to have [B/C/D].onion behind NATs in
different locations. You could more efficiently solve that problem by
using SSH tunneling, but that would give an outside observer knowledge
that there is some kind of a link between A <-> B/C/D.
This reminds me of a common practice used in the "standard web" which is
using DNS round robin and overloading a domain such as google.com with
multiple A records. Unfortunately, Hidden Services have no such concept
(as far as I know) of having multiple endpoints responding to the same
domain name, otherwise your A/B/C/D set up could work a lot better.
>> I decided to create a (hopefully) simple guide to help you here:
> Nice. Please state license of that document and please add license file
> to that github repository.
tor-talk mailing list