[tor-talk] possible solutions for increasing the capacity of a Hidden Service

[s7r <s7r@xxxxxxxxxx>]

-----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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk