Delivery-Date: Sun, 08 Mar 2015 20:27:37 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD,URIBL_BLOCKED
	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 48B801E0BCB
	for <archiver@seul.org>; Sun,  8 Mar 2015 20:27:35 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id F035433B63;
	Mon,  9 Mar 2015 00:27:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 3293833B62
 for <tor-talk@lists.torproject.org>; Mon,  9 Mar 2015 00:27:26 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
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 5qwNiaT56d4k for <tor-talk@lists.torproject.org>;
 Mon,  9 Mar 2015 00:27:26 +0000 (UTC)
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com
 [162.222.225.14])
 by eugeni.torproject.org (Postfix) with ESMTP id 1108133B5F
 for <tor-talk@lists.torproject.org>; Mon,  9 Mar 2015 00:27:26 +0000 (UTC)
Received: from [0.0.0.0] (exit2.telostor.ca [62.210.74.186])
 (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 (Authenticated sender: s7r@sky-ip.org)
 by outbound.mailhostbox.com (Postfix) with ESMTPSA id 044561A1467
 for <tor-talk@lists.torproject.org>; Mon,  9 Mar 2015 00:27:11 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org;
 s=20110108; t=1425860843;
 bh=4OJRMrwRVgpBolcKhOo13lrUDNZiUnQunWTVHLNXwyA=;
 h=Date:From:Reply-To:To:Subject;
 b=It983y/NDpFJVsR+rAZkLIRumxoNtjhRbqds7xHUJ0NyElLucQM3lLc806nHZyKLj
 eNFxvJpoDyU0KVgKcjv1cVFREq6VobKHJxWVcASGM3LAP+2dtLqa08vouMs5VALUCH
 Xnx7srHFtxR3m3AXZJieK4CQRr7EOWjavS6ECJ7g=
Message-ID: <54FCE8DA.2030905@sky-ip.org>
Date: Mon, 09 Mar 2015 02:27:06 +0200
From: s7r <s7r@sky-ip.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92
Subject: [tor-talk] possible solutions for increasing the capacity of a
	Hidden Service
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

When operating a high-usage Hidden Services 2 things are needed to
'tweak' the performance and enable it to handle more concurrent clients:

Increase NumEntryGuards to 3 or 5
Increase MaxClientCircuitsPending 300
*These values can be increased if the traffic to the Hidden Service in
question is even higher.

I came to look at this values when I saw in Tor logfile the message
that it wanted to launch more circuits but already had n circuits
pending already, so thought this can be a bottleneck. When I increased
these values, that message disappeared from logs.

Obviously the Guard(s) is/are a bottleneck for a Hidden Service, since
all the traffic to or from it has to go through the Guard(s). The
performance (CPU/RAM) and bandwidth of the server actually hosting the
Hidden Service won't make much of a difference in this scenario, when
Tor (used with default settings) will randomly select 1 (one) Guard
and keep it for a longer period.

I know the Guard requirements are different now, this flag being
currently allocated to a certain percent of the fastest Stable and
most-of-the-time up relays in the consensus - but still, this can be
the bottleneck if we are talking about a big Hidden Service.

In order to mitigate this, which one of the methods below do you think
would hurt anonymity the least:

1. Run your own high speed Guard relays and manually teach the server
hosting the Hidden Service to use them. Could this work? It doesn't
sound very random or diverse for anonymity, and obviously these Guards
will also be Guards for other clients, which have selected them
randomly, therefor they won't have all the bandwidth available.

2. Run your own high speed Bridge Relays. When using Bridges, we have
these possibilities:

a) Create regular high speed Bridge Relays and use them by adding them
all to the server hosting the Hidden Service and add NumEntryGuards n
where n = number of bridges. Leave other users to use these bridges
also by publishing them with Tonga.

b) Create private Bridge Relays (PublishServerDescriptor 0) and use
them by adding them all to the server hosting the Hidden Service and
add NumEntryGuards n where n = number of bridges.

c) Create private Bridge Relays (PublishServerDescruptor 0) and use
them by adding them all to the server hosting the Hidden Service and
add NumEntryGuards n where n = number of bridges and configure Tor to
build 4 Hop circuits when used with Bridge Relays:
Hidden Service -> bridge -> middle1 -> middle2 -> middle3 -> rendezvous

Will such a behavior (method 2-c) be easily detected? Will any of the
other relays or an attacker watching the Tor network (or part of the
Tor network) notify this? In case we use 4 hop circuits with a Bridge
with PublishServerDescriptor 0 (IP address will not be in the
consensus and not even in Tonga's database), and we configure Tor in a
way that the first hop (middle1) also has the Guard flag, won't all
the bridges connecting this way look like normal Tor clients?

What other parameters could improve the performance and capacity of a
Hidden Service?


!!! !!! !!!
THESE METHODS ARE EXPERIMENTAL, NOT YET TESTED AND JUST FOR RESEARCH!
DO NOT USE THEM FOR REAL HIDDEN SERVICES, IT CAN AND PROBABLY WILL
COMPROMISE THEIR CURRENT LEVEL OF ANONYMITY WHICH IS ENSURED MORE OR
LESS BY Tor's DEFAULT SETTINGS.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJU/OjaAAoJEIN/pSyBJlsRwtYH/0XQeYlDgo1xAL4DkzfAlc38
9fun5xW5d7SBVKuZsa2YYOtIpmSTOEgo/vt/2zDZYIDuvY+DWS/m9Y0WQ/R/FDHK
MHH9b2LBzWtt0meI+P5rIwwbvqUCsWYjVApJp+bn3NdlI8tYKLvc30HUzAbmBeSM
gG1USdsmf8/KJeZzu68yM73XxMW+9PM3cbxFFSbR+Ix1plkvzvwKMD/DdJnWLfuk
hICqQs4fCB6RPweElZIMrzFqpHMbw9qh7CgCV2XcUrjZNwlYFSIb36U+ULP4FpsX
5PPLffk1JtOFNOS1BJl/t0vSWKd/1dLSbivceLohW475F5a4duV3HkboXUBpMdc=
=XvfB
-----END PGP SIGNATURE-----
-- 
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

