After I reported the export relays (I didn’t know they were part of KAX17 at the time), they were removed in October 2020, but I think this did not completely stop their export operations. Coincidentally, a new large-scale unnamed export relay team was born the day after they stepped down. This new group is not included in Figure 1 because it cannot be attributed to KAX17 using the same strong indicator.
In order to provide a worst-case snapshot, the overall Tor network visibility on 2020-09-08 KAX17 will allow them to deanonymize Tor users with the following probability:
- Probability of first jump (guard): 10.34%
- Probability of second jump (medium): 24.33%
- Probability of last hop (exit): 4.6%
Since the intermediate and outlet relays are frequently changed, the possibility of using KAX17 relays will increase with the use of Tor. We have no evidence that they are actually performing a de-anonymization attack, but they are capable of doing so, and someone runs such a large part of the network to relay “doing things”, something that ordinary relays cannot do (intentionally ambiguous) ), enough to sound all kinds of alarm bells.
During 2020, a large number of suspicious non-export relays joined the network and reported to the Tor project, but since they are no longer deleted, I sent them to the public Tor-talk mailing list because their capacity continues to increase (2020-08-20, 2020-09-22).
Unexpected hints help to better understand this mystery
At the time (2020), I didn’t have a strong linkability indicator for these large non-exported relay sets of KAX17 actors-this changed a few weeks ago (fall 2021) when a reader of the blog reached out and shared Their notes are about a group of suspicious relays. We independently verified and replicated their observations on a technical level. When placed in a broader context, their tips help understand the larger picture by providing powerful indicators of all these relays:
- Is actually operated by a single entity, and
- All of these are actually part of KAX17.
What is special about KAX17?
KAX17 is more worrying than the usual malicious Tor egress relay group, because they seem to be very keen to have a great understanding of the network’s non-egress locations (entry guards and intermediate relays). These locations are useless for the usual malicious actors who manipulate and sniff egress traffic because there is no clear text traffic available at these locations. Participants who perform attacks in these non-exit locations are considered more advanced adversaries because these attacks require a higher degree of complexity and are not easy to implement.
Some parts of this story remind me of the so-called “Relay early“Traffic confirmation attack from the backend Year 2014 Combine running malicious relays with active Tor protocol level exploitation to deanonymize the onion service (called “hidden service” at the time) and its users, because this is one of the rare cases, you can also see Involving non-exit attack relays. Other than that, nothing points in that direction.
KAX17 participates in the tor-relays policy discussion
When viewing the metadata of the KAX17 relay, I repeatedly encountered a specific email address. Some KAX17 relays initially used this email address in their ContactInfo, but shortly after setting up these relays, the email address was removed from their configuration.I am also here Tor-relay Mailing Lists. Interestingly, when discussing policy recommendations on malicious relaying or deleting large malicious relay groups, it almost only appeared on the mailing list. They obviously don’t like suggestions that make their activities less efficient 
Since everyone can use your email address in their relayed ContactInfo, this information is not necessarily true, but because the email address first appeared on the tor-relays mailing list on the KAX17 relay long before Use it on it, I think it’s terrible Operational safety As far as they are concerned.
Obviously, tor users have powerful opponents and a lot of resources in their hands. This is a particularly uncomfortable situation because it is known that some participants have been running most of the Tor network for years and will continue to do so. It’s also obvious that even with such a large-scale relay group, we can’t find it in time – let alone be removed.When Tor directory authorities take action, KAX17 operations may be severely degraded be opposed to They were in November 2021, but they have begun to regain their foothold, as they did after they were removed for the first time in October 2019, so we will need something more sustainable when dealing with malicious relays solution.
In the past, I have been reluctant to change the Tor client configuration that affects path selection because it makes the Tor client stand out in theory, but given the threat landscape of the Tor network, I think this is reasonable (for some threat models, Even necessary) self-defense behavior, stop using untrusted relays for certain path locations to reduce the risk of de-anonymization and other types of attacks-even if this is a non-default configuration.
In order to achieve this goal, customers need to:
(1) Configure trusted operators or learn about them through so-called trust anchors
(2) Automatically enumerate the relays of all trusted operators
(3) Automatically configure the tor client to only use trusted relays in certain locations, such as entrance guards and/or exit relays
This design allows tor users to assign trust at the operator level and inherit this trust to all relays managed by the operator. This should ensure scalability and not susceptible to changes, such as when adding or replacing new relays.
Unspoofable operator identifier
How do we solve (2)? The Tor network does not have the identifier of the relay operator. There is a relayed ContactInfo string, but it is not safe to use it without any verification scheme and has been exploited by malicious operators in the past. So we need some operator identifiers that cannot be arbitrarily deceived by opponents. Fortunately, we were not unprepared for this. In 2020 I wrote a specification (International Information and Security Institute) Allows Tor relay operators to link their relays to their domain/hostname in a verifiable manner. This is achieved using a simple 2-way link from the relay to the domain and back to the relay from the domain.In practice, operators must perform two simple steps, according to Specification:
- Add to
url:example.com Proof:uri-rsa ciissversion:2
Contact information to her relay - release Relay fingerprint in IANA Registered well-known hatred:
https://example.com/.well-known/tor-relay/rsa-fingerprint.txt
(Or create a DNS TXT record).
In the past few months, verified domains have been widely implemented by most large export operators in the Tor relay community, and currently more than 50% of the Tor network export capacity has been covered (the more the better):
This provides tor users with a non-spoofable, automatically verifiable operator identifier they can assign to trust. It is important to emphasize that verified domains are not implicitly trusted, and malicious groups can also prove their domains. This is only the first step, the user can choose a trusted identifier. The use of verified operator domains to protect relays is much less (about 10% protection probability), until this proportion increases, users can configure trusted relays as bridges to reduce their use of malicious protection chance.
Trusted operator domain
In this case, trust means that the relay operator is considered to operate the relay without malicious intent. The detailed information on the release and use of trust information is listed in this draft specification: Simple trust network for Tor relay operator IDIt allows dynamic discovery of trusted operators starting from a trust anchor (optional), but it also supports stricter manual-only trust assignment (no recursive discovery)-this is up to the user.
Proof of concept implementation
We have done a quick and dirty proof of the concept of the above steps and will publish it with this blog post. It is not suitable for general use by end users.
https://github.com/nusenu/trustor-poc
It is implemented as a python script that talks to the local Tor client through its control port/socket, uses the list of trusted operator domains to read local files, verifies the relay/domain certification (via Tor) and configures the Tor client Use exit relays that are only run by trusted operators. The list of trusted operators is defined by the user.
We want to implement a practical and serious implementation, and we may update it in the next few months.
- Since 2017, the mysterious actor we gave the codename KAX17 has been running most of the Tor network, despite multiple attempts to remove it from the network in the past few years.
- KAX17 has been operating relays in all positions (guards, middle and exit) of tor circuits in many autonomous systems, enabling them to deanonymize some tor users.
- Their behavior and motives are unclear.
- We found strong signs that the email addresses linked by KAX17 participated in the Tor-relay mailing list discussion related to the fight against malicious relays.
- Detecting and removing malicious Tor relays from the network has become an unrealistic problem that needs to be solved.
- We have proposed a design and proof of concept implementation that aims to provide Tor clients with better self-defense options to reduce the risk of malicious relays without the need for detection.
- The exit capacity (>50%) of most Tor networks already supports this design. More protection relays with verified domains are needed (currently about 10%).
I would like to thank those who provided important suggestions for a better understanding of KAX17’s relays. The person requested to remain anonymous.
The figure below shows the network capacity of KAX17 (at least as we know it). The detection method must have false negatives (some relays we did not attribute to them).
