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

[s7r <s7r@xxxxxxxxxx>]

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


On 1/24/2016 1:51 AM, Tim Wilson-Brown - teor wrote:
> 
>> On 24 Jan 2016, at 09:28, s7r <s7r@xxxxxxxxxx
>> <mailto:s7r@xxxxxxxxxx>> wrote:
>> 
>>> * This will break some Tor2Web installations, which
>>> deliberately choose rendezvous points on the same server or
>>> network for latency reasons. (Forcing Tor2Web installations to
>>> choose multiple RPs may be a worthwhile security tradeoff.)
>>> 
>> Yes, but there is a HiddenServiceRendFilter 0 in the proposal for
>> this purpose and for RSOS services as well.
> 
> But that doesn't help clients to connect to every hidden service
> using the same rendezvous points for every connection, unless every
> hidden service sets HiddenServiceRendFilter 0.
> 
> Tor2Web instances are Tor clients that are configured as reverse
> proxies to the entire Tor hidden service address space.
> 
> HiddenServiceRendFilter 0 only modifies the behaviour of one
> hidden service with Tor2Web. But because Tor2Web is a client which
> is configured to use the same rendezvous point(s) for every hidden
> service connection, it will get banned if it connects to the same
> hidden service too many times.
> 

Negative.

A Tor2Web instance runs as a normal Tor client and are configured as
reverse proxies.

This means that Tor2Web runs as _normal_ and _genuine_ client, and
picks rendezvous points randomly as per Tor's path selection. They do
not request a hidden service server to connect 100 times to a middle
relay (rendezvous point) with consensus weight of 0.01%, which is what
we are trying to mitigate. So a super popular Tor2Web service might
initiate 10000 rendezvous circuits in few hours, but they will all be
at multiple rendezvous points, according to their weight and middle
fraction probability, which is OK in our model and will not be affected.

Re-using circuits is not a problem either in our model, because if a
Tor2Web client builds a rendezvous circuit with a hidden service to
rendezvous point X, and has 500 users that want to access that hidden
service, it will maintain the same (a single) rendezvous circuit to
point X until it's unused for some period of time and gets killed,
which means the hidden service server will count only 1 circuit, also
OK in our model and will not be affected.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWpDEzAAoJEIN/pSyBJlsRqG8IAJoRhYSoqadDDBHG06n/2Xbt
8MTtwWgrj03bs5v79Nt1v8j/u4jlzMhnnh02nvbCPtfJm7uoyCJokQkWn+M3wpBP
2GhaZKQu0LcbiSHc4mC4iGgd3Lxe8qXLAQGoguJsp1V72dWN60MUvNcEimSrjJxI
4/0pfqHlcnNKos5M2GyTS48J+4W0NrYm8zGtuFUZ5PtHF0AOz7LFGtv1dg9zRbSA
87GOwL8n2YT5C78rZdg+FqHakzmbHW3xjX+xDj14KlfZ4rq61vVCwRViHuIX8QnE
Wvwnizaa2xhB+P02gGGF48G1AZWWOobRO6jks1qaqWKsawoNGcUD8Bq7USHNYSw=
=+5zt
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev