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