Re: [tor-dev] Open topics of prop247: Defending Against Guard Discovery Attacks using Vanguards

[George Kadianakis <desnacked@xxxxxxxxxx>]

s7r <s7r@xxxxxxxxxx> writes:

> George Kadianakis wrote:
>> Hello,
>> 
>> here is some background information and summarizing of proposal 247
>> "Defending Against Guard Discovery Attacks using Vanguards" for people
>> who plan to work on this in the short-term future.
>> 
>
> Hello,
>
> I have discussed in Amsterdam briefly with David about this and want to
> further discuss it here where everyone can throw an eye on it. I have an
> idea to use a different technique that will replace the concept of
> vanguards and will only activate in case the hidden service might be
> under attack - I refer here to Hidden Service Guard Discovery Attack,
> which is currently fast, easy, (relatively, depending on adversary)
> cheap and effective. It will also address the load balancing questions
> we have in the context of using vanguards and make it much harder and
> more expensive for an adversary to mount a HS Guard Discovery attack.
>
> The main idea was discussed last year a little bit:
> https://lists.torproject.org/pipermail/tor-dev/2016-January/010291.html
>
> but its initial logic (banning a suspicious rendezvous point for a
> period of time) had some issues as pointed out by arma:
> https://lists.torproject.org/pipermail/tor-dev/2016-January/010292.html
>
> So, to mitigate those, we could do something different:
>
> Each hidden service server will keep in persistent memory the following
> information and always validate a rule before selecting the path for any
> rendezvous circuit:
> - total number of successfully established rendezvous circuits for the
> last 24 hours;
> - middle probability based on consensus weight fraction for each
> rendezvous relay in the list (if this value is less than 0.3, it
> defaults to 0.3);
> - hop 2 and 3 from the last circuit used to each rendezvous relay in the
> list;
> - number of successfully established rendezvous circuits per each
> rendezvous relay fingerprint in the last 24 hours.
>
> A table with the required columns would look like this:
> Fingerprint | Middle Prob | Last circ hop2,hop3 | num circs last 24 hrs
>
> A rendezvous relay is considered suspicious when the number of
> successfully established circuits in the last 24 hours per a certain
> rendezvous relay exceeds with more than x2 factor the number of expected
> circuits having that relay as rendezvous point.
>

Hello s7r,

and thanks for helping with this and approaching it from a different
direction.

Personally, I'd be really surprised if any solution that statistically
marks relays or paths as "suspicious" will ever work for this particular
problem. That's because the adversary does not need that many paths to
succeed, and also because the adversary has lots of time to carry out
the attack. I also dislike these solutions since the HS operator cannot
really distinguish between an actual attack that just happened, or their
HS getting slashdotted, or someone trolling them by connecting a
thousand times.

Furthermore, I don't understand why your proposal marks rendezvous
points as suspicious, and not the paths themselves. After all, the
attacker can choose a diffferent rendezvous point everytime, as long as
the HS makes fresh circuits for each one.

Also if you are suggesting the reuse of hops 2 and 3 for multiple
circuits, you are basically suggesting a layered guard approach which is
what prop247 also tries to do, and FWIW it's not simple at all
(especially from an engineering perspective).

Cheers!

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