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

[Tim Wilson-Brown - teor]

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 at sky-ip.org> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160124/4b97f387/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160124/4b97f387/attachment.sig>