Sponsor-112.md

+# Combating Malicious Relays
+
+_We moved to track all tickets in this project with the _[_Label Sponsor 112_](https://gitlab.torproject.org/groups/tpo/-/issues/?sort=created_date&state=opened&label_name%5B%5D=Sponsor%20112&first_page_size=20)
+
+Our goal with this project is to ensure that human rights defenders, journalists, activists, and other marginalized people have a safe, secure experience on the Tor network by reducing malicious relay activity and improving the health of the network.
+
+Public meetings for this project happen in irc.oftc.net during the network-health meetings every Monday.
+
+### **Objective 1: Implement expanded network monitoring system and tools. In order to improve the network, we need to be able to better recognize relay operation patterns and add attributions to relays. Simply, we know that we need to have tools to better monitor relay groups that are being added to the network. When bad actors try to add relays to the network, they know that if they add them all at once and they are configured similarly, we will easily catch them and boot them out—so bad actors use varying tactics to evade detection. We need to build tools that will help us better monitor this behavior, for example, SybilHunter.**
+
+The role of each tool built in this Objective is to help humans on the network health team to better understand relay dynamics, be alerted to potential malicious activity, and track trends in the network. These tools are not designed to automatically remove relays or bridges, but to alert developers of potential issues in the network so they can be reviewed.
+
+Automatic removal of relays could cause unintended censorship and is not part of our approach. Not all relays that are not working correctly are necessarily malicious. Some relays may be misconfigured in a way that gives a safe but not fully functional experience for Tor users, and these issues can be remedied by contacting the relay operator, advising them of the issue, and the relay operator correcting the configuration of their relay.
+
+Further, these tools are monitoring the behavior and configuration of machines on the network—not monitoring data of or behavior of users. To ensure that this activity does not introduce privacy risks to relay operators or to users, we have included an activity to conduct a third-party privacy impact assessment on the tools we develop.
+
+To accomplish this Objective, we will:
+
+● O1.1: Build mechanisms to annotate, understand, tag and track relays to document their behavior and churn on the network. We will build a database with a developer-facing user-interface that displays and sorts annotations about relays. For example, when looking at groups of relays that appear to be different, yet turn out to be run by the same malicious operator, we've found that subtle characteristics like "when each relay restarts" provide valuable hints about correlation over time. Some annotations about relays in this database would be private so that administrators can make notes about potential malicious relays without informing an attacker, but we will explore publishing as much of the annotations as possible for transparency and so that external researchers can assist. We will track the implementation of the tools once these systems are in place.
+
+● O1.2: Improve network health monitoring tools. We will review the existing ecosystem of network health measurement tools, and select tools focusing on metrics meaningful to this project and those that require improved tooling, and we will work on improving these tools. Examples include mechanisms to capture baseline metrics for the network as a whole (e.g. how many relays are running, how diverse are they in terms of geography, operator, versions, etc.), baseline metrics for individual relays (e.g., bandwidth and its change over time, circuit handshake failure rate, etc.), and CAPTCHA Monitor, a tool for measuring and quantifying webserver-side blocking/discrimination against requests coming from the Tor network and Tor Browser. We will track the implementation of the tools once these systems are in place.
+
+● O1.3: Improve and deploy tools to automatically detect malicious relay activity. In this activity, we will improve and deploy two existing tools used to monitor malicious relay behavior on the live Tor network. The automatic detection is designed to alert developers when relays meet certain triggers (e.g., the ‘my family’ field has not been properly configured):
+
+- Margot, a Rust command line application with a series of commands used to monitor the network. Margot gives us similar functionality of SybilHunter, plus the ability to do more.
+- Exitmap, a modular Python-based scanner for exit relays that performs automated tests against every exit relay and looks for anomalies. We’re already using Exitmap in some scenarios. In this Activity, we need to document and evaluate current tests, identify and make necessary fixes, make improvements to expand coverage, and improve automation for responding to issues that Exitmap finds.
+- We will track the implementation of the tools once these systems are in place.
+
+● O1.4: Conduct a privacy impact assessment of monitoring tools with an external party. In this activity, we will engage a third party to conduct a privacy impact assessment of the tools developed in this Objective. The goal of this assessment is to investigate whether or not these tools impact the privacy of relay operators and to ensure that these tools are working in the most rights preserving ways possible. Should issues be discovered in this assessment, we will take recommended action to remedy them. This assessment will include both public- and internal-facing components of these tools. We will make a redacted, summarized, and/or plain language version of this report public.
+
+Deliverables:
+
+- Database with a developer-facing user-interface that displays and sorts annotations about relays.
+- Map of the Tor network health measurement tool ecosystem.
+- Margot is deployed for use on the network.
+- Improvements to Exitmap are deployed.
+- A privacy impact assessment is available.
+
+Outcomes:
+
+- Outcome: We can better monitor the Tor network for malicious activity.
+- Outcome: Malicious relays are more able to be quickly identified in the network.
+- Outcome: Investigations of malicious relays are more quickly resolved.
+- Impact: Human rights defenders, journalists, activists, and other marginalized people are safer and more secure when they use the Tor network to access the free, uncensored internet.
+
+Indicators:
+
+- Number of annotations registered in database we create.
+- Number of new metrics.
+- Time from beginning to end of a investigation on a suspected malicious relay.
+
+### **Objective 2: Establish community-driven behavioral agreements and consequences for relay operators. Relay operators run the backbone infrastructure of the Tor network. Part of what makes the Tor network successful or unsuccessful is this community. Working to improve the health of this community improves the network as a whole.**
+
+As the Tor network is decentralized, diverse, and global, this is no small task, but it is critical. An important mechanism of increasing trust between Tor users, the Tor Project, and relay operators is creating a code of conduct and/or establishing behavior expectations with relays and exit node operators that have clear consequences. We plan to evaluate such mechanisms (e.g., some potential solutions include policies, agreements, and codes of conduct that are either legally enforceable or enforced by directory authorities), and implement selected solutions based on this evaluation.
+
+As part of this Objective, we will engage with the relay operator community to collect input and feedback about potential solutions. We will use this feedback to shape our approach and define how we evaluate success.
+
+To accomplish this Objective, we will:
+
+● O2.1 Develop evaluation criteria for determining if behavior expectation and consequence solutions are appropriate. In this Activity, we will define evaluation criteria for the success of policies, agreements, and methods of enforcement. This Activity will allow the Tor Project to evaluate the solutions we choose in O2.3 and determine if we have met the community’s expressed needs. We will submit these criteria to DRL for approval.
+
+● O2.2: Evaluate promising solutions for relay operator code of conducts, policies, agreements and methods for enforcement. In this Activity, our goal is to engage relay operators and gather feedback about potential solutions around establishing behavior expectations and clear consequences. We will also organize the results of a year-long fellowship research project to better guide other activities under this Objective.
+
+- Gather input from the community on any concepts developed in this project. This involves online events and discussions where we engage with relay operators in different phases of the relay operator life cycle.
+- Develop recommendations for Objectives 2.3 and 2.4 based on the research findings and the relay operator personas definition developed as part of the fellowship alongside input collected in this Activity.
+
+● O2.3: Develop and implement solutions for operator codes of conduct, policies, agreements, and methods for enforcement. The code of conduct will codify what we expect of relay operators rather than leaving it implicit, as it is now. These guidelines mirror our criteria for rejecting bad relays. In this Activity we will: ○ Publish clear guidelines for (1) Tor to consistently identify and reject malicious relays, and (2) relay operators to understand what kind of behavior will not be tolerated and what steps are taken when certain activity is detected. ○ Use criteria developed in O2.1 to evaluate whether these behavior expectation and consequence solutions are appropriate per relay operator feedback.
+
+● O2.4: Document relay community governance processes. In this activity we will publish public-facing documentation on what enforcement mechanisms were considered, why the ones that were selected were chosen, and why the ones that were not implemented, but were considered as possible candidates, were eventually rejected. The audience for these documents will be future technology projects that utilize similar volunteer-run infrastructure and may be able to benefit from the insights Tor obtained during this process.
+
+● O2.5: Create threat model documentation. In this activity we will produce formal threat models and user-facing explanations for relay operators that cover the technologies, processes, and mechanisms developed in Objectives 1, 2, and 3 of this project. Prior to production of the threat model documentation, we will create a draft outline that we will share with DRL. We will work with a contracted technical writer to produce this documentation so that it is easily consumable and useful to the relay operator audience.
+
+Deliverables:
+
+- Evaluation criteria.
+- Survey results and feedback from relay operators.
+- Recommendations for Objectives 2.2 and 2.3 based on research with the relay operator community.
+- Implemented code of conduct for relay operators. We have a code of conduct for relay operators and clear consequences for what to do when relay operators break this code of conduct.
+- Documentation on policies, agreements and enforcement methods selection process.
+- Documentation on threat models and user-facing explanations for relay operators.
+
+Outcomes:
+
+- Outcome: It is harder for malicious operators to be a part of the community.
+- Outcome: Operators trust each other more.
+- Outcome: Community understands Tor decisions to remove operators.
+- Impact: The infrastructure and community that makes up the Tor network is stronger, healthier, and more sustainable.
+- Impact: Potential operators are more likely to join the network.
+
+Indicators:
+
+- Number of implemented solutions for relay operator codes of conduct and enforcement mechanisms.
+- Criteria developed as part of O2.1
+
+### **Objective 3: Make the Tor network more able to resist relay attacks. The goal with this Objective is simple: make it harder for people who want to run malicious relays to succeed in their goals of conducting a variety of attacks. Our approach involves implementing specific fixes to the Tor protocol to resist relay, traffic analysis, cryptographic tagging, and traffic manipulation attacks.**
+
+Relay attacks happen via traffic analysis, cryptographic tagging attacks, and traffic manipulation attacks. The research literature proposes a variety of solutions to make it more difficult for relays to attack users in these ways, and several prototype solutions are ready to implement.
+
+In this Objective we will:
+
+● O3.1: Audit the Tor protocol for dropped cell and other relay side channel attacks, and fix them in Rust for Arti. In this activity, we will review the Tor protocol and work on restricting cells that are semantically invalid or otherwise violate Tor protocol. Malicious relays can use invalid cells to create traffic patterns during periods of inactivity on a circuit in order to communicate with one another and deanonymize activity. In the research literature, this class of attack is called DropMark. The Tor design was originally permissive with respect to invalid protocol data, following what is called Postel’s Maxim. This maxim has since been rejected by the Internet community, and Tor’s previous adherence to it means that many areas in the protocol allow these side channels. The purpose of this audit activity is to eliminate the cases where invalid cells are permitted, and thus reduce the side channels available to malicious relays to inject traffic and harm anonymity. Changes resulting from this audit will be implemented in Arti, with some potential fixes at relays.
+
+● O3.2: Implement tagging resistant ciphers to reduce the ability of relays to perform route manipulation attacks. Tagging attacks are also side channels that allow malicious relays to communicate in order to deanonymize clients. They operate by exploiting the “malleability” property of the circuit encryption currently used in Tor, which allows the encryption stream to be modified without detection. Tagging attacks also allow malicious relays to close circuits that do not have another active malicious participant in them, so that in addition to communicating information to each other to aid in attacks, they can ensure that they only carry traffic that has been fully deanonymized by another malicious relay. To address this issue, we will evaluate and implement a non-malleable block cipher for use in circuit encryption. Ciphers in this class have the property that modifying an encryption stream renders it completely invalid, thus eliminating the side channel, preventing the possibility of communication, and vastly reducing route manipulation capability. The current leading tagging resistant cipher candidate is Counter Gallois Onion.
+
+● O3.3: Implement DoS defenses to reduce overall DoS overload risk to directory authorities and the network. During the course of this proposal review, revision, and evaluation process, the Tor network has experienced active attacks by at least four different groups of adversaries, all of which are still ongoing. Historically, we have also seen DoS attacks with regularity. During this proposal evaluation process, these attacks have caused loss of Guard relays, which impacts anonymity of clients, by forcing them to switch to possibly malicious Guard relays, which can then perform the above or other attacks. Additionally, attacks have been mounted against the directory authorities, to influence their operation, as well as to delay bootstrapping of new Tor clients. The goals of these adversaries are manifold: some appear to be intent on merely causing disruption to discourage new users from using Tor; others appear to coincide with malicious relay appearance and activity; still others appear to be simply the result of other attacks being mounted through the Tor network. We will implement rate limiting and structural defenses for these attacks in priority order: first targeting attacks of continuing ongoing nature, and then focusing on attacks of common historical prevalence. We have already seen adversarial adaptation from some of these adversaries to target different scarcity conditions on non-malicious relays and directory authorities. We expect this adaptation to continue and we will adapt our approach to this activity as new attack tactics are observed.
+
+● O3.4: Implement mechanisms to support TrafficSliver and Interspace traffic analysis defenses in Arti, the Rust re-write of Tor code. Malicious Guard relays, bridges, and Internet routers can perform a class of traffic analysis attack called Website Traffic Fingerprinting. This attack allows them to recognize websites by the traffic patterns they create, so that they can decide to censor or otherwise target specific users. While these attacks are statistical and expensive to mount by themselves, they are aided through various other side channels called oracles, which can make them much more practical, by reducing the volume of traffic that needs to be considered. The combination of these factors allows these attacks to be dangerously close to practicality by low-resourced adversaries. We will address known oracles in the Tor protocol, which will reduce the utility of these attacks by malicious relays and internet routers. We will also provide support for traffic splitting and traffic padding defenses, the two leading examples of these being TrafficSliver and Interspace. These classes of defenses are also currently being investigated by VPN providers, and we expect to be able to share defense tuning results with those implementations. We will ensure that these two classes of defenses are supported in Arti, for further evaluation and tuning by the research community.
+
+● O3.5 Implement formal mechanisms for detecting relays lying about their bandwidth capacity. In order to receive a larger portion of traffic to mount attacks, malicious relays can lie about their capacity. This allows them to perform attacks on a larger portion of the Tor user base than they normally would. By analyzing already-existing information from our load balancing system, as well as our performance metrics sensors, we can detect outlier relays that have significantly lower actual performance than their self-reported bandwidth values claim, when compared to similar relays. We can then subject these relays to further tests, to determine if this discrepancy is likely malicious. Relays that have large confirmed discrepancies between claimed values and actual performance will be contacted to diagnose any potential issues, and failing improvement, removed from the network. During the course of this grant, we will also evaluate research prototypes for improving this detection capability and consider their adoption, subject to their implementation quality and expected engineering costs vs benefits.
+
+Deliverables:
+
+- Tor specification is updated to improve defenses against guard discovery attacks.
+- Tagging resistant ciphers are deployed.
+- DoS defenses are deployed.
+- Mechanisms to support TrafficSliver and Interspace traffic analysis defenses in Arti are deployed.
+- There is a tool deployed that can support detection of relays lying about their bandwidth.
+
+Outcomes:
+
+- Outcome: DoS attacks have less ability to shift traffic to possibly malicious nodes.
+- Outcome: Attacks against Tor outlined in research have been addressed.
+- Outcome: The Tor network is protected against relays trying to inflate their bandwidth.
+- Outcome: We expect to see less DoS attacks, network attacks, and malicious relays on the network, as their incentives and ability to perform successful attacks goes down.
+- Impact: Human rights defenders, journalists, activists, and other marginalized people are safer and more secure when they use the Tor network to access the free, uncensored internet.
+
+Indicators:
+
+- Number of solutions evaluated and implemented
+- Number of relays lying about their bandwidth capacity
\ No newline at end of file