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

> On 24 Jan 2016, at 13:04, s7r wrote: > > Signed PGP part > > On 1/24/2016 1:51 AM, Tim Wilson-Brown - teor wrote: > > > >> On 24 Jan 2016, at 09:28, s7r >> > wrote: > >> > >>> * This will break some Tor2Web installations, which > >>> deliberately choose rendezvous poi

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sorry for posting 2 times, want to highlight something which doesn't read clear. On 1/24/2016 4:44 AM, s7r wrote: > Consider this. We set the REND_FILTER_TOLERANCE to 4. This means > that any relay, regardless of its middle probability fraction, w

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Mike, Answers inline. On 1/24/2016 1:56 AM, Mike Perry wrote: >>> A) Can I deny service to a hidden service by methodically >>> pretending to attack it from each honest relay, one at a time, >>> causing it to become upset at each of these r

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/24/2016 1:51 AM, Tim Wilson-Brown - teor wrote: > >> On 24 Jan 2016, at 09:28, s7r > > wrote: >> >>> * This will break some Tor2Web installations, which >>> deliberately choose rendezvous points on the same server or >

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

s7r: > On 1/24/2016 12:10 AM, Roger Dingledine wrote: > > A few more details about "this is not always enough" would be > > helpful here. In particular, is it not always enough because > > sometimes even 3 hops is not safe enough, or not always enough > > besides sometimes making a 3-hop circuit is

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

> On 24 Jan 2016, at 09:28, s7r 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.) > >

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

-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 discuss

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/24/2016 12:10 AM, Roger Dingledine wrote: > > A few more details about "this is not always enough" would be > helpful here. In particular, is it not always enough because > sometimes even 3 hops is not safe enough, or not always enough > besi

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

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 s

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

On Sat, Jan 23, 2016 at 11:38:00PM +0200, s7r wrote: > The attacker is also a Sybil (holds an unknown % of the bandwidth in > the Tor network). By making the hidden service server build many > circuits to his evil rendezvous points, the attacker gets a high > probability that the hidden service ser

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, Inspired by asn, dgoulet and Mike Perry discussing alternate path lengths for proposal 247, I wrote a proposal that could fit in nicely with proposal 247, maybe even allow us to make the 3rd hop wild (random) so we don't have to worry about H