On 24 Jan 2016, at 13:04, s7r s7r@sky-ip.org wrote:
Signed PGP part
On 1/24/2016 1:51 AM, Tim Wilson-Brown - teor wrote:
On 24 Jan 2016, at 09:28, s7r <s7r@sky-ip.org mailto:s7r@sky-ip.org> wrote:
- 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.
...
HiddenServiceRendFilter 0 only modifies the behaviour of one hidden service with Tor2Web. But because Tor2Web is a client which is configured to use the same rendezvous point(s) for every hidden service connection, it will get banned if it connects to the same hidden service too many times.
Negative.
A Tor2Web instance runs as a normal Tor client and are configured as reverse proxies.
This means that Tor2Web runs as _normal_ and _genuine_ client, and picks rendezvous points randomly as per Tor's path selection. They do not request a hidden service server to connect 100 times to a middle relay (rendezvous point) with consensus weight of 0.01%, which is what we are trying to mitigate. So a super popular Tor2Web service might initiate 10000 rendezvous circuits in few hours, but they will all be at multiple rendezvous points, according to their weight and middle fraction probability, which is OK in our model and will not be affected.
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?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F