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 12:11 AM, Tim Wilson-Brown - teor wrote:
> Hi s7r,
> 
> Great proposal, I really like it - I think it targets the actual 
> behaviour we want to prevent in a less complex manner than the HS
> 3rd-hop alternatives being discussed for prop247.
> 
Thanks!

> Some general questions:
> 
> * Do we want to make this behaviour (somewhat) symmetric, so that a
> client which sees a hidden service choose the same introduction
> point(s) for N periods will refuse to use that introduction point?
> 
I don't think so. I am not concerned about clients, given that they
cannot be made to build circuits, only they initiate them. Plus the
client builds normal circuit to the introduction points afaik, and we
don't want to overload the client with more stuff to process. For the
hidden service servers, it's totally worth the effort.

> * 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.

>> 8. Security implications for maintaining such records in the 
>> persistent state of a hidden service server
>> 
>> An attacker which compromises the location of a hidden service
>> server will access this additional information: total number of
>> rendezvous circuits built within the last
>> REND_FILTER_MONITOR_PERIOD and to which rendezvous points these
>> circuits were. This tradeoff should be worth it as well, since if
>> the location of a hidden service server is compromised it is game
>> over anyway, and this additional information shouldn't be so
>> important to the attacker, except maybe for better determining
>> the popularity of that hidden service (this can be determined
>> many other ways, like the logs from the application running 
>> behind the hidden service, network counter, datacenter/ISP level 
>> counters and logs, etc.).
> 
> To reduce the sensitivity of these counters, we should discard them
> after a certain period of time, perhaps every hidden service period
> (24 hours?)
> 
> We could also add noise and/or round into buckets, like we do for
> other statistics, but I'm not sure there's much point, as they are
> never seen outside the hidden service.
> 

Hmm, we should think about this. The 24 hours will in fact be the
latest 24 hours as of $now, something like this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWo/6FAAoJEIN/pSyBJlsRWI8H/33fudi5RF+yVOmxvx4mTh3p
vFBf7qOP8N39H7kn2gtbABa2iBP22FJJGcjxGdLnHMLxdrzufzdHz5DXBafP+Eh9
4nyrNNGmLNl4MdEWT4sUXcEjv3FDTwBTXTO6z8i5P3RR3Zo5Tjif0MgRW5/MliM/
jVTCqBtLUHGcWhzYQiCcaUoymqqytEy07D27xBwTVAn/3Mc90epqokPBnwgs6OWg
9XtQRipucE7SCxAsNVwJnhHNMO5ZoS004ChesJZ5pD1iE44da9EPifPiAowdT6ST
4IIzTjSkcKeCvlyX6IOjLQJxuQviqMJxxPvh8nL7JZI8daqrvFFEzXUN8K9CsSk=
=2sAp
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev