Opened 9 months ago

Closed 6 months 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/Atlas Version:
Severity: Normal Keywords: family
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Hello,

(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 9 months ago by cypherpunks

  • Component changed from - Select a component to Metrics/Atlas
  • Owner set to irl

comment:2 Changed 9 months ago by teor

  • Keywords atlas members removed
  • Summary changed from atlas doesn't check if all family members list themselves to atlas 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.

https://onionoo.torproject.org/protocol.html#details

comment:3 Changed 9 months ago by irl

  • Status changed from new to accepted

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

comment:4 Changed 9 months ago by karsten

  • Status changed from accepted to needs_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: https://atlas.torproject.org/#details/B204DE75B37064EF6A4C6BAF955C5724578D0B32

comment:5 Changed 9 months 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 9 months 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 9 months 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 6 months ago by RaBe

  • Owner changed from irl to RaBe
  • Status changed from needs_information to assigned

comment:9 Changed 6 months 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.

https://github.com/RaphaelBergmann/atlas/commit/baff7af2656594a1b7f8a8f2c73023ce20efb33b

comment:10 Changed 6 months ago by RaBe

  • Status changed from assigned to needs_review

comment:11 Changed 6 months ago by irl

  • Resolution set to fixed
  • Status changed from needs_review to closed

LGTM. Merged.

Note: See TracTickets for help on using tickets.