[tor-dev] protecting users from known relay groups with end-to-end correlation capabilities

[nusenu]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161202/7f06ce3f/attachment.sig>