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

[s7r <s7r@xxxxxxxxxx>]

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

Sorry for posting 2 times, want to highlight something which doesn't
read clear.

On 1/24/2016 4:44 AM, s7r wrote:

> Consider this. We set  the REND_FILTER_TOLERANCE to 4. This means
> that any relay, regardless of its middle probability fraction, will
> be able to build 4 +1 different rendezvous circuits with a hidden
> service server, before it gets banned for 24 hours.
> 
I mean any relay, regardless of its middle probability fraction, will
be able to be used as rendezvous point in at least 4 rendezvous
circuits in 24 hours with the same hidden service, before it gets
banned for 24 hours (the ban will be effective only for that
particular hidden service, other hidden services will use it normally
until it annoys them too).

> So, an attacker will start by, as a client, building 5 rendezvous 
> circuits with each relay in the consensus in order to try to make
> the hidden service inaccessible.
> 
I mean building at least 5 different rendezvous circuits within 24
hours with the same relay as the rendezvous point to the same hidden
service.

> So he starts, and gets some relays banned. But after the attacker
> got 300 relays banned as rendezvous points on a hidden service
> (not affecting the other clients/hidden services in the network in
> any way) he would have made the hidden service server build 1500
> circuits already.
> 
> This means that next time he wants to ban a relay as being used
> for rendezvous by that hidden service, and that relay has a 0.5%
> middle probability fraction (1% since we allow 2 times more to
> reduce error margin) he will have to build 1500 x 0.01 = 15 (+1)
> circuits to get this relay banned also.
> 
> After 100 more relays like this getting banned we have at least
> 1600 more rendezvous circuits, plus the previous 1500 = 3100
> rendezvous circuits. And just 300 relays banned (out of ~7000). To
> continue, now the attacker has to build 3100 x 0.01 = 31 (+1)
> circuits to get another relay with middle probability fraction 0.5%
> banned. And so on.
> 
Sorry, it's 400 relays banned here (300 + 100). I mean the attacker
has to build another 31 (+1) different rendezvous circuits with the
next relay as the rendezvous point to the same hidden service to get
it banned as well.

> As you can see, it's quite hard to make a hidden service
> inaccessible via this method, with over 7000 relays in the
> consensus and only 24 hours of rend circuit history (e.g. relays
> banned more than 24 hours ago have the ban lifted now).
> 
> There are plenty of things which will fail before this protection 
> enables a DDoS attack for a hidden service, like the hidden
> service's guard which will fail _way_ before an attacker is able to
> ban ~7000 relays as rendezvous points for a hidden service. This is
> already an existing problem (bottleneck of hidden service capacity
> is its guard) so we are not making anything worse, the attack
> already exists with or without the rendezvous filter.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWpD58AAoJEIN/pSyBJlsRCM4H/Ap2ePluNz3aDYKS6nQ8fq89
4+ycu3QhyzwDzhkqkl5SGpJSjJzklja/M/gk/3zDdUV9nQK/62hZVXbcdGa6vxq/
AZHaCN28loYqcCCtM8fV6yrZOE/XyLTVse3QS6Mlf6wA8xv0hQFV2Vwuv9+qjwKT
2xXjFRSV4zztFzW5o22XzSpH7wjbCuIgw933SO3lqFzj4z4c9AFUBa0NvNgoxASa
VCqlf3/pMcNsyrIo1GWi81ox5nev7iOw6Pkfp7Eoub44cNftRSqHwAKUpgkn8uh/
H5duESPm37xRGv0byweIf/HRtOM4SOcY8oszVGJ2ex22hCgnksFaElkL5EhlB0s=
=r8MG
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev