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 12:10 AM, Roger Dingledine wrote:
> 
> A few more details about "this is not always enough" would be
> helpful here. In particular, is it not always enough because
> sometimes even 3 hops is not safe enough, or not always enough
> besides sometimes making a 3-hop circuit isn't what the HS wants to
> do? Or something else?
> 
Not enough in the sense that it can theoretically get Sybiled and end
up with at least a guard discovery attack. Since an attacker can
request unlimited circuits to an evil rendezvous point, his other evil
relays will, with enough retries, end up in the path as well.

> 
> A) Can I deny service to a hidden service by methodically
> pretending to attack it from each honest relay, one at a time,
> causing it to become upset at each of these relays?
> 
Only if you are the only one connecting to that hidden service and
make 5 rendezvous circuits with each relay as a rendezvous point. But
after little time the total number of rendezvous circuits will grow so
large that you'll have to exponentially have to build more rendezvous
circuits with each relay as a rendezvous point to ban them all. So
it's a whole lot of work, you'll DDoS the hidden service guard or a
lot of other things first, before hitting the limit of this protection.

> B) Can I fool your reputation system by raising the total number
> of rendezvous attempts that I attempt, in effect making the hidden
> service feel more popular so it's not alarmed as much by any single
> rendezvous point? I could imagine ways to launch a rendezvous
> attempt that are quite cheap on the part of a client who has no
> plans to follow through.
> 
Yes, you could I think. But this has costs and is also visible to the
hidden service operator. And we keep count of established rendezvous
circuits with streams inside, not failed rendezvous circuits. We only
count successes, to make it costly for an attacker.

> 
> Actually, I don't think this is client behavior right now. (It
> could be if somebody changed the design of course.)
> 

Hm, thought it would retry at least one time, if the first rend
circuit fails. This can be trivially change though.

Thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWo/3CAAoJEIN/pSyBJlsRxwYH/jUxv94b85mBbH5XEMNRPF40
DXFwd1YC0zUo6/omiUfJzHlmGtmhjhMkrPokje+++mN4OhrqKP5PRVPuJ1JKd565
bJOrYYW499Cxm3+TedvndqvsCvQ0GFaWtFmzJ0ixjLyUZtqCu1u7O4gRUzHqlb1a
fnHJVcl9BhMAC2gOPOUnQQeAwaNFXz2+8k8Zn8TcDNPhxaS+kZRrNbh3fABJUBAs
6YenozzpIHM8/O6Y0avg+5bi/POxkbGk/4RV9k+Hq4AabUYsLOrAjZean/v6GTYJ
2MucWoIu1bGMukx6jWSO8vGIWJVEgGxzp5Ypw7M2gWqT/9iYbJDwXqkwnMGyxqg=
=3DMA
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev