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

[Tim Wilson-Brown - teor <teor2345@xxxxxxxxx>]

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. 

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?

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

On 24 Jan 2016, at 08:38, s7r <s7r@xxxxxxxxxx> wrote:

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.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev