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_dangerous_relaygroups.txt (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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev