Re: [tor-dev] Proposal xxx: Filtering malicious rendezvous points at hidden service server side

[s7r <s7r@xxxxxxxxxx>]

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

Hi teor,

On 1/24/2016 6:33 AM, Tim Wilson-Brown - teor wrote:
> Please read the tor man page documentation for the option 
> Tor2webRendezvousPoints. It's implemented in the function
> pick_tor2web_rendezvous_node().
> 
> Under this proposal, what is the smallest number of rendezvous
> points a Tor2web instance would need to specify in
> Tor2webRendezvousPoints to avoid being banned, or does it vary
> depending on the popularity of the hidden service?
> 

Ideally pick_tor2web_rendezvous_node() should pick a random relay to
act as a rendezvous point, based on its consensus weight / middle
probability fraction, exactly the same as any regular client would do.

Obviously a tor2web service can skip the Guard since it doesn't care
about anonymity, for lower latency to the hidden service.

For load balancing and capacity and everything, a tor2web service
should always choose a random rendezvous relay for every circuit, and
ideally (don't know if it's possible in reverse proxy mode) re-use the
same circuit to the same hidden service if there are multiple visitors
(tor2web clients) asking to connect to the same hidden service. If
this is not possible (using one circuit per hidden service
destination, regardless if there are more people accessing that hidden
service address via tor2web) at least it should pick randomly
rendezvous relays for every circuit.

This way, no rendezvous nodes will be banned. And the number of
rendezvous circuits we allow with a single relay as rendezvous point
is of course dependent on the popularity of the hidden service (total
number of rendezvous circuits built by that hidden service in the last
24 hours). So if a hidden service experienced 10000 rendezvous
circuits in the last 24 hours, a relay with middle probability
fraction of 0.5% is able to build at least 10000 * 0.005 = 50 new
rendezvous circuits before might get banned for the next 24 hours by
that hidden service.

P.S. Picking the same rendezvous relays in tor2web services sounds
like we are hammering them too much.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWpPeBAAoJEIN/pSyBJlsRxycIAMKKsc4CpTDbJ90W30tKVwVl
637mDZfAFbM3goNnRQvyjgbDBvyPGhtrkJkVrLHRpSJ1xszd06W3aYVVlIVn4AtD
ZVKImkFZK7qKjwEVRmFEAUBO/m8PSWWjpz17zB93sJJYZrSDI5ypVWBJpXAqy8fI
iOeirexvLU8XsxJowXT/thQFvC9F26IZbAjUSkwkZjoxHe846NulZobnrSECls6U
G6i9J9pYejWUFK0uBORFk2RTqyEzRUEPefOfkmT3+ytGJrM7yBbUoYbNXElinDmb
YxeaK0TFIbYcaot0JEML06T4P6+/jKEFeYMZLUE5GtPIiMjUsw4g1lwacDI544o=
=0+Ba
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev