Opened 4 years ago

Closed 4 years ago

#20382 closed enhancement (fixed)

atlas doesn't check if a relay's family members also list that relay in their family

Reported by: cypherpunks Owned by: irl
Priority: Medium Milestone:
Component: Metrics/Relay Search Version:
Severity: Normal Keywords: family
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:



(sorry, english isn't my mother tongue, so please excuse my writing)

As said in title, atlas isn't checking if all family members list themselves, so it leads to some ambiguous results, showing relay being part of the same family when it's not the case.

Below a copy/paste from the IRC (nicknames are anonymized as I didn't ask permission to paste the log)

< mickael> Hello, it seems someone is hijacking my family members, what can be done against that? I mean: a node pretends to be part of my family but it's wrong. I'm running one single middle node, nothing else.
< nick1> it doesn't matter.
< nick1> two nodes are only considered a family if they list each other.
< mickael> Ok, so even if atlas tells we're part of the same family, there is no need to worry ?
< nick1> probably correct.
< nick2> sounds like an atlas bug
< nick3> and even if nodes are in same family, I do not see ~any harm in it
< mickael> nick1: thanks, nick2: do you want me to fill a bug report ?
< nick4> oh in theory there is harm if you ask me, you would be able to make the tor network not use the two nodes in a circuit, no?
< nick2> mickael: that could be helpful! I don't maintain atlas, so I can't guarantee much, but it is probably a good idea.

Child Tickets

Change History (11)

comment:1 Changed 4 years ago by cypherpunks

Component: - Select a componentMetrics/Atlas
Owner: set to irl

comment:2 Changed 4 years ago by teor

Keywords: atlas members removed
Summary: atlas doesn't check if all family members list themselvesatlas doesn't check if a relay's family members also list that relay in their family

Clarified bug title.

By the way, nick3 is wrong: the attack is to steer traffic towards particular nodes by listing a very large family. And it doesn't work on recent versions of Tor, because it checks for mutual family relationships.

OnionOO has effective_family and alleged_family, I suggest they are coloured differently in the Atlas family list, like we currently colour missing relays differently.

comment:3 Changed 4 years ago by irl

Status: newaccepted

Colouring differently and adding a tooltip for potential false information I think is a good way to go here.

comment:4 Changed 4 years ago by karsten

Status: acceptedneeds_information

I'm not sure what exactly this ticket ask for, but Atlas already colors effective and alleged family members differently: blue vs. orange. Example:

comment:5 Changed 4 years ago by irl

Perhaps we could add small headings? I think it would be good to at least add tooltips to explain what the difference is between effective and alleged family.

comment:6 Changed 4 years ago by karsten

Sure, adding more explanations and tooltips sounds great. Not sure about the headings; those could be a good idea, but I'm a bit more careful here, because the distinction between effective and alleged family comes from Onionoo, and it might be wrong or base the distinction on outdated data. Originally, all fingerprints (or nicknames) come from the relay. However, I'm looking at this from the perspective of a developer who knows the data, not from a user perspective. If a small heading would be easier to comprehend for users, okay. Please decide. :)

comment:7 Changed 4 years ago by irl

There's potentially a bigger problem here. None of the tooltips are currently working, I believe due to a conflict between bootstrap and jquery. Need to investigate.

comment:8 Changed 4 years ago by RaBe

Owner: changed from irl to RaBe
Status: needs_informationassigned

comment:9 Changed 4 years ago by RaBe

Owner: changed from RaBe to irl

To separate the effective and alleged family members more clearly I added the headers that irl suggested. (I had to do that in advance to #12692, so it's in the same branch.) The tooltip problem will be solved by #9913.

comment:10 Changed 4 years ago by RaBe

Status: assignedneeds_review

comment:11 Changed 4 years ago by irl

Resolution: fixed
Status: needs_reviewclosed

LGTM. Merged.

Note: See TracTickets for help on using tickets.