A limited number of relay groups can see you enter and exit the Tor network (deanonymization).

TL;DR: If you want to get the list of relevant Tor relays go to the bold URL near the end of this page.

When a Tor client routes traffic through the Tor network he tries to select 3 “random” (mostly) relays (guard, middle and an exit relay). The number of relays is crucial. Using 3 hops should help reduce the risk that a single entity (excluding global passive adversaries) can “see” Alice’s real IP address and the fact that she is talking to Bob. Alice protection is lost should her Tor client use relays controlled by a single entity (there are multiple cases, we mainly talk about the worst-case: operator sees entry and exit connection.)

There are multiple safeguards and properties in the Tor client to help reduce the risk of Alice loosing Tor’s traffic analysis protection due to unlucky path selection:

A default Tor client enforces distinct subnets. /16 IPv4 network blocks are treated as a “single relay operator”. Alice would not establish a circuit like 1.1. 0.1(Guard) → 2.2.0.1(Middle) → 1.1. 1.1(Exit), because that would violate the distinct subnets protection (more than one relay in 1.1. 0.0/16)

establish a circuit like 0.1(Guard) → 2.2.0.1(Middle) → 1.1(Exit), because that would violate the distinct subnets protection (more than one relay in 0.0/16) In addition to the IP address a Tor client never uses more than one relay from a given “family”. This safeguard depends on the relay operators actually declaring their group of relays in their configuration.

actually declaring their group of relays in their configuration. A Tor client only uses relays with the guard flag as their first hop — ignoring bridges for now. Guards are static over multiple months before rotating them.

A Tor client can only use relays with the exit flag to connect to the actual destination. (The guard and exit flags are not in place to mitigate this risk specifically but in practice they help as well because relay operators tend to run exits or none-exits exclusively, so they can not see both ends).

Are there relay groups that despite these safeguards could be used in multiple positions in a circuit?

Yes, but I guess most are probably not in that position because they want to harm you.

Finding relay groups in end-to-end correlation position

Relay groups in end to end correlation position run exits and guard-only relays in multiple netblocks.

To identify groups of relays one can use the ContactInfo field of relays. This is the easiest method, but keep in mind, that field is completely optional and a relay operator can provide an arbitrary string. That means anyone can setup relays with other people’s contact addresses. A relay operators would notice that when we contact them to update their family configuration.

We use the contact string to group relays with the same (or similar) contact. Once we find groups we check if they meet all the requirements for end-to-end correlation (multiple netblocks, no or incomplete family configuration, guard and exit probability > 0%).

Since this list changes over time it would be a bit pointless to list these relays here, instead I’m pointing you to the regularly updated list a my OrNetStats page:

https://nusenu.github.io/OrNetStats/endtoend-correlation-groups

Note: I’m not saying that these groups actually perform any deanonymization attacks but we should not have to trust any individual Tor relay operators (completely). That is a core principle of the Tor design.

Am I affected?

If you use one of the relays in the above list as your entry guard relay (static over multiple months) than you might sooner or later also use one of their exit relays (changes frequently) as well.

To find out if you use them currently as your entry-guard you can search for these fingerprints in your Tor “state” file located in your Tor client’s “DataDirectory”. The probability that you use them is around ~0.9% as of 2017–05–09. Even if they are not in the state file this might affect you in the future when your guard is rotated.

Mitigation