Delivery-Date: Wed, 16 Jul 2014 14:42:03 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 200931E01A3
	for <archiver@seul.org>; Wed, 16 Jul 2014 14:42:01 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id E85432F87C;
	Wed, 16 Jul 2014 18:41:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 25AC62F852
 for <tor-talk@lists.torproject.org>; Wed, 16 Jul 2014 18:34:25 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ggoGQZRVD3vp for <tor-talk@lists.torproject.org>;
 Wed, 16 Jul 2014 18:34:25 +0000 (UTC)
X-Greylist: delayed 1659 seconds by postgrey-1.34 at eugeni;
 Wed, 16 Jul 2014 18:34:24 UTC
Received: from server4.tvdw.eu (lauravdw.com [IPv6:2001:1af8:4100:a00d:4::2])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id EB9922ECD2
 for <tor-talk@lists.torproject.org>; Wed, 16 Jul 2014 18:34:24 +0000 (UTC)
Received: from g124058.upc-g.chello.nl ([80.57.124.58]
 helo=Toms-MacBook-Pro.local)
 by server4.tvdw.eu with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128)
 (Exim 4.82) (envelope-from <info@tvdw.eu>)
 id 1X7TbC-00030K-Og; Wed, 16 Jul 2014 20:06:38 +0200
Message-ID: <53C6BF2B.1010808@tvdw.eu>
Date: Wed, 16 Jul 2014 20:06:35 +0200
From: Tom van der Woerdt <info@tvdw.eu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org, fosforo@gmail.com
References: <CAH8ZuZqbovDWFz2ngeHOb0TZyEAwbhiuoPmKFJBUVSmGib7tyQ@mail.gmail.com>
In-Reply-To: <CAH8ZuZqbovDWFz2ngeHOb0TZyEAwbhiuoPmKFJBUVSmGib7tyQ@mail.gmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Escalating hidden services
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Fosforo schreef op 16/07/14 14:15:
> I am a big fan of pinkmeth hidden service ( hxxp://pinkmethuylnenlz.onion/ )
>
> But it constantly times out.
>
> As an unix administrator, I was thinking in ways to escalate such good
> public services through normal clusters, and would like opinions if my
> approach is valid, to suggest it to the unknown author:
>
> 1) Frontend - Only 1 node. Entry point as normal "semi-hidden" hidden
> service with 32 guards (exposed, semi-hidden)
> 2) Backend - X number of nodes  (escaling is here) numbers of backend
> hidden services with 3 guards
>
> 1) is just a relay box, nginx with reverse connection to backend hidden
> services, in a different structure than backends. round robin. 32 guards to
> handle good speed and lots of circuits. anonymity is not a requirement
> here. each backend hidden service is a local port in 127.0.0.1 made with
> torified netcat (I think there are better approaches than netcat, would
> like to know )
>
> 2) apache+mysql each node, gfs filesystem (for static files) shared among
> nodes, replicated mysql database.
>
> I see latency as a problem here [ user -> nginx (hidden) -> apache (hidden)
> ], but I dont see more timeouts. thoughts?

I think that, depending on the specific case (I don't know this 
'pinkmeth'), there are some far better solutions for this :

* Find a better network for the servers and instead of doing 'nginx -> 
tor -> apache' just go 'nginx -> apache'. You can of course still use 
SSL to encrypt the data inbetween. This reduces a lot of latency.

* Rather than putting everything on a single domain, just put only the 
HTML on the primary .onion domain and put all static content, such as 
stylesheets, videos and images, on a different server. You could scale 
the static content part really well by just returning one of several 
.onion domains that all have your static content. Give the user a small 
cookie that can be used to make sure the same static server is always 
used for the same user.

* As far as I can tell nothing in the hidden service spec really blocks 
you from load balancing a single HS address across multiple nodes. If 
you run 3 nodes, tell 1 of them to handle the introductions, and have 
this node communicate with the other nodes which then handle the 
rendezvous part. It might need some hacking in the Tor code, but this 
should scale for several gigabits very nicely.

Tom


PS: These three are just some solutions I came up with just now - they 
might not even work.

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

