On 31 Jan 2016 11:07 a.m., "Fabio Pietrosanti (naif) - lists" < lists@infosecurity.ch> wrote:
Regarding massive scale deployment, there is this limit actually https://trac.torproject.org/projects/tor/ticket/15251https
https://trac.torproject.org/projects/tor/ticket/15251:// https://trac.torproject.org/projects/tor/ticket/15251trac.torproject.org https://trac.torproject.org/projects/tor/ticket/15251/projects/ https://trac.torproject.org/projects/tor/ticket/15251tor https://trac.torproject.org/projects/tor/ticket/15251/ticket/15251 https://trac.torproject.org/projects/tor/ticket/15251
That's a really interesting issue.
I have not considered a use-case where a single daemon would have possibly many hundreds, if not thousands, of Onion addresses.
I can't see a short or medium-term use-case for a single daemon serving 1000s of Onions (compare: how many servers with thousands of specific, enumerated IPv4 addresses?) but with Prop224 and changes in use-case (messaging gateways) certainly it can't be ruled out.
The model I'm most interested in is simpler: a modest number of high-throughput addresses, perhaps each served by an independent daemon, publishing a shared address with OnionBalance.
This is quite similar to popular DSR (Direct Server Return) loadbalancing architectures.
Especially if tvdw's work in rendezvous-handoff works out okay, then this seems a good medium-perhaps-long-term strategy for web service deployment on Onions. Likely OnionBalance on its own would suffice for a year or more.
-a
- web-server config
I feel that on Apache there should be an application module, like mod_tor, that once enabled will allow to do something like "OnionService on" in the <VirtualHost> directive, having the rest happening in a auto-magic way.
That's awesome! I look forward to seeing it.
-a