protecting users from known relay groups with end-to-end correlation capabilities
Hi, it is a well known fact that MyFamily is a largely ignored setting, luckily this is not a problem in most cases because - all relevant relays are run in a single /16 or - are only guard relays (exit probability = 0*) or - are only exit relays (guard probability = 0*) but there is a limited number of relay groups** that have actual end-to-end correlation capabilities, meaning they are potentially chosen by tor clients for the guard _and_ exit position, even if the odds are (hopefully) not very high. These potentially dangerous relay groups - are run in multiple /16 netblocks - have an exit _and_ guard probability of > 0 (because they run exits and guards) Examples (generated daily): https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dang... (see CC) How could the risk for tor clients be reduced? (options after enough dir auths came to the conclusion that these relays are in fact operated by a single entity) 1) try to contact the operators and give them time to fix it I've done that multiple times but haven't been successful [1] 2) build tools to easily/automatically manage MyFamily done[2], but it is unlikely to be used 3) assign them the badexit flag since exits are a scarce resource, not very wise 4) assign them the badguard flag there is no such thing ;) 5) blacklist the entry guards (that are outside the configured family) 6) change tor's path selection algorithm to never choose more than one relay with a given non-empty non-default contact string? This would basically turn the ContactInfo field into the PoS token mentioned by Mike in [3]. Since there are a few common contactInfo strings this is probably not the best option without excluding them. [1] https://lists.torproject.org/pipermail/tor-relays/2016-November/010965.html [2] https://github.com/nusenu/ansible-relayor [3] https://trac.torproject.org/projects/tor/ticket/5565 * if we can assume onionoo's values to be accurate and realistic ** they are considered to be operated by a single group due to their contactInfo descriptor field. This string is not verified in any way and can therefore result in false-positives.
Dear relay operators who are CC'd, TL;DR: we're talking about blacklisting your non-exit relays, because they don't have MyFamily set correctly. If you'd like help configuring MyFamily correctly, please let us know.
On 3 Dec. 2016, at 08:50, nusenu <nusenu@openmailbox.org> wrote:
Hi,
it is a well known fact that MyFamily is a largely ignored setting, luckily this is not a problem in most cases because
- all relevant relays are run in a single /16 or - are only guard relays (exit probability = 0*) or - are only exit relays (guard probability = 0*)
but there is a limited number of relay groups** that have actual end-to-end correlation capabilities, meaning they are potentially chosen by tor clients for the guard _and_ exit position, even if the odds are (hopefully) not very high.
These potentially dangerous relay groups - are run in multiple /16 netblocks - have an exit _and_ guard probability of > 0 (because they run exits and guards)
Examples (generated daily): https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dang... (see CC)
This is a useful check, but it is insufficient. Can you please produce a similar list for middles and exits by the same operator? (Controlling the middle and exit leads to a guard identification attack.) There's also an attack when an operator controls a guard and a middle. But that's harder to resolve, albeit much more common.
How could the risk for tor clients be reduced? (options after enough dir auths came to the conclusion that these relays are in fact operated by a single entity)
1) try to contact the operators and give them time to fix it I've done that multiple times but haven't been successful [1]
Have you tried emailing them individually? I've typically got better results that way.
2) build tools to easily/automatically manage MyFamily done[2], but it is unlikely to be used
Maybe one solution is to build a generic tool that works with more than just ansible?
3) assign them the badexit flag since exits are a scarce resource, not very wise
+1
4) assign them the badguard flag there is no such thing ;)
We have written patches that take away the guard flag. This would be possible, but it doesn't resolve the issue, because they will still be used as middle relays. However, taking away the guard flag would fix the guard/middle case, because then all the relays would only be used as middle relays.
5) blacklist the entry guards (that are outside the configured family)
Yes, this is the best option, because it protects clients from selecting relays from that operator as either guard or middle. (However, operating a bridge and an exit still has the same issue, and there is no MyFamily for bridges, because that de-anonymises them. As do the bridge/middle and guard/middle cases. So maybe we should consider the risks of each case, and whether we want to educate or ban.) And, of course, it's worth noting that the ContactInfo might be incorrect, so we would have to do this on a case-by-case basis, and convince the directory authority operators it's a sensible thing to do. (If someone is using others' ContactInfo, those relays should be banned.)
6) change tor's path selection algorithm to never choose more than one relay with a given non-empty non-default contact string? This would basically turn the ContactInfo field into the PoS token mentioned by Mike in [3]. Since there are a few common contactInfo strings this is probably not the best option without excluding them.
No, this field is not mutually authenticated, unlike MyFamily. This leads to an attack where bad relays bias client path selection using ContactInfo.
[1] https://lists.torproject.org/pipermail/tor-relays/2016-November/010965.html [2] https://github.com/nusenu/ansible-relayor [3] https://trac.torproject.org/projects/tor/ticket/5565 * if we can assume onionoo's values to be accurate and realistic ** they are considered to be operated by a single group due to their contactInfo descriptor field. This string is not verified in any way and can therefore result in false-positives.
T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Examples (generated daily): https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dang... (see CC)
This is a useful check, but it is insufficient. Can you please produce a similar list for middles and exits by the same operator?
done https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dang...
1) try to contact the operators and give them time to fix it I've done that multiple times but haven't been successful [1]
Have you tried emailing them individually? I've typically got better results that way.
Yes I did. Just one example: https://lists.torproject.org/pipermail/tor-relays/2016-November/010950.html
2) build tools to easily/automatically manage MyFamily done[2], but it is unlikely to be used
Maybe one solution is to build a generic tool that works with more than just ansible?
other example by coldhakca https://github.com/coldhakca/sync_family
Dear noisebridge tor operators, teor wrote [1]:
TL;DR: we're talking about blacklisting your non-exit relays, because they don't have MyFamily set correctly.
If you'd like help configuring MyFamily correctly, please let us know.
If you are wondering which relay is misconfigured: https://atlas.torproject.org/#details/1A835E3663068222F28F7C5AF3216F4B27B50B... [1] https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html +----------------+----------+------+ | nickname | MyFamily | exit | +----------------+----------+------+ | noisebridge01a | NULL | 0 | | noiseexit01a | 4.0000 | 1 | | noiseexit01b | 4.0000 | 1 | | noiseexit01c | 4.0000 | 1 | | noiseexit01d | 4.0000 | 1 | +----------------+----------+------+
Dear snaptorg tor operator, teor wrote [1]:
TL;DR: we're talking about blacklisting your non-exit relays, because they don't have MyFamily set correctly.
If you'd like help configuring MyFamily correctly, please let us know.
If you are wondering which relay is misconfigured, the last column (MyFamilyCount) should say at least 7 (or 8 if you plan to recycle your Creanova relay key). https://atlas.torproject.org/#details/9BFBF1EA78A3FC1A790F7A7789F074338E7F81... +---------------------+--------------+------+-------+---------------+ | first_seen | nickname | exit | guard | MyFamilyCount | +---------------------+--------------+------+-------+---------------+ | 2016-12-03 23:00:00 | SnapTorCAN | 0 | 0 | 5.0000 | | 2016-11-28 14:00:00 | SnapExitUS | 1 | 1 | 7.0000 | | 2016-11-28 11:00:00 | SnapExitBULG | 1 | 0 | 7.0000 | | 2016-11-27 00:00:00 | SnapTorBANG | 0 | 0 | 8.0000 | | 2016-11-26 23:00:00 | SnapTorSNPR | 0 | 0 | 8.0000 | | 2016-11-26 23:00:00 | SnapTorSTRAS | 0 | 0 | 8.0000 | | 2016-11-12 00:00:00 | SnapTorFr | 0 | 0 | 8.0000 | +---------------------+--------------+------+-------+---------------+ [1] https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html
Dear tor directory authorities, TLDR: Would you blacklist relays with end-to-end correlation capabilities? I'm asking to find out whether it makes sense to put any effort into finding such operators [2]. If most dir auths would not blacklist such relays than it does not make sense to look for them I guess. So please let us know whats your opinion on that - thank you. More information below and there [1]: The process could look something like this: - someone identifies such a relay groups (basically based on contactinfo [2]) - contact the operators asking to fix this (ideally this would be a @torproject.org sender) - give them 15 days to fix it - if not fixed: blacklist respective guard relays - give them the possibility to get removed from the blacklist once fixed teor [1]:
And, of course, it's worth noting that the ContactInfo might be incorrect, so we would have to do this on a case-by-case basis, and convince the directory authority operators it's a sensible thing to do.
[1] https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html [2] examples: https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dang...
participants (2)
-
nusenu -
teor