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

[Tim Wilson-Brown - teor]

> On 25 Jan 2016, at 03:10, s7r <s7r at sky-ip.org> wrote:
> 
> Signed PGP part
> Hi teor,
> 
> On 1/24/2016 6:33 AM, Tim Wilson-Brown - teor wrote:
> > Please read the tor man page documentation for the option
> > Tor2webRendezvousPoints. It's implemented in the function
> > pick_tor2web_rendezvous_node().
> >
> > Under this proposal, what is the smallest number of rendezvous
> > points a Tor2web instance would need to specify in
> > Tor2webRendezvousPoints to avoid being banned, or does it vary
> > depending on the popularity of the hidden service?
> >
> 
> Ideally pick_tor2web_rendezvous_node() should pick a random relay to
> act as a rendezvous point, based on its consensus weight / middle
> probability fraction, exactly the same as any regular client would do.

This isn't how the current Tor2web implementation works. If your proposal will
break the Tor2webRendezvousPoints option, or require a minimum number of
relays to be specified in that option, you need to document these implementation
changes or new configuration constraints clearly in the proposal.

> 
> ...
> For load balancing and capacity and everything, a tor2web service
> should always choose a random rendezvous relay for every circuit, and
> ideally (don't know if it's possible in reverse proxy mode) re-use the
> same circuit to the same hidden service if there are multiple visitors
> (tor2web clients) asking to connect to the same hidden service.

I'm not sure whether different Tor2web web clients get different hidden service
circuits. But as it's critical to the correct functioning of this proposal with Tor2web
mode, I'd encourage you to find out, and update the proposal accordingly.

> 
> If
> this is not possible (using one circuit per hidden service
> destination, regardless if there are more people accessing that hidden
> service address via tor2web) at least it should pick randomly
> rendezvous relays for every circuit.

This isn't how Tor2web mode works. If your proposal needs the design to be
changed, then please document that.

> 
> This way, no rendezvous nodes will be banned. And the number of
> rendezvous circuits we allow with a single relay as rendezvous point
> is of course dependent on the popularity of the hidden service (total
> number of rendezvous circuits built by that hidden service in the last
> 24 hours). So if a hidden service experienced 10000 rendezvous
> circuits in the last 24 hours, a relay with middle probability
> fraction of 0.5% is able to build at least 10000 * 0.005 = 50 new
> rendezvous circuits before might get banned for the next 24 hours by
> that hidden service.

So the number of rendezvous points required in Tor2webRendezvousPoints
depends on the load on the particular hidden service, the number of web
clients connecting to the particular hidden service via the Tor2web instance,
and whether those clients get the same rendezvous circuit or not.

Such a non-deterministic requirement essentially breaks the
Tor2webRendezvousPoints feature.

> 
> P.S. Picking the same rendezvous relays in tor2web services sounds
> like we are hammering them too much.

That's precisely why the option exists. Tor2web clients can choose a
rendezvous relay controlled by the Tor2web operator, on the same machine
or same network. This increases the speed of Tor2web connections.

And the operator can control for load on relays they control much more
precisely than picking a random rendezvous point.

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/20160125/2bc9ab7f/attachment-0001.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/20160125/2bc9ab7f/attachment-0001.sig>