Activity
Replying to rransom:
- It is probably harmful for clients to refuse to use two relays operated by the same honest entity, and malicious relay operators will not use MyFamily honestly.
I've the feeling that this ignores the fact that MyFamily is still useful even if only honest operators use it. Why is it useful even then? 0wning a honest relay operator likely gives you access to all of his relays (sooner or later). [Yes after owning them the attacker could remove their MyFamily setting but reconfiguring and reloading a relay hopefully would rise some suspicion]
Or more generally: The probability to compromise relay A and B is higher if they are run by the same operator.
I think the strongest argument we're going to get here will come from Tariq's research on guard rotational vulnerabilities. He found that when guard rotation occurs, the bad guy is significantly more likely to get his relay chosen as your guard if you obey the family stuff than if you ignore it. The 'significantly' is because a lot of our really big relays are in families. So there's increased vulnerability right now in the passive (no compromise of big nodes) case. The question is which vulnerabilities are worse.
I'm hoping to get good answers here once he finishes prepping the WPES paper/talk and moves on to the NDSS submission (or whatever venue is next).
Trac:
Cc: N/A to tariq.elahi@uwaterloo.ca, iangI think it is a bad idea to remove the family setting, because it will make larger operators a more interesting target.
What if I end up as both entry and exit, and potentially even the middle node? Some time ago, some LEA wanted me to give up information on a case that was "happening right now", so there might still be open circuits, right?
Replying to arma:
I think the strongest argument we're going to get here will come from Tariq's research on guard rotational vulnerabilities. He found that when guard rotation occurs, the bad guy is significantly more likely to get his relay chosen as your guard if you obey the family stuff than if you ignore it. The 'significantly' is because a lot of our really big relays are in families. So there's increased vulnerability right now in the passive (no compromise of big nodes) case. The question is which vulnerabilities are worse.
I'm hoping to get good answers here once he finishes prepping the WPES paper/talk and moves on to the NDSS submission (or whatever venue is next).
I talked to Tariq about this at Oakland, and he said that his analysis shows (counterintuitively) that taking away the Family concept actually doesn't change vulnerability to the above attacks much. That is, the 'significantly' above is not actually significant.
It would be interesting to have Aaron re-do the same calculation using his new TorPS simulator.
Trac:
Cc: tariq.elahi@uwaterloo.ca, iang to tariq.elahi@uwaterloo.ca, iang, gsathya, amj703
Trac:
Parent: N/A to legacy/trac#15060 (moved)I believe it is dangerous to use all 3 relays in a circuit from a single entity - even if the entity is acting honestly.
MyFamily is hated and not properly used because:
-
it is cumbersome to manage
-
there are no incentives for a relay operator to set it properly
-
it was not easy to verify whether MyFamily was setup correctly on all your relays
-
I'm aiming to make it very easy for relay operators to manage MyFamily without them even knowing what MyFamily is (using an ansible role https://github.com/nusenu/ansible-relayor)
-
create a tor operator "bandwidth ranking" based on the family (new compass group-by family functionality). So a relay operator that wants to move up on the list has a reason to properly set MyFamily (using provided tools or manually). MyFamily is currently even the only way to properly group relays of a certain operator toghether. Using contactInfo is a much weaker since it does not require any mutual agreement.
-
relay operators can use compass to very easily verify whether their MyFamily is setup correctly using the Family lookup (which is already available today)
-
Trac:
Username: tyseom
Cc: tariq.elahi@uwaterloo.ca, iang, gsathya, amj703 to tariq.elahi@uwaterloo.ca, iang, gsathya, amj703, nusenu@openmailbox.orgTrac:
Cc: tariq.elahi@uwaterloo.ca, iang, gsathya, amj703, nusenu@openmailbox.org to tariq.elahi@uwaterloo.ca, iang, gsathya, amj703, nusenu@openmailbox.org, qbi