[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos
#26294: attacker can force intro point rotation by ddos
-------------------------------------------------+-------------------------
Reporter: arma | Owner: asn
Type: defect | Status:
| assigned
Priority: Medium | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs, tor-dos, network-team- | Actual Points:
roadmap-2019-Q1Q2 |
Parent ID: #29999 | Points: 7
Reviewer: | Sponsor:
| Sponsor27-must
-------------------------------------------------+-------------------------
Comment (by s7r):
I like 'a' as a short term plan as well. Proof of work solutions are non
trivial engineering challenges, consume time and it eventually still gets
down to the simple question how much resources/work/time/bandwidth is the
attacker willing to give to pull this of.
what if we add a time based lifetime for each intro point, which will be a
random value chosen at intro point selection between n and m hours, along
with a ALLOW_RESET_CACHE parameter which will be a random number between o
and p and also maintain the intro requests lifetime rand(16384, 16384*2)
which will be combined with ALLOW_RESET_CACHE, and rebuild descriptor when
the first from these two is reached. This way we don't have to increase
the cache but only reset it.
For example:
An onion service selects Z as intro point. It also chooses these random
values and remembers them for this intro point:
- time based lifetime = 5 hours (let's pretend n = 1; m = 6)
- ALLOW_RESET_CACHE = 1400 (let's pretend ALLOW_RESET_CACHE = rand(100,
7000))
- intro requests lifetime = 20122 (rand(16384, 16384*2)
Now, this intro point will be rotated either after 5 hours, if the onion
service is not under attack, either after 20122 * 1400 = 28,170,800 intro
requests.
If high values would have been chose for ALLOW_RESET_CACHE and intro
requests lifetime, indeed we will be getting many introduction requests
through the same introduction point, but we still have the time based
lifetime parameter as a safety precaution that will eventually move us
from this introduction point.
We can go even go more crazy about this and use the introduction point
measured bandwidth or consensus weight so we choose parameters based on
how much the intro point is actually able to support in terms of
bandwidth, so we don't end up with maintaining an introduction point that
is hammered and can't process the requests because it's too slow. Or find
another way to check if the intro point is actually responding to intro
requests. But even without these smarter computations the presented
solution still has to be better than what we have now.
All 3 parameters must be randomized as described, otherwise we open the
door for easier analysis and predictability for attackers, like estimate
with high probability when will the intro point change occur, etc.
(outside the scope of this ticket).
The numbers for time based lifetime and ALLOW_RESET_CACHE don't have any
analysis behind, they are just from top of my head and only to illustrate
and example about the logic we need to code. We need to evaluate and
choose good parameters for these values, if we think this is a good idea.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26294#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs