s7r s7r@sky-ip.org 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!