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/15251>https <https://trac.torproject.org/projects/tor/ticket/15251>:// <https://trac.torproject.org/projects/tor/ticket/15251>trac.torproject.org <https://trac.torproject.org/projects/tor/ticket/15251>/projects/ <https://trac.torproject.org/projects/tor/ticket/15251>tor <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