Filename: 344-protocol-info-leaks.md
Title: A New Threat Model for the Tor Protocol
Author: Mike Perry
Created: 2023-07-17
Purpose: Normative
Status: Open

Table of Contents

0. Introduction
   • 0.1. Background: Gaps in Tor's Original Threat Model
   • 0.2. A Unified Threat Model
   • 0.3. Threat Model Scope
   • 0.4. Performing Security Analysis
1. Categorized Attack Vectors
   • 1.1. Reliable Internal Covert Channels
     • 1.1.1. Cryptographic Tagging
     • 1.1.2. End-to-end cell header manipulation
     • 1.1.3. Dropped cells
   • 1.2. Behavior Manipulation
     • 1.2.1. Guard Trapping Attacks
     • 1.2.2. Adversary-Induced Circuit Creation
     • 1.2.3. Recognizable Protocol Activity
     • 1.2.4. Adversary-Induced Circuit Failure
     • 1.2.5. DoS/OOM Attacks against Relays
     • 1.2.6. Directory Authority Vote and Consensus Manipulation
     • 1.2.7. Relay Bandwidth Lying
   • 1.3. Augmented Observation
     • 1.3.1. Netflow Observation
     • 1.3.2. Metrics Leakage
     • 1.3.3. DNS Cache Oracles
     • 1.3.4. Active Traffic Manipulation Covert Channels
     • 1.3.5. Passive Application-Layer Traffic Patterns
     • 1.3.6. Protocol or Application Linkability
     • 1.3.7. Latency Measurement
     • 1.3.8. BGP Hijacking
2. Worked Security Analyses
   • 2.1. Selective Guard Failure
   • 2.2. Alternate Consensus Delivery
3. Historical Attack Examples
   • 3.1. CMU Tagging Attack
   • 3.2. Guard Discovery Attacks with Netflow Deanonymization
   • 3.3. Netflow Anonymity Set Reduction
   • 3.4. Application Layer Confirmation
4. Glossary

0. Introduction

This document defines a unified threat model for the Tor network protocol and Tor client behavior.

Application-specific threat models for Tor Browser, TorVPN, and Tails are covered in those respective threat model documents.

Readers who are relatively new to anonymity literature may wish to first consult the Glossary in Section 4, especially if terms such as Covert Channel, Path Bias, Guard Discovery, and False Positive/False Negative are unfamiliar or hazy. There is also a catalog of historical real-world attacks that are known to have been performed against Tor in Section 3, to help illustrate how these attack vectors have been used adversarially, in practice.

0.1. Background: Tor's Original Threat Model

Tor's original threat model focused on local adversaries who can observe limited portions of the Tor network, excluding global adversaries with full network visibility.

In that model, the distributed trust properties of a network run by multiple distinct entities works in Tor's favor. A local adversary observing a fraction (c/n) of the network's entrance and exit capacity is expected to deanonymize only (c/n)^2 of traffic, thanks to Tor's random entrance and exit selection. (This compromise estimate was altered slightly, to account for guard nodes; see part 2 of [TOR_DESIGN_UPDATES]. We retain the original estimate for simplicity of explanation.)

Though not required by a local adversary threat model, Tor also considered traffic confirmation attacks (where an adversary observes both ends of a communication to confirm its occurrence) to be out of scope. Tor's threat model implicitly assumed that such observations were always 100% accurate and not worth defending against in specific. This assumption underpins the (c/n)^2 deanonymization estimate.

Tor's original design paper defined traffic analysis attacks as attacks where an adversary uses traffic patterns to learn where they need to attack, in order to maximize the utility of its c/n observation capability. Tor's original design paper considered these attacks to be in scope.

0.1.1. Limitations of Tor's Original Threat Model

Tor's fractional local-adversary analysis estimates the probability that an adversary can observe the required network positions, but it does not properly address the capabilities of active local attackers to influence client behavior.

Tor's distributed path selection limits joint observation and provides distributed trust only when relay selection remains independent and the adversary cannot create reliable internal signals, manipulate client or relay behavior, or augment its observation with additional data.

Furthermore, by dismissing all forms of end-to-end confirmation without considering accuracy, Tor's original threat model was ill-equipped to differentiate between attacks that can be performed instantly, reliably, and quietly, versus attacks that require large volumes of data over a very large number of distinct observations.

0.2. A Unified Threat Model

In this updated threat model, we retain Tor's local fractional adversary analysis as the baseline for unmanipulated path selection, but we expand the treatment of this adversary to cover active capabilities uncovered by the research literature, as well as ways that a local adversary can use external data sources to extend its visibility and approximate a global passive adverary with low fidelity.

Tor's original threat model scope falls short in three areas, which we propose to be now explicitly in-scope, as valid Tor attack categories warranting development prioritization, and future funding allocation consideration:

1. Internal Covert Channels: Traffic confirmation vectors in the Tor Protocol itself provide reliable internal covert channels that relays can use to reliably manipulate circuit use prior to any application usage, in ways that are invisible to users and applications. The resulting path bias capability completely removes Tor's distributed trusty property at malicious Guard relays (and at malicious ISPs that only allow usage of malicious Guards), by enabling these Guards to ensure that only colluding Exits are used by clients, while also transmitting recognizable unique identifiers to these Exits. This yields full-take deanonymization of all user activity that uses that malicious Guard (or malicious ISP).

2. Behavior Manipulation: Traffic analysis attacks can make use of various behavior manipulation mechanisms to elicit specific unique Tor protocol activity, and to erode Tor's distributed trust property to observe it. The resulting Tor protocol activity provides a traffic confirmation vector that they can reliably observe, on demand, without requiring any user-initiated application activity.

3. Augmented Observation: Traffic confirmation attacks can be built upon mechanisms of augmented observation that enable an adversary to construct low-resolution approximations of global adversaries, through novel forms of traffic observation. In these cases, we now have practical, real-world attack scenarios where traffic observation does not guarantee traffic confirmation with 100% accuracy, in ways that enable and shape the development and deployment of defenses.

Over the past two decades of academic research and real-world attacks on the Tor network, all significant attacks directly involving the Tor protocol have been related to one of these three new threat model categories.

We do away with the distinction between traffic analysis and traffic confirmation for defining scope, and instead directly consider the false postive and false negative rates associated with each attack vector. We also consider the adversary's positional requirements, active capability requirements, and ultimate impact of each attack vector in these categories.

As we shall see, under this analysis the three new categories also correspond to a severity ordering: Covert Channels directly inside the Tor Protocol yield more comprehensive deanonymization capability than Behavior Manipulation, and Behavior Manipulation typically is used to assist Augmented Observation to become sufficiently accurate for deanonymization.

To support this ordering, we also examine the anonymity impact that each attack vector in each category enables. This examination drives the severity ordering of each vector within its category. The most severe vectors are listed first within each category.

Each attack vector also has a common solution, and some vectors share the same solution as other vectors.

0.3. Threat Model Scope

This threat model specifically covers only the Tor network and Tor protocol.

This threat model does not attempt to cover endpoint compromise or application-specific security failures. Application-layer threat models and security goals are maintained separately for Tor Browser, TorVPN, and Tails. Applications that were not specifically designed for use with Tor inherently carry additional application-layer risks: they may bypass Tor, expose identifying state, or make device and application side channels available to a remote adversary.

Examples outside this document's scope include:

• Onion-service clock-skew fingerprinting of the host machine (see [CLOCK_SKEW])
• Onion-service content, certificate, and configuration leaks (see [CARONTE])
• BitTorrent or DHT behavior that exposes a direct IP address, followed by application-identifier linkage (see [BAD_APPLE])
• Ultrasound cross-device tracking (see [ULTRASOUND])
• Device side channels such as website inference through a malicious USB charger (see [USB_SIDE_CHANNEL])
• Browser plugins, helper applications, or other direct-network bypasses

These kinds of issues are anonymity set reduction, information leaks, linkability, and/or Tor bypass issues that are independent from Tor network traffic or usage of the Tor protocol itself.

Cases where an application's traffic patterns or connection retry behavior can enhance its vulnerability to Tor network traffic analysis remain in scope for this document and associated security analysis.

0.4. Performing Security Analysis

When an adversary performs an attack, they have three goals:

1. Link a client or onion service to its network location or identity.
2. Link a client or onion service to particular destinations or activity.
3. Discover the relays or paths used by a client or onion service as a step toward either of the first two outcomes.

The categorization framework used in this document should be applied before making a decision about a suspected anonymity risk with respect to the adversary's ability to accomplish these goals.

Such analysis should:

1. Name the adversary's capability and intended outcome, and map the attack to a vector in this document (or propose an amendment for a missing vector).

2. Describe the steps that turn the underlying defect or feature into that outcome, including any required combination with other vectors.

3. For each step, state whether the adversary passively observes or actively injects, modifies, suppresses, or provokes traffic or behavior to observe an attack vector's signal. Separately identify who generates each distinguishing signal.

4. Roughly quantify or describe the affected population and success probability, including ballpark estimates of false positives, false negatives, and the base rate of impacted activity. State the assumptions behind the analysis, including whether relay fractions represent counts or selection weights and whether the sets overlap.

5. Discuss the required attack duration, what the adversary can observe after each attempt, the ability to perform repeated attempts, and opportunities for detection.

6. Compare the potential mitigations with the concrete cost and risk of the proposed response, including the risk of improper remediation, capability loss, or follow-on bugs.

For comparisons between vectors, analyses must distinguish several quantities that are easy to conflate:

• Signal accuracy is the false-positive and false-negative rate after the adversary has obtained the required observation position and the signal has been generated. The base rate under consideration while looking for the signal's presence must also be estimated.

• Position probability is the probability that the adversary obtains the required relay positions or network vantage points. Relay fractions must state whether they are fractions of relay count, consensus weight, or position-specific selection weight, and whether the controlled sets overlap.

• Trigger or delivery probability is the probability that the target receives an injected input or performs the behavior that generates the signal.

• Outcome probability is the probability that one attempt achieves the stated security outcome after accounting for position, trigger or delivery, signal recognition, and any follow-on steps. Zero signal error does not imply that an attack succeeds with certainty.

NOTE: Many research papers that employ statistical attacks and machine learning classifiers use additional metrics beyond false positive and false negatives (typically including precision, recall, wrong positives, and/or ROC curves). See the glossary for those definitions and notes on how they relate to the FP and FN rates that we use in this threat model document. Even papers that specify the full suite of machine learning metrics can still suffer from the base rate fallacy, by underestimating or miscounting the volume of activity that must be considered for their attack to be carried out. This is particularly common in passive traffic analysis attack papers.

For a multi-stage attack, give the conditional probability of each stage when possible. An overall estimate can then be expressed as the product of those conditional probabilities, with dependencies called out rather than silently assuming independence. If a quantity is unknown, state that and give useful bounds or the variables on which it depends instead of substituting a qualitative accuracy label.

Analyses should also use a common unit of comparison. Define what constitutes one attempt, the feedback available after it, the retry rate and stopping condition, and whether failed attempts consume or expose relay positions. State whether the affected population is one selected target, the users of a relay, the users behind a network adversary, or the whole Tor network. Finally, give the expected persistence of the effect, likely detection points and detection time, and these same quantities after currently deployed mitigations.

This analysis is required prior to proposing a course of action in response to a newly discovered security issue or research finding, and all proposed courses of action must be anchored in such analysis.

The adversarial relay fraction c/n is an input to this analysis, but the means of obtaining those positions must still be stated. An adversary may run or compromise relays, introduce many Sybil identities, or manipulate relay selection through the vectors in this document. Analysis must consider the ability of such Sybil identities to be maintained despite efforts of the Network Health team's relay vetting and validation procedures.

Analyses must also state if/when directory authority or consensus compromise is involved; control of those systems grants capabilities beyond merely operating fraction c/n of relay capacity.

See the Worked Security Analysis section for examples of this analysis being applied to attack vectors and security issues.

1. Categorized Attack Vectors

This section defines and prioritizes attack vectors according to the three categories enumerated earlier: "Reliable Internal Covert Channels", "Behavior Manipulation", and "Augmented Observation". Within each category, vectors with the highest impact are listed first.

For each vector, we provide a brief "at-a-glance" summary table, which includes a ballpark estimate of Accuracy in terms of False Positives (FP) and False Negatives (FN), as 0, near-zero, low, medium, or high. We then list what is required to make use of the vector, the impact, the reason for the prioritization, and some details on where the signal is injected and observed.

At the end of each section, we provide another table with the mitigation plans and status of that vector.

1.1. Reliable Internal Covert Channels

A covert channel is a mechanism by which malicious entities in a communication channel can recognize and communicate with each other.

Reliable Internal Covert Channels are created by traffic confirmation vectors inside of Tor's protocol.

In order to be classified as a Reliable Internal Covert Channel, a vector must satisfy four properties:

1. It must be usable before a circuit is carrying application traffic.

2. It must be immediately recognizable as an end-to-end collusion signal on a circuit, such that the adversary can confidently close all circuits that do not contain this signal.

3. It must have a zero or near-zero false positive and false negative rate for this collusion signal.

4. It must leave deanonymized circuits usable, so the adversary can carry traffic while rejecting circuits without the signal. A channel that always destroys its circuit can aid Guard Discovery, but cannot capture usable routes. For example, see the analysis of DESTROY reasons under Recognizable Protocol Activity.

These four properties enable relays to fail all circuits that are not deanonymized (a process called Path Bias). This removes a c/n factor of Tor's distributed trust properties, increasing these relays' share of deanonymized Tor traffic from the expected (c/n)^2 to c/n.

To highlight how vectors can combine: If the adversary also has the Guard trapping capability from Section 1.2.1 to censor Tor clients to use only specific Guards, they can ensure that users only connect to compromised Guards (or Bridges). These Guards can in turn use this section's covert channels to ensure that all of these circuits are directed only to compromised Exits. This removes both c/n factors, fully deanonymizing all users who are subject to this censorship firewall. In these specific circumstances, Tor is actually less secure than a 1-hop VPN.

This style of censorship-based deanonymization attack was first academically published in [TRAPPING_TOR], and it also includes a covert channel. However, their covert channel (stream correlation) does not satisfy the first requirement of this section, because it relies on streams already sending data. In practice, this means that targeted users would notice their connections were repeatedly being terminated mid-download, and would have great difficulty actually using Tor to download anything. The covert channels in this section, by contrast, enable closing circuits before application traffic begins, thus making them invisible to targeted users, other than as a higher circuit failure rate.

1.1.1. Cryptographic Tagging

At a Glance:

First reported at Black Hat in 2009 (see [ONECELL]), and elaborated further with the path bias amplification attack in 2012 by some Raccoons (see [RACCOON23]), this is the most severe vector of covert channel attack to have been discovered in Tor.

Cryptographic tagging is where an adversary who controls a Guard (or Bridge) XORs an identifier, such as the client's IP address, directly into the circuit's cipher-stream, in an area of known-plaintext. Prior to Tor's CGO circuit encryption upgrade, this tag could be exactly recovered by a colluding exit relay, ensuring zero false positives and zero false negatives for this built-in identifier transmission, along with their collusion signal.

Additionally, because every circuit that does not have a colluding relay would automatically fail due to a failed relay cell digest validation, the adversary would gain a free amplification attack, such that their relay only actually carries traffic that they know they have successfully deanonymized. Because clients continually attempt to re-build circuits through the guard until they hit a compromised exit and succeed, this violated Tor's distributed trust assumption, reducing it to the same security level as a one-hop proxy (ie: the security of fully trusting the Guard relay).

Worse still, when the adversary had full censorship control over all connections into the Tor network, Tor provided zero anonymity or privacy against them, when they used this vector in combination with the guard trapping attacks vector in Section 1.2.1.

Because the Exit was able to close all circuits that do not contain this tag, the adversary's Guard capacity could exactly match their Exit capacity. They did not need to carry any Tor traffic that they had not full deanonymized.

If the adversary did not have censorship capability, their relays could lie about their bandwidth, or DoS other guards to make themselves more likely to be chosen as Guards.

This attack, and path bias attacks that are used in the next two sections, have some minor engineering barriers when being performed against both onion and exit traffic, because the onion service traffic is restricted to particular hops in the case of HSDIR and intro point circuits. However, because pre-built circuits are used to access HSDIR and intro points, the adversary can use their covert channel such that only exits and pre-built onion service circuits are allowed to proceed. Onion services are harder to deanonymize in this way, because the HSDIR choice itself can't be controlled by them, but they can still be connected to using pre-built circuits until the adversary also ends up in the HSDIR position, for deanonymization.

Mitigation Plan:

1.1.2. End-to-end cell header manipulation

At a glance:

The Tor protocol consists of both cell header commands, and relay header commands. Cell commands are not encrypted by circuit-level encryption, so they are visible and modifiable by every relay in the path. Relay header commands are encrypted, and not visible to every hop in the path.

Not all cell commands are forwarded end-to-end. Currently, these are limited to RELAY, RELAY_EARLY, and DESTROY. Because of the attack described here, great care must be taken when adding new end-to-end cell commands, even if they are protected by a MAC.

Previously, a group of researchers at CMU used this property to modify the cell command header of cells on circuits, to switch between RELAY_EARLY and RELAY at exits and HSDIRs (see [RELAY_EARLY]). This creates a visible bit in each cell, that can signal collusion, or with enough cells, can encode an identifier such as an IP address. They assisted the FBI, to use this attack in the wild to deanonymize clients.

We addressed the CMU attack by closing the circuit upon receiving an "inbound" (towards the client) RELAY_EARLY command cell, and by limiting the number of "outbound" (towards the exit) RELAY_EARLY command cells at relays, and by requiring the use of RELAY_EARLY for EXTEND (onionskin) relay commands.

This defense was not generalized, though. Guards could still use this specific covert channel to send around 3-5 bits of information after the extend handshake, without killing the circuit. It was possible to use the remaining outbound vector to conduct a path bias amplification attack in combination with dropped cell covert channel attacks. In this case, these 3-5 bits would just be a collusion signal to the exit to keep the circuit (or to close it when the signal is absent). This would reduce the amount of non-compromised traffic that malicious exit must carry (see the following Section 1.1.3).

If the adversary is an ISP with censorship capability, this combined vector was possible to use to deanonymize all Tor traffic at that ISP, using [TRAPPING_TOR] Guard filtering.

While more cumbersome than cryptographic tagging attacks from Section 1.1.1, in practice this attack was just as successful when these cell command types were not restricted and limited.

CGO circuit-level encryption eliminated the ability of Guards to alter cell commands via a MAC, but Exits, HSDir, and Intro Point relays will still be able to make use of the vector towards the client, if it is not mitigated at the client by closing the circuit. Additionally, this MAC will not prevent this covert channel from being used all the way from an onion client to an onion service, or vice-versa, on a rend circuit, especially one with a malicious RP relay.

Mitigation Plan:

1.1.3. Dropped cells

At a glance:

Dropped cells are cells that a relay can inject that end up ignored and discarded by a Tor client. These include:

• Unparsable cells
• Unrecognized cells (ie: wrong source hop, or decrypt failures)
• Invalid relay commands
• Unsupported (or consensus-disabled) relay commands or extensions
• Out-of-context relay commands
• Duplicate relay commands
• Relay commands that hit any error codepaths
• Relay commands for an invalid or already-closed stream ID
• Semantically void relay cells (incl relay data len == 0, or PING)
• Onion descriptor-appended junk

Additionally, clients can send arbitrary relay commands to onion services, which includes the above set, plus:

• RELAY_BEGIN to invalid addrs/ports (onion service port scanning)
• RELAY_BEGIN to reused stream-ids
• Relay commands normally reserved for relays or exits
• Optimistic data sent to invalid onion service ports

The attack works by injecting inbound RELAY cells at the exit, HSDir, Intro Point, or client, and then observing anomalous traffic patterns at the guard or at the client->guard connection.

The accuracy of this covert channel is extremely high (zero false positives; zero false negatives) when these cells are injected in cases where the circuit is otherwise known to be silent, because of the protocol state machine. These cases include:

• Immediately following an onionskin response
• During other protocol handshakes (onion services, conflux)
• When the onion service client is adversarial

Because of the stateful and deterministic nature of the Tor protocol, especially handshakes, it is easy to accurately recognize these specific cases even when observing only encrypted circuit traffic at the Guard relay (see [DROPMARK]).

Because this covert channel is most accurate before actual circuit use, when the circuit is expected to be otherwise silent, it is trivial for a Guard relay to close every circuit that does not display this covert channel, providing path bias amplification attack and distributed trust reduction, similar to cryptographic tagging attacks and end-to-end cell header manipulation.

Consistent with the criteria for Section 1.1, this ability to use the collusion signal to perform path bias before circuit use differentiates dropped cells within the Tor Protocol from dead weight traffic during application usage (such as javascript requests for 404 URLs, covered in Section 1.3.4).

This category is not quite as severe as these previous two categories by itself, for two main reasons:

1. First, the collusion signal is only one way: the Exit can't use this covert channel to close circuits that are carried by a non-colluding Guard, since there is no covert channel from the Guard to the Exit with this vector alone. Thus, unlike cryptographic tagging, the adversary's Exits will still carry non-deanonymized traffic from non-adversary Guards, and thus the adversary needs more Exit capacity than Guard capacity, to carry out deanonymization with this vector alone. These kinds of more subtle trade-offs with respect to path bias are covered in [DOSSECURITY].
2. Second, encoding a full unique identifier in this covert channel is non-trivial. A significant amount of injected traffic must be sent to exchange more than a simple collusion signal, to link circuits when attacking a large number of users. In practice, this likely means some amount of correlation, and a resulting (but very small) statistical error.

Obviously, the actual practical consequences of these two limitations are minimal, so this covert channel is still regarded as reliable. It can still result in full deanonymization of all Tor traffic by an adversary with censorship capability, with very little error.

The mitigation for this attack vector is for clients and onion services to close any circuit with invalid end-to-end data.

The DESTROY cells used for circuit teardown should be prioritized at relays, to minimize side channel capacity and to reduce memory bloat potential. To handle the case where the Guard itself maliciously ignores DESTROY cells, RELAY_COMMAND_TRUNCATED could be sent to the middle relay prior to sending the destroy. This is not currently done by either C-Tor or Arti, but it would be a defense-in-depth improvement.

The channel on the other hand MUST NOT be closed in these cases. Closing the entire channel creates a loud Netflow signal and disrupts unrelated circuits, giving the adversary another observable effect.

Channel-level gibberish from the Guard is different. A client may reject a Guard that sends an unknown or non-negotiated cell command for protocol correctness. This does not reveal information the Guard lacks: it already knows the client and can close their channel at will. The distinction is tracked in torspec#385.

Mitigation Plan:

1.2. Behavior Manipulation

These attack vectors are less severe than the first group, because they do not provide full control of all circuit usage, by themselves.

Instead, they enable the adversary to control or manipulate client behavior, and combine it with relative uniqueness of Tor Protocol handshake traffic patterns, to build potent attacks, without any user-initiated application activity. In some cases, this still results in full deanonymization.

Importantly, these attack vectors and their resulting impact still are entirely the fault of the Tor Protocol and Tor implementation behavior, and are not inherent to low-latency mix networks in general.

1.2.1. Guard Trapping Attacks

At a glance:

As already mentioned, an adversary with a censorship firewall, local network, or ISP control can restrict a Tor client to only connect to their malicious Guard relays. If they are able to use a reliable internal covert channel from the previous section, they can then perform full deanonymization of all Tor client traffic on their network.

This attack vector is possible primarily because Tor clients continually try to connect to Guard relays until enough primary guard connections succeed, without stopping to alert the user at any point. This behavior is an artifact of from before Tor Browser had easy-to-use bridge autoconfiguration; in the hope it might help some forms of censored clients connect easier. Now, however, it is not necessary. (Tor Browser bridge autoconfiguration is rate limited, which minimizes this attack vector there).

This behavior also permits a slow-roll attack: instead of blocking all honest Guards at once, the adversary can block them one at a time as the client tries them. The client eventually settles on adversary-controlled Guards without a clear failure that would alert the user or engage censorship-circumvention features. This problem and a redesign of Guard selection are tracked in torspec#320.

The affected population is the set of clients whose Guard reachability the network adversary can control. Conditional on the client continuing to retry, blocking every honest candidate while allowing an adversarial Guard makes eventual adversarial Guard selection effectively certain. The number and duration of attempts depend on the client's sampled Guard set, retry schedule, bridge use, and stopping or warning thresholds.

This style of censorship-based deanonymization attack was first academically published in [TRAPPING_TOR]. It is worth repeating that their covert channel in that paper is stream data correlation, which is not a reliable internal covert channel. For most applications, the repeated connection termination mid-download will be noticeable to the user, and will make their application unusable.

However, if the adversary is attacking an onion service, or has control of a website used by their target, they can use active traffic manipulation to confirm activity at their Guard, to deanonymize the user. They can also make use of the other vectors in this section to manipulate client activity, and detect this maniupulation at their Guard.

In order to mitigate this attack, Tor clients need to be less aggressive with probing Guards until they succeed, and alert the user if too many fail, instead of silently succeeding. If either [GUARDSETS_2015], [GUARDSETS_2018], or related ideas in torspec#320 are implemented, clients could refuse to use anything other than a specific set of guards. It would also make it more challenging for such an adversary to control all client guards in a set.

Mitigation Plan:

1.2.2. Adversary-Induced Circuit Creation

At a glance:

By itself, the ability for an adversary to cause a client to create circuits is not a covert channel or arguably even an information leak. Circuit creation, even bursts of frequent circuit creation, is commonplace on the Tor network.

Accordingly, the accuracy values in the table are not properties of circuit creation alone. This vector supplies repeated path-selection trials; the paired covert channel, recognizable activity, or traffic manipulation supplies the classifier and its false-positive and false-negative rates.

When adversary induced circuit activity is combined with a covert channel from Section 1.1, with recognizable protocol activity from Section 1.2.3, or with active traffic manipulation (Section 1.3.4), then it leads to Guard Discovery, by allowing the adversary to recognize when they are chosen for the Middle position, and thus learn the Guard. Once Guard Discovery is achieved, netflow analysis of the Guard's connections can be used to perform intersection attacks and eventually determine the client IP address (see Section 1.3.1).

Large quantities of circuit creation can be induced by:

• Many connections to an Onion Service
• Causing a client to make connections to many onion service addresses
• Application connection to ports in rare exit policies, followed by circuit close at Exit
• Malicious javascript that abuses the circuit dirty timeout to continually build circuits, slowly, on browser tabs left open for long periods
• Repeated Conflux leg failures

This these cases also become more severe when the adversary can additionally control some aspect of the circuit construction that a client performs. The first case of this being problematic was so-called .exit notation, where Tor allowed an application to specify their desired exit by appending it to the domain name. Applications that handle untrusted data, such as the browser, could be induced to build circuits to malicious exits, for deanonymization attacks.

A similar problem still exists with exit policies: an exit can make an exit policy with a rare port, such as a single port in the bittorrent range, and a malicious website can perform redirects to such a port. Network-health scanners can identify some unusually restrictive exit policies that can be used to control exit choice in this way, but there is no comprehensive scanner for every possible exit-policy manipulation.

C-Tor has patched several cases of path restriction related control of circuit creation in the past. An illustrative example is Bug 14917, where Tor's single guard use allowed the adversary to either learn that guard, or collude with the local ISP to confirm client activity, through choice of the RP.

C-Tor no longer applies path restrictions to onion service circuits, but there is a minefield of problems that can still reappear in various circumstances with these restrictions. See Proposal 354 for those details, and for a proposed set of restrictions that do not expose circuit path selection to adversary control.

To protect onion service usage from excessive circuit creation attempts, C-Tor and arti use Vanguards for both onion service client-side and service-side circuit creation. The system comes in two flavors: Lite and Full. Vanguards-Lite adds one layer of vanguards to onion service circuits, with rotation times set such that it is sufficient to protect a user for use cases on the order of weeks, assuming the adversary does not get lucky and land in a set. Full Vanguards uses two layers of vanguards, for an expected use case on the order of several months.

These attack times are probabilistic expectations, and are rough estimates. See the statistical analysis in the spec for details. To derive these numbers, the spec assumes a 100% accurate covert channel for detecting that the middle is in the desired circuit. For covert channels that are not fully reliable, these expected lifetimes will be longer.

Non-Onion service activity is protected by feature-specific rate limits, rather than vanguards. For example, conflux limits the circuit creation attempts to build conflux sets, before abandoning set creation.

To address application-layer sources of circuit creation, Proposal 368 redesigns circuit dirty timeouts to minimize periodic application activity from causing additional circuit creation for each period request. The specification work is tracked in torspec#321, with implementation work remaining.

When examining a particular source of adversary-induced circuit creation or rate limiting mitigation, an analysis must define whether one attempt is an application request, a new circuit, or a distinct path. It must also consider the maximum retry rate before client, application, or relay limits intervene.

For example, if the adversary controls fraction m of the applicable Middle-selection weight and can cause k sufficiently independent circuits, the probability of appearing as a Middle at least once is approximately 1-(1-m)^k. Path restrictions, Vanguard persistence, rate limits, and reuse of existing circuits can make the trials dependent or prevent them entirely.

Mitigation Plan:

1.2.3. Recognizable Protocol Activity

At a glance:

The near-zero error estimate in this at-a-glance table applies to onion-service and Conflux handshake fingerprints, not automatically to every example in this section. Each new analysis must identify the exact sequence being classified, its base rate among unrelated circuits, and whether multiplexing obscures it when the adversary only observes TLS activity. It must also distinguish a reusable signal on a live circuit from a failure signal that destroys the circuit: the latter can assist Guard discovery over repeated attempts but cannot carry application traffic after recognition.

Certain aspects of Tor's handshakes are very unique and easy to fingerprint, based only on observed traffic timing and volume patterns. In particular, the onion client and onion service handshake activity is fingerprintable with near-zero false negatives and near-zero false positive rates, as per [ONIONPRINT]. The conflux link handshake is also unique (and thus accurately recognizable), because it is our only 3-way handshake.

This attack vector is very accurate. However, the impact is much lower than that of covert channels, because by itself, it can only tell if a particular Tor protocol, behavior, or feature is in use.

Published attacks have built upon this attack vector, though.

For example, onion client fingerprintability can be used to vastly reduce the set of website traffic traces that need to be considered for website traffic fingerprinting (see Section 1.3.5), making that attack realistic and practical. Effectively, it functions as a kind of oracle in this case (see Glossary, and [ORACLES]).

Additionally, certain error conditions, such as returning a single "404"-containing relay cell for an unknown onion service descriptor, are uniquely recognizable. This fingerprint was used in the [ONIONFOUND] guard discovery attack in combination with a circuit creation vector (Section 1.2.2). The authors provide a measurement of its uniqueness in that paper.

Ephemeral padding defenses offer a promising way to make these protocol patterns less stable. Instead of deploying one fixed padding machine that an adversary can train against, each circuit selects a newly generated Maybenot machine. The machines can use padding alone, or padding plus blocking, and their budgets can be tuned to trade bandwidth and delay for protection. Experiments in [EPHEMERAL] substantially reduce circuit-fingerprinting accuracy relative to Tor's deployed padding machines. However, the paper's production deployment is for WireGuard rather than Tor. See the circuit padding dev notes document for our design notes on deploying and testing this system in Arti.

Automatic Onion-Location redirection illustrated how several recognizable handshakes can compose into a stronger fingerprint that would require longer duration padding with considerably higher overhead costs to defend against. Tor Browser first loaded a site over a general circuit and then immediately performed the HSDir, introduction, and rendezvous activity needed to load the same page as an onion service. A guard adversary could classify each circuit type with at least 99.9% accuracy and recognize this deterministic transition. Because the set of stable Onion-Location sites was also enumerable and small, the transition reduced the set of possible destinations and provided an oracle for website fingerprinting (see [ONION_LOCATION]). Tor Browser removed its automatic "Prioritize .onion sites when known" option in tor-browser#42444. Manual Onion-Location navigation remains possible when the user clicks on the Onion Location button, because this user action is neither deterministic nor immediate with respect to page load.

Client or application retry behavior can also make even a one-bit timing signal more serious. If a Guard can recognize whether a BEGIN or RESOLVE response came from a colluding Exit, it can close every circuit without that signal and let transparent retries choose new paths. This restores end-to-end route capture without a dropped-cell channel. Optimistic data is particularly sensitive to this vector because it can add a large custom-size trailer behind this initial BEGIN cell, which will be unique if retried repeatedly.

Fragmented handshakes can create similar timing signals. For example, if post-quantum EXTEND messages normally send all fragments together, a colluding relay could encode a bit with an unusual delay between fragments. Implementations should flush such fragments together in both directions so that this timing choice cannot become a recognizable collusion signal.

Protocol failures themselves can also provide recognizable activity. If relays were to preserve a specific DESTROY reason when propagating a circuit failure toward the client, an adversarial endpoint such as an HSDir could close its circuits with a rare reason. Combined with adversary-induced circuit creation, a colluding middle could recognize that reason and record the preceding Guard. Repeating the process would enable Guard Discovery.

While such a DESTROY reason signal appears superficially similar to cell header manipulation, this signal is not a Reliable Internal Covert Channel, because every signaled circuit is destroyed and therefore unusable. It is nevertheless a recognizable protocol failure property that is useful to attackers. C-Tor relays prevent it by replacing specific DESTROY reasons with a common reason rather than propagating them across the circuit; arti-relay always sets the reason to NONE (even when originating the DESTROY).

Mitigation Plan:

1.2.4. Adversary-Induced Circuit Failure

At a glance:

In the absence of a reliable internal covert channel, adversary induced circuit failure is nowhere near as severe, because it requires a tremendous amount of circuit failure in order to achieve deanonymization.

When a circuit failure attack is mounted to close circuits during circuit handshake construction without a collusion signal to the Exit, it must proceed hop-by-hop. Guards must close circuits that do not extend to colluding middles, and those colluding middles must close circuits that don't extend to colluding exits. This means that the adversary must control some relays in each position, and has a substantially higher circuit failure rate while directing circuits to each of these relays in a path.

In such a case, Tor's distributed trust properties remain intact.

To understand how, consider that an adversary using a collusion signal that runs 10% of Exits expects to fail 9 circuits before detecting their signal at a colluding exit and allowing a circuit to succeed. In this case, the success probability per attempt is p_E = 0.1, so the expected number of failures before a success is (1 - p_E) / p_E = 0.9 / 0.1 = 9. However, an adversary without a collusion signal that controls 10% of Middles and 10% of Exits must obtain both positions in the same circuit build. Assuming independent position selection at these fractions, the conditional probability chain is P(M and E) = P(M) * P(E | M) = 0.1 * 0.1 = 0.01. Because a failed attempt causes the client to build an entirely new circuit, each new attempt must obtain both positions again. The expected number of failed circuit builds before a success is therefore (1 - 0.01) / 0.01 = 99: 90 are expected to fail by selecting a non-colluding Middle, since P(!M) / P(M && E) = 0.9 / 0.01 = 90, and 9 more are expected to reach a colluding Middle but select a non-colluding Exit, since P(M && !E) / P(M && E) = (0.1 * 0.9) / 0.01 = 9.

Every rejected path gives the adversary feedback but also raises the target client's circuit-failure rate, which is detectable by clients. C-Tor has a path bias detector that was tuned for the collusion signal case. This means that its alarm limits are lower than necessary for the multi-hop attack, and are prone to false positives as a result during DDoS and Guard overload.

To reduce false alarms that may be caused by DDoS and other load-inducing events, Arti implements Path bias lite. It classifies circuit-build outcomes per Guard and counts indeterminate failures on randomly selected paths. After enough observations, it warns about or permanently disables a Guard whose failure fraction crosses configured thresholds. Failures while connecting to the Guard do not count, reducing false alarms from a bad local network connection. This is simpler than C-Tor's full detector, and also less sensitive to false alarms.

If false alarms still persiat, this path bias detector could have a second layer in Arti, that checks to see if any specific Exits, IP, RP, or HSDirs are overused when the circuit failure rate is high. This would be more indicative of an attack, but could still go off if the user is actually trying to use rare exits (ie: country selection, bittorrent). IP, RP, and HSDir usage detection will not suffer from this source of false positives in such a detector.

Mitigation Plan:

1.2.5. DoS/OOM Attacks against Relays

At a glance:

An adversary that is able to crash or otherwise knock a relay offline is able to remove that relay's Guard and HSDir flags. This attack is explored in the [SNIPER_2014] and [HSDIR_SNIPER_2024] papers.

If the adversary is also running Guard or HSDir relays, they can selectively attack other relays, in an attempt to cause clients and services to migrate to their malicious ones, from which they can make use of additional attack vectors, or engage in censorship.

An adversary can confirm that a Guard is used by an onion service by maintaining a connection to it while taking it offline, to watch the connection close. Such an adversary may be more interested in the resulting Guard discovery surveillance opportunities, rather than removing the Guard flag itself.

When another vector reveals that a specific Guard is in use, the adversary can target that Guard directly and repeat the attack as clients select replacements. If the adversary can observe those migrations, it can continue until the targeted clients are known to have selected an adversarial Guard. This targeting and repeatability make relay DoS more severe than directory authority consensus manipulation, whose alternate consensus is difficult to deliver to a particular client and still requires probabilistic relay selection and follow-on observation.

In a simplified model where adversarial Guards have fraction a of the reachable replacement Guard-selection weight, k independent replacement selections would choose at least one adversarial Guard with probability 1-(1-a)^k. See the example security analysis for an example that does not allow repeated attempts, and requires a follow-on attack.

The adversary does not need to operate relays or have significant bandwidth capacity to perform these attacks. The Point Break attack uses modified clients and ordinary external servers to build many long circuits and amplify downloaded traffic across targeted relays. Its "stop reading" variant previously forged SENDME cells after the client stopped accepting data, consuming relay bandwidth at substantially lower attacker cost (see [POINTBREAK]). Requiring authenticated SENDMEs prevents that variant: an attacker must keep reading data to produce valid acknowledgments.

This same attack can be performed without SENDMEs at all if the attacker controls a single onion service: intermediate relays are not able to enforce internal SENDME usage on these circuits. For this scenario, we rely on closing circuits with excessive queue length at relays. This variant does require that the attacker have enough bandwidth on their onion service to send the traffic (unlike the Point Break attack, which requires almost no attacker bandwidth).

In general, authenticated SENDMEs remove the low-cost forged-acknowledgment variant, but not attacks in which the adversary pays to transmit the traffic. Queue limits can protect relay memory by closing circuits while still giving an adversary a circuit-failure mechanism. Defense comparisons must therefore report attacker bandwidth and connection cost, relay resource consumption, outage duration, and whether the residual effect is relay failure, congestion, or forced circuit migration.

Note: Congestion control, conflux, and stream-level flow control rely on the oomkiller and circuit queue limits to deal with protocol "cheaters" and related memory consumption vectors. When reviewing these components for DoS/OOM risk, the oomkiller behavior and circuit queue length limits must be taken into consideration. We have received numerous invalid bug reports against these components, because code review only considered the protocol behavior and not relay oomkiller interaction during cases of buffer bloat.

Mitigation Plan:

1.2.6. Directory Authority Vote and Consensus Manipulation

At a glance:

Tor clients rely on the directory consensus for the relay set, relay flags, bandwidth weights, protocol versions, and security-sensitive consensus parameters that determine client behavior. A compromised directory authority can attempt to manipulate this behavior by sending different votes to different authorities, selectively withholding votes or signatures, or exploiting voting thresholds that are lower than a full authority majority.

The historical directory protocol does not provide Byzantine agreement among the authorities. The equivocation attack in [DIRECTORY_CONSENSUS] demonstrates that malicious authorities can cause honest authorities to sign different consensus documents. Three malicious authorities can divide the honest authorities and collect a valid signature majority for each document. A single malicious authority can do so when the honest votes are divided at the relevant decision boundary. By releasing signatures for only one document publicly, the adversary can retain a second valid consensus for targeted delivery.

Equivocation can be combined with several forms of vote manipulation:

• A malicious authority can cause different authorities to compute different consensuses, preventing publication of a consensus.
• Adversarial Sybil relays can be included in an alternate consensus while being concealed from the public consensus and ordinary network-health review.
• Three malicious bandwidth-measuring authorities can assign an adversarial relay an inflated measured bandwidth before honest measurements are available.
• Marginal votes for relay flags or consensus parameters can be manipulated when only a subset of authorities participates in that decision.
• Carefully timed vote delivery, authority failure, or denial of service can leave honest authorities with different vote sets. This broader broadcast problem is tracked in torspec#143.

These attacks do not by themselves provide full route capture. The alternate consensus must first reach a targeted client, which is difficult due to the pinned fingerprints of consensus mirror relays during bootstrap, and the use of known Guards for consensus updates. The client must then select the adversary's relays for the positions required by a follow-on attack. Relay inclusion, flags, and path restrictions can each prevent the adversary from controlling every position, and bandwidth manipulation changes selection probability rather than forcing a particular route. Finally, the adversary still needs an observation mechanism, such as control of both ends of a circuit, recognizable protocol activity, or an application-layer confirmation signal, to associate the manipulated behavior with specific client activity.

For a privacy attack, the overall outcome is usefully decomposed as P(alternate consensus delivered) * P(required adversarial path positions | alternate consensus) * P(follow-on observation). These factors are not necessarily independent, but naming them prevents valid signatures or a zero-error relay signal from being mistaken for reliable targeting. Liveness attacks instead affect the clients that cannot obtain a fresh consensus; partitioning attacks affect only recipients of the alternate view; and bandwidth or flag manipulation can affect every client using the public consensus. Each case therefore needs a separate affected-population estimate.

An adversarial relay that appears only in the alternate consensus can recognize clients using that consensus with few false positives. False negatives remain high, however, because targeted delivery can fail and clients that receive the alternate consensus may never select that particular relay. Manipulations that only change the weight or flags of a relay present in both consensuses provide an even less distinctive signal.

The primary security report and its evaluation are tracked in tor#40790. The attack is difficult to target because clients ordinarily obtain consensuses through directory caches or guards rather than directly from the equivocating authority. Repeated attacks may also be noisy: missing authority signatures, different votes observed by different authorities, and incompatible consensus documents provide evidence that monitors can detect.

One attempt is one authority voting period. The adversary learns during that period which votes and signatures it received and whether an alternate quorum formed; targeted clients provide no guaranteed feedback unless they later use an observable adversarial relay. Repetition requires continued authority control and recreating a favorable vote boundary. Analyses should compare the alternate consensus lifetime and delivery time with a monitor's collection and alert delay.

The immediate defense is to make equivocation conspicuous. Authorities and monitors can archive the vote each authority presented to every other authority, compare those views, warn loudly about inconsistencies and missing signatures, monitor decisions close to voting thresholds, investigate any consensus missing signatures from running authorities, and alert network operators. This vote-view comparison was added to consensus-health monitoring using depictor, based on the TorEq monitor from the researchers. Clients could also compare multiple directory sources or consult an equivocation monitor before accepting a new consensus, though this adds availability and bootstrapping concerns.

Consensus hash chaining from Proposal 239 and consensus transparency from Proposal 267 can make targeted consensuses detectable after they are used. Walking Onions would bind relay information to a consensus view and further expose incompatible views. These mechanisms detect or constrain hidden consensus delivery, but do not prevent authorities from equivocating during voting.

Stronger preventive defenses include requiring broader participation for flags, bandwidths, and consensus parameters; explicitly voting default parameter values; and replacing the current broadcast process with a Byzantine broadcast or interactive-consistency protocol that guarantees agreement. DirCast is one such protocol proposed in [DIRECTORY_CONSENSUS]. The Arti directory-authority security work, including consensus hash chains, is tracked in arti#1544.

Mitigation Plan:

1.2.7. Relay Bandwidth Lying

At a glance:

Tor clients select relays for circuits in proportion to their fraction of consensus "bandwidth" weight. This consensus weight is calculated by multiplying the relay's self-reported "observed" descriptor bandwidth value by two ratios: one measured by the Tor load balancing system (formerly TorFlow; now sbws -- see [SBWS] for an overview), and another ratio that is calculated to take relay flag assignment (Guard, Exit, Middle, Guard+Middle) into account.

Note that three distinct tasks produce relay path selection weights: measurement estimates spare relay stream capacity, while load balancing turns these measurements into relay-selection weights adjusted in the direction of equalizing spare relay stream capacity. An additional load balancing step adjusts path selection weights to take flag assignment ratios into account during path selection itself.

Because these final path selection weights for relays all derive from relay-submitted descriptor bandwidth values via ratio multiplications, relays can still influence their weight by egregiously lying in their descriptor value, thus attracting more client usage. They can also attempt to fingerprint load balancer activity and selectively give it better service, though this is more complicated than simply patching Tor to lie.

This attack vector is especially useful when combined with a reliable internal covert channel attack from Section 1.1: if an adversary is using one of those covert channels to close a large portion of their circuits, they can make up for this loss of usage by inflating their corresponding bandwidth value by an equivalent amount, thus causing the load balancer to still measure a reasonable ratio for them, and thus still provide fast service for the fully deanonymized circuits that they do carry.

There are many research papers written on alternate approaches to the measurement problem. These have not been deployed for three reasons:

1. The unwieldy complexity and fragility of the C-Tor codebase
2. The historical coupling of measurement with load balancing, when we need a defined interface and implementations for both
3. Difficulty performing measurement of the fastest relays with non-detectable/distributed mechanisms

In the medium term, we will work on detecting bandwidth lying and manipulation via separate relay scanners. In the long term, Arti-relay will allow the implementation of distributed and/or dedicated measurement components, such as [FLASHFLOW]. FlashFlow only provides measurement, so it still needs a separate load-balancing mechanism. A stable capacity-measurement file could serve as the interface between the two, taking the place of the relay-submitted capacity values.

Mitigation Plan:

1.3. Augmented Observation

Augmented Observation provides a local adversary with additional ability to observe network traffic, in ways that improve their ability to carry out confirmation attacks with one-sided direct observation, and/or with observation in limited resolution.

In effect, these vectors all assist a local adversary in constructing an approximation of a global adversary, with varying degrees of accuracy. Vectors are included here because they are either foundational to this construction, or because they assist in improving the accuracy of this approximation.

Under these augmented observation vectors, confirmation accuracy varies greatly depending on traffic pattern uniqueness, traffic quantity, traffic duration, multiplexing properties, data retention resolution, and the number of similar traffic flows being compared.

With this in mind, while these observation vectors do not yield reliable, full scale deanonymization by themselves, they can still do so when they are part of a combined attack, such as with Guard Discovery from the previous section. Traffic modification and injection can also significantly enhance confirmation capabilities by creating unique, observable signals, for use in Netflow analysis, for example.

Confirmation is also generally easier than correlation: an adversary can test whether one suspected action occurred without having to identify it among all possible actions. The strongest confirmation signals therefore correspond to actions that are both rare and plausible.

Defenses should make more actions plausible or co-incident from the observer's perspective (which increases false positives), as well as eliminate sources of anonymity set reduction (which increases the base rate of events to compare). These defenses need not produce perfect indistinguishability to increase the adversary's false positive rate.

Some of these vectors may be more or less severe than currently suspected, especially relative to each other, under various defenses, and/or when combined with other sources of information. This entire category remains under active research, for both attacks and defenses.

1.3.1. Netflow Observation

At a glance:

Netflow is a feature of internet routers that records connection tuples, as well as time stamps and byte counts, for analysis.

ISPs, autonomous systems (ASes), and Internet exchange points (IXPs) are realistic sources of this kind of observation. Because these positions carry very large traffic volumes, connection metadata retention and analysis are typically more practical (and also less legally restricted) than full packet capture. Sampled IXP traffic has been shown to support flow correlation, subject to false positives and false negatives that depend on the sampling rate and number of candidate flows (see [SAMPLED_IXP]).

The traffic visible at any one of these positions is not necessarily stable. Asymmetric routing and ordinary Internet routing changes can move either direction of a Tor connection into or out of an AS's or IXP's view over time (see [RAPTOR]). As a result, a provider may retain or sell flow metadata for a changing cross-section of Internet traffic rather than a fixed, consistently observable population. Such churn can expand the set of connections available to an adversary over a long period, while also making individual observations less complete and harder to analyze.

This data is bought and sold, by both governments and threat intelligence companies, as documented in [NETFLOW_TICKET]. This Netflow data market effectively creates a low-resolution global passive adversary, for anyone who buys enough Netflow record datasets, or pays for access to analysis of these datasets.

Tor has a padding mechanism to reduce the resolution of this data (see Section 2 of [PADDING_SPEC]), but this hinges on clients' ability to keep connections open and padded for 45-60 minutes, even when idle. This padding reduces the resolution of intersection attacks, making them operate on 30 minute time windows, rather than 15 second time windows. This increases the false positive rate, and thus increases the duration of such intersection attacks.

Large scale Netflow data can also be used to track Tor users as they migrate from location to location, without necessarily deanonymizing them. Because Tor uses three directory guards, and has ~4000 Guard relays, the choice 4000 choose 3 of directory Guards is ~10 billion different combinations, though probability weighting of Guard selection does reduce this considerably in practice. Lowering the total number of Guard relays (via arti-relay and using only the fastest Guards), and using just two directory guards as opposed to three can reduce this such that false positives become more common. More thorough solutions are discussed in [GUARDSETS_2015] and [GUARDSETS_2018], as well as torspec#320.

Location tracking aside, by itself, this data (especially when padded) is not a threat to client anonymity. When Netflow data is used by itself in the wild, it tends to result in the hassling of multiple innocent Tor users rather than confirming a particular individual.

However, this data can also be used in combination with a number of oracles or confirmation vectors, such as:

• DNS Oracles
• Guard Discovery
• Flooding an onion service with huge amounts of traffic in a pattern
• Advertising analytics or account activity log purchase
• TCP RST injection
• TLS connection rotation

These oracles can be used to either confirm the connection of an onion service, or to deanonymize it after Guard Discovery. In the case of clients, the use of oracle data can enable intersection attacks to deanonymize them.

The oracle data necessary for client intersection attack is also being bought and sold, as documented in [NETFLOW_TICKET]. It is unknown how long such attacks take, but it is a function of the number of users under consideration, and their connection durations.

Indeed, it has been used successfully in the wild in combination with Guard Discovery, specifically in cases where the Guards in question were not heavily used.

Various Tor client behaviors can also leak information about usage to netflow adversaries that may not be deanonymizing by itself, but where the netflow connection creation signal can be combined with other data such as DNS Oracles, to confirm client activity in some circumstances.

For example, relay path restrictions create a passive netflow leak about Exit use in some Conflux usage scenarios. Suppose a dual-flagged Guard+Exit relay D is one of the client's primary Guards and is selected as the Exit. The first leg can use the other primary Guard, but the second leg excludes both D (because it is the Exit) and the first leg's Guard. Conflux must then connect to a third Guard to use D. Normal Conflux circuit construction creates this TLS connection. A passive netflow observer can use it to infer that D is being used as the Exit. Its lifetime brackets the period of Exit activity for correlation with server logs or other observations. Proposal 265 will remove dual Exit+Guard flag assignments from the consensus, making these relays only available for use as Exits. Proposal 354 further reduces the impact of path restrictions in terms of observable consequences.

The research interest here is in determining what can be done to increase the amount of time these attacks take, in terms of increasing connection duration, increasing the number of users, reducing the total number of Guard relays, using a UDP transport, further changes to flag assignment, or changing user behavior.

For comparison, one observation attempt should be defined as one retained flow record or one fixed correlation window. Analyses must state the number of candidate users or flows, vantage-point coverage, sampling rate, timestamp and byte-count resolution, retention period, and the fraction of the target's traffic visible in each direction. The number of independent windows and the target's activity frequency determine duration; routing churn can increase long-term coverage while increasing per-window false negatives. Results should separately report persistent user tracking, confirmation of a suspected onion service, and deanonymization after Guard discovery, since each has a different base rate and stopping condition.

Mitigation Plan:

1.3.2. Metrics Leakage

At a glance:

In the past, we have had issues with information leaks in our metrics reporting (see [METRICSLEAK]), where our own relay metrics effectively provided a global passive adversary with enough resolution to recognize certain kinds of traffic.

Under such conditions of improper operation, this vector is quite severe, and can be combined with even limited netflow data to construct a global adversary, and deanonymize onion services.

We addressed these issues by lowering the resolution of read/write history, and ensuring certain error conditions could not willfully introduce noticeable asymmetries. However, certain characteristics, like reporting local onion or SOCKS activity in relay bandwidth counts, still remain.

Additionally, during extremely large flooding or DDoS attempts, it may still be possible to see the corresponding increases in reported metrics for Guards in use by onion services, and thus discover its Guards.

A concrete analysis should follow the entire inference chain: inject a known traffic volume into the onion service, wait for the reporting interval, compare the aggregate change across candidate relays, identify candidate Guards, and use Netflow or another observation to confirm them. One attempt is therefore at least one metrics reporting period, currently 24 hours. Its success depends on injected volume relative to background traffic, aggregation and rounding, number of candidate relays, correlated network-wide load, and whether repeated reports can be linked. The adversary learns a candidate set rather than a Guard with certainty, so analyses should report the set size and both erroneous inclusions and missed Guards.

The affected population is limited to services that can be stimulated strongly enough to survive aggregation. Large injections and repeated day-scale changes are also visible to relay operators and network-health monitoring.

Mitigation Plan:

1.3.3. DNS Cache Oracles

At a glance:

The Tor Exit DNS cache can be probed to determine if a domain has been recently visited using that exit. This can increase the severity of Website Traffic Fingerprinting in Section 1.3.5, by reducing false positives, especially for unpopular websites. Effectively, this oracle provides a low resolution observation of the other end of a website traffic packet capture.

For DNS cache probing, Tor deployed a defense in the [DNSORACLE] ticket, to randomize expiry time. This helps reduce the precision of this oracle for popular and moderately popular domains/websites in the network, but does not fully eliminate it for unpopular domains/websites.

The paper also describes a "timeless" probe whose cache-state result is deterministic in C-Tor. The adversary sends a RESOLVE for the target followed by one for a known-cached control domain (or another request that receives an immediate internal response). If the target is cached, responses preserve their request order; if it is not cached, the control response arrives first. This ordering distinguishes a cache hit from a miss with certainty, independent of absolute DNS latency. Randomized cache expiry changes what a hit says about visit time, but does not remove this ordering signal.

The paper specifies a further defense, using a pre-load of popular names and circuit cache isolation defense in Section 6.2, with large-scale third party resolvers (Cloudflare, Google, Quad9, etc). The purpose of the pre-load list is to preserve the cache hits for shared domains across circuits (~11-17% of cache hits, according to the paper). The purpose of circuit isolation is to avoid Tor cache hits for unpopular domains across circuits. The purpose of third party resolvers is to ensure that the local resolver's cache does not become measurable, when isolating non-preloaded domains to be per-circuit.

Unfortunately, large-scale third party resolvers are unlikely to be recommended for use by Tor, since cache misses of unpopular domains would hit them, and be subject to sale in DNS analytics data (see [NETFLOW_TICKET]).

Also note that the cache probe attack can only be used by one adversary at a time (or they begin to generate false positives for each other by actually causing caching, or need to monitor for each other to avoid each other). This is in stark contrast to third party resolvers, where this information is sold and available to multiple adversaries concurrently, for all uncached domains, with high resolution timing, without the need for careful coordination by adversaries.

The arti dev notes directory contains an overview of several options for handling this vector in arti-relay.

There are additional forms of oracles that can reduce the set of sites that Website Traffic Fingerprinting and other attacks must consider, such as onion service handshake and Onion-Location fingerprinting described in Section 1.2.3. External oracles also exist that can be made use for this purpose, but these are not protocol oracles in Tor. See [ORACLES] for more details.

Mitigation Plan:

1.3.4. Active Traffic Manipulation Covert Channels

At a glance:

This category of covert channel occurs after a client has begun using a circuit, by manipulating application data traffic. This manipulation can occur either at the application layer, or at the Tor protocol layer.

Because it occurs after the circuit is in use, it does not permit the use of path bias or trust reduction properties by itself (unless combined with one of the above attack vectors -- most often Adversary-Induced Circuit Creation).

These covert channels also have a significantly higher false positive rate than those before circuit use, since application traffic is ad-hoc and arbitrary, and is also involved during the attempted manipulation of application traffic.

For clients, this covert channel typically is only effective after the adversary suspects an individual, for confirmation of their suspicion, or after Guard Discovery.

For onion services, this covert channel is much more severe: Onion services may be flooded with application data in large-volume patterns over long periods of time, which can be seen in netflow logs, to enable netflow deanonymization of a service. In the research literature, INFLOW and Duster both produce similar watermarks in onion-service traffic by controlling either client or ISP connectivity throughput.

Onion services can also be flooded with relay messages that are not currently covered by congestion control. INTRODUCE2, BEGIN, RESOLVE, and other uncontrolled relay messages can produce traffic spikes on an onion service's circuits, even when the service rejects or cannot act on them. Besides their Denial of Service impact, these spikes provide the same kind of observable traffic-volume signal for netflow-assisted deanonymization.

Proposal 367 addresses the general problem by making nearly all relay messages count against circuit SENDME windows. Introduction circuits also need an introduction failure acknowledgment (an "INTRO NACK"; see torspec#201) so that an introduction point can reject requests when the onion service's congestion window is full. Finally, the onion-service PoW protocol should allow introduction points to validate PoW and prioritize higher-effort requests when deciding which introductions to forward, rather than spending scarce circuit capacity on low-effort requests.

An adversary can also manipulate a circuit indirectly through resources shared with other circuits. Historical attacks have modulated a relay's load or available bandwidth, then used latency or throughput probes to determine whether that relay carried the target circuit (see [LOW_COST_TRAFFIC], [THROUGHPUT_FINGERPRINT], and [AVAILABLE_BANDWIDTH]). These attacks require enough flooding or probing capability to create and detect contention, but do not necessarily require direct observation of the target's client-to-Guard link. These attacks were published before Tor implemented true congestion control, deployed circuit length limits, deployed per-IP circuit creation limits, and lowered the acceptable circuit queue limits at relays before closing them. These attacks are unlikely to be effective against the modern Tor network in their published form, but the general attack vector likely remains viable to some degree.

Further examples of this class of covert channel include:

• Application-layer manipulation (AJAX)
• Traffic delays (rainbow, swirl - see [BACKLIT])
• Onion Service flooding via HTTP POST
• Flooding Tor relays to notice traffic changes in onion service throughput
• Shared-relay congestion and throughput probing
• Congestion-control and flow-control watermarks
• Conflux leg switching patterns
• Traffic inflation (1 byte data cells)

This vector's accuracy entry should not be applied uniformly to the different mechanisms described here. Comparative analyses should separate at least these cases:

For each case, state the pattern duration and bandwidth, candidate population, number of repetitions, feedback after a failed attempt, and whether the attack confirms a chosen target or searches for one among many. These values determine both detectability and whether the medium/low error estimate is justified.

Mitigation Plan:

1.3.5. Passive Application-Layer Traffic Patterns

At a glance:

This attack vector is only available after a client has begun using a circuit, by analyzing application data traffic.

Examples of this attack vector include:

• Website traffic fingerprinting
• End-to-end correlation

The canonical application of this vector is in end-to-end correlation, where application traffic entering the Tor network is correlated to traffic exiting the Tor network (see [DEEPCOFFEA]). This attack vector requires a global view of all Tor traffic, or false negatives skyrocket. However, this vector is also possible to exploit at a single observation point, using machine learning classifiers (see [ROBFINGERPRINT]), typically either the Guard or bridge relay, or the path between the Guard/bridge and the client.

In both cases, the majority of the information gained by classifiers is in the beginning of the trace (see [FRONT] and [DEEPCOFFEA]).

This attack vector has a significant false positive rate, because application traffic is ad-hoc, arbitrary, and self-similar. Additionally, because multiple circuits are multiplexed on one TLS connection, the false positive and false negative rates are higher still at this observation location, as opposed to observing a specific circuit (which is only possible by compromising a Guard or its TLS key).

The fraction of alerts that are correct (precision) depends on the "base rate" of target activity, even when the true-positive and false-positive rates stay the same. For example, suppose a single target website accounts for 100 out of one million analyzed page visits: a base rate of 0.01%. An attack with 90% recall detects 90 of those 100 target visits and misses 10. A false-positive rate of 0.1% means it also falsely flags approximately 1,000 of the 999,900 non-target visits. Its precision is therefore 90 / (90 + 1000) = 8.3%: only about 8% of its alerts are correct. The remaining roughly 92% of alerts are wrong; this is not the false-positive rate, which uses non-target visits, rather than alerts, as its denominator. Ignoring the base rate when interpreting a small false-positive rate as evidence that alerts are reliable is an instance of the base rate fallacy.

Because of the impact of the base rate, this attack vector gets more severe when it is combined with another oracle (as per [ORACLES]) that can confirm the statistically derived activity, or narrow the scope of material to analyze. Example external oracles include:

• Restricting targeting to either specific users, or specific websites
• DNS resolver query or flow records
• Destination server or CDN request logs
• Advertising, real-time bidding, or account activity logs (see [NETFLOW_TICKET])
• Directory information and other public activity metadata

These external metadata oracles are distinct from actively probing Tor's DNS cache in Section 1.3.3 or using handshake fingerprinting from Section 1.2.5 to recognize onion service usage (though these both are also useful oracles as well).

External metadata oracles are observed and retained by infrastructure outside the Tor protocol, and may be available to multiple buyers or observers concurrently. Their coverage and timing fidelity vary by provider. For example, DefecTor combines passively observed exit-side DNS requests with website fingerprinting; unpopular destinations can provide a particularly precise oracle (see [DEFECTOR]). The broader website-oracle model and other external sources are discussed in [ORACLES].

The nature of the protocol usage by the application (and how unique it is compared to other traffic) can also make this attack easier or harder. This has resulted in application layer defenses, such as [ALPACA]. Additionally, the original Google QUIC was easier to fingerprint than HTTP (See [QUICPRINT1]), but IETF HTTP3 reversed this (See [QUICPRINT2]). Javascript usage makes these attacks easier (see [INTERSPACE], Table 3), where as concurrent activity (in the case of TLS observation) makes them harder. Web3 protocols that exchange blocks of data instead of performing AJAX requests are likely to be much harder to fingerprint, so long as the web3 application is accessed via its native protocol, and not via a website front-end.

Website traffic fingerprinting literature is divided into two classes of attack study: Open World and Closed World. Closed World is when the adversary uses an oracle to restrict the set of possible websites to classify traffic against. Open World is when the adversary attempts to recognize a specific website or set of websites out of all possible other traffic.

Evaluation also has two distinct goals. Synthetic or small datasets are often used to attempt to measure the relative performance of attacks and defenses, though this is very likely to suffer from overfitting that artificially favors specific attacks or defenses. Estimating absolute performance requires testing against genuine Tor traces that reflect the variety and concurrent activity an adversary must classify. The GTT23 study in [GTT23] provides evidence that synthetic datasets differ materially from live Tor traffic.

The entire research literature for this vector is fraught with analysis problems, unfortunately. Because smaller web crawl sizes make the attacks more effective, and because attack papers are easier to produce than defenses generally, dismal results are commonplace. [WFNETSIM] and [WFLIVE] examine some of these effects. It is common for additional hidden gifts to adversaries to creep in, leading to contradictory results, even in otherwise comprehensive papers at top-tier venues. The entire vein of literature must be read with a skeptical eye, a fine-tooth comb, and a large dumpster nearby.

As one recent example, in an otherwise comprehensive evaluation of modern defenses, [DEFCRITIC] found a contrary result with respect to the Javascript finding in the [INTERSPACE] paper, by training and testing their classifiers with knowledge of the Javascript state of the browser (thus giving them a free oracle). In truth, neither [DEFCRITIC] nor [INTERSPACE] properly examined the effects of Javascript -- a rigorous test would train and test on a mix of Javascript and non-Javascript traffic, and then compare the classification accuracy of each set separately, after joint classification. Instead, [DEFCRITIC] just reported that disabling Javascript (via the security level of Tor Browser) has "no beneficial effect", which they showed by actually letting the adversary know which traces had Javascript disabled.

Another example appears in the ISP evaluation in [REALITYCHECK]. This paper makes useful contributions in terms of improving realism by combining genuine background traffic with monitored visites and differentiating between the impact of different vantage points. However, in Section 3.4.5, monitored traces use client-recorded page boundaries, while background segmentation uses circuit lifetimes. These are not ordinarily available to an ISP. Removing circuit identifiers from classifier inputs does not remove their contribution to preprocessing.

The [REALITYCHECK] evaluation also illustrates how attack rankings change with conditions: older Deep Fingerprinting outperforms Robust Fingerprinting ([ROBFINGERPRINT]) under its cross-network tests, while Robust Fingerprinting performs better under concept drift and some Conflux conditions. Robustness to network changes, content evolution, and defenses are distinct properties; superiority in one setting does not establish a universally superior attack.

Such hidden gifts to certain kinds of adversaries are commonplace, especially in attack papers. While it may be useful to do this while comparing defenses against each other, when these assumptions are hidden, and when defenses are not re-tunable for more realistic conditions, this leads to focus on burdensome defenses with large amounts of delay or huge amounts of overhead, at the expense of ignoring lighter approaches that actually improve the situation in practice.

Defenses should therefore be inherently tunable. Relative evaluation can give a rough "guestimate" comparison between designs in the research phase (if performed very carefully by a researcher with no horse in the race), but measurements aimed at absolute performance are necessary to inform the deployed bandwidth and delay budgets as our understanding of real traffic improves.

In terms of defense deployment, it makes the most sense to place padding machines at the Guards to start, for many reasons. This is in contrast to other lighter padding machines for earlier vectors, where it makes more sense to place them at the middle relay. In this case, the heavier padding machines necessary for this vector can take advantage of higher multiplexing, which means less overhead. They can also use the congestion signal at the TLS connection, to more easily avoid unnecessary padding when the TLS connection is blocked, thus only using "slack" Guard capacity.

Mitigation Plan:

1.3.6. Protocol or Application Linkability

At a glance:

Historically, due to Tor's slow upgrade cycles, we have had concerns about deploying new features that may fragment the anonymity set of early adopters.

Since we have moved to a more rapid release cycle for both clients and relays by abandoning the Tor LTS series, these concerns are much less severe. However, they can still present concerns during the upgrade cycle. For Conflux, for example, during the alpha series, the fact that few exits supported conflux caused us to limit the number of pre-built conflux sets to just one, to avoid concentrating alpha users at just a few exits. It is not clear that this was actually a serious anonymity concern, but it was certainly a concern with respect to concentrating the full activity of all these users at just a few locations, for load balancing reasons alone.

Similar concerns exist for users of alternate implementations, both of Tor, and of applications like the browser. We regard this as a potential research concern, but it is likely not a severe one. For example, assuming Tor Browser and Brave both address browser fingerprinting, how bad is it for anonymity that they address it differently? Even if they ensure that all their users have the same or similar browser fingerprints, it will still be possible for websites, analytics datasets, and possibly even Exit relays or Exit-side network observers, to differentiate the use of one browser versus the other. Does this actually harm their anonymity in a real way, or must other oracles be involved? Are these oracles easy to obtain?

Similarly, letting users choose their exit country is in this category. In some circumstances, this choice has serious anonymity implications: if the choice is a permanent, global one, and the user chooses an unpopular country with few exits, all of their activity will be much more linkable. However, if the country is popular, and/or if the choice is isolated per-tab or per-app, is this still significant such that it actually enables any real attacks?

When answering these questions, recognizing a deterministic protocol bit, version, country choice, or application identifier is only the first stage. If fraction p of the observable population shares the feature, recognition reduces the candidate population to roughly that fraction; it does not identify one member without an external identifier or oracle. Analyses must state the feature's prevalence, the population over which it is measured, and whether the feature persists across circuits, destinations, tabs, applications, or release upgrades. They must then describe the separate step that links the resulting group to identity or activity and give that step's error rate.

Application identifiers and shared circuits can also amplify an initial application-layer identity leak. The "Bad Apple" attack first obtained a BitTorrent user's IP address through behavior outside Tor, then used peer identifiers, tracker-returned address/port pairs, and circuit multiplexing to link other BitTorrent and HTTP streams to the same user (see [BAD_APPLE]). The initial direct-network leak is outside this threat model, but the subsequent linkage demonstrates why stream isolation must prevent identifiers or a compromised stream from associating otherwise independent activity.

Mitigation Plan:

1.3.7. Latency Measurement

At a glance:

Latency's effects on anonymity set has been studied in the [LATENCY_LEAK_2007] and [HOW_LOW_2013] papers.

It may be possible to get a rough idea of the geolocation of an onion service by measuring the latency over many different circuits. This seems more realistic if the Guard or Guards are known, so that their contribution to latency statistics can be factored in, over many many connections to an onion service. For normal client activity, route selection and the fact that the Exit does not know specific accounts or cookies in use likely provides enough protection.

One attempt is one request/response latency sample over a stated circuit and path. An analysis must give the number of circuits and samples, sampling interval, candidate regions, estimator and confidence threshold, and variance from relay processing, congestion, circuit construction, and Internet paths. It must also state whether the Guard is known and how that knowledge was obtained. The outcome should be reported as a region or candidate-set reduction with an error distribution, rather than as successful deanonymization. Repeated probing duration and target-visible request volume provide the main detection opportunity.

If this turns out to be severe, it seems the best option is to add a delay on the client side to attempt to mask the overall latency. This kind of approach is only likely to make sense for onion services. Other path selection alterations may help, though.

Defense comparisons should translate a client-side delay or alternative path-selection defense into remaining geographic precision and confidence, and compare that reduction with added latency and distinguishability. Without such measurements, the current mitigation suggestions cannot be prioritized against other vectors.

Mitigation Plan:

1.3.8. BGP Hijacking

At a glance:

BGP hijacking and interception can temporarily change Internet routes so that an adversary gains an observation point it would not normally possess. A hijack can disrupt a route, while an interception continues forwarding the traffic after attracting it. An interception of traffic to a Guard can help discover its users; observing both ends can enable traffic confirmation. The RAPTOR work demonstrated these attacks against Tor, and Counter-RAPTOR examined relay selection and monitoring defenses (see [RAPTOR] and [COUNTER_RAPTOR]).

The signal that a route was successfully diverted is distinct from the final security outcome. One attempt is one route announcement against a stated relay or destination prefix for a stated duration. The adversary receives routing-table and captured-traffic feedback while the announcement is active, but longer or repeated announcements increase the chance of route-monitor alarms, operator investigation, filtering, or de-peering. Comparative analysis should place expected propagation and useful observation time against those detection times, then recompute coverage after route filtering, RPKI-based rejection, or route-aware relay selection.

We consider this a low-severity Tor-specific vector because an active route attack against major Tor relays is liable to be noticed by their network operators. A detected source can be de-peered, and forged advertisements can be filtered. Persistent BGP attacks would also affect many services outside Tor, motivating better-resourced operators to deploy authenticated routing and filtering at the Internet layer.

Mitigation Plan:

2. Worked Security Analyses

The framework above can be used to analyze suspected anonymity risks before deciding how to respond to them. This section provides worked examples of that analysis.

2.1. Selective Guard Failure

Suppose a remotely triggered relay failure can affect a fraction f of Guard-selection weight belonging to honest vulnerable Guards (for example, only Guard+Exit relays), and an adversary already controls a disjoint, unaffected fraction a of Guard-selection weight. The adversary's intended outcome is to deanonymize a client. Its immediate capability is only Behavior Manipulation, specifically DoS/OOM Attacks against Relays: it tries to push clients off honest Guards and onto its Guards. It still needs a Reliable Internal Covert Channel or Augmented Observation as a follow-on attack.

The attack has the following conditional stages:

1. The adversary delivers an active trigger and keeps the vulnerable Guard set unavailable enough for it to lose the Guard flag.

2. A client is using a Guard in that set and replaces it. The fraction of the client population currently using such a guard is roughly f.

3. The client selects an adversarial replacement Guard. If all of the vulnerable weight f is unavailable and the remaining weights are otherwise unchanged, this position probability is a/(1-f).

4. The adversary then performs a follow-on attack on the users that choose their Guards. Let its conditional outcome probability be p. This value must account for any additional position probability, trigger or delivery probability, signal false-negative rate, and identity-linkage step. The signal's false-positive rate must also be reported, but is not itself a factor in the true target's success probability; it instead determines how often an observed match identifies an unrelated client.

The probability that one attack episode correctly deanonymizes a random client in the relevant population is f*a*p/(1-f), which is approximately f*a*p when f is small. If only part of the vulnerable set can reliably be induced to lose its Guard flag, or relay selection is correlated, the actual disabled and remaining selection weights must replace this simple formula.

For this example, a displaced client selects an unaffected honest Guard with probability (1-a-f)/(1-f). Because the stated flaw does not affect that Guard, the adversary cannot repeat this same selective failure against that client. Targeting the new Guard through some other DoS mechanism would be another stage with its own delivery probability, cost, feedback, and detection risk; it cannot be assumed as a free retry. The attack stops when the target reaches an adversarial Guard, chooses an unaffected Guard, the failed Guard recovers, or the attack is detected.

A related case to consider in this scenario is where the adversary wishes to determine if a particular onion service is using one of these vulnerable Guards. In this case, the adversary can hold open a few connections to the onion service, and bring down the Guards in the vulnerable set one at a time. This becomes a confirmation attack which succeeds with overall probability of f: the probability that the onion service had chosen the downed Guard as one of its Guards. However, this attack yields only Guard discovery. Deanonymization would require a follow-on attack that requires access to netflow data at all of the target Guards, and can make use of it with probability p to deanonymize the onion service (perhaps by flooding it). So for this case, the overall adversary success probability is f*p.

2.2. Alternate Consensus Delivery

The addition of Directory Authority Vote and Consensus Manipulation vector provides an example of how to place a new vector in the severity ordering. The analysis must begin with the capability demonstrated by the reported attack, rather than the maximum outcome possible after adding stronger compromises. It must then compare that capability with adjacent vectors using the same outcome, target, attempt, feedback, and mitigation assumptions.

For an attack using an alternate consensus as described by that vector, define the following events:

• C: the authority attack produces an alternate consensus that clients would accept.
• D: that consensus is delivered to the intended client.
• R: the client selects the adversarial relay positions required by the follow-on attack.
• O: the follow-on observation correctly links the client to the intended activity or identity.

The probability of the stated outcome for one targeted voting period is P(C) * P(D|C) * P(R|C,D) * P(O|C,D,R). Valid consensus signatures establish only C. They do not imply successful targeted delivery, selection of even one adversarial relay, control of a complete route, or observation of the client's activity. Each manipulation also has a different affected population: failure to produce a fresh consensus is a liveness attack, public weight or flag manipulation can affect all users of that consensus, and a hidden alternate consensus affects only the clients to which it is delivered.

The equivocation and vote-boundary attacks described in the cited research and tickets can cause authorities to sign different consensuses, sometimes with fewer compromised authorities than a simple majority model would suggest. They do not by themselves cause a targeted consensus to contain only adversarial relays or force a client to use an adversarial Guard, Middle, and Exit. A hypothetical adversary with full authority-key compromise could create such a consensus, but would still have to deliver it to the target and observe the resulting traffic. Such maximum-impact scenarios also must not be used as the outcome probability or severity of a weaker attack that is actually under review.

This conditional chain explains the vector's position below the other targeted Behavior Manipulation attacks. Guard Trapping Attacks can force selected clients onto an adversarial Guard and then combine with a reliable covert channel for complete route capture, even when the adversary operates only a small fraction of relays. Adversary-Induced Circuit Failure is extremely noisy, but each rejected path provides feedback and repeated construction attempts can eventually acquire the required positions. Targeted relay DoS can attack a known in-use Guard and, when migration is observable, repeat against replacement Guards until the client reaches an adversarial one. Alternate-consensus manipulation has no comparable guarantee of targeted delivery or client selection, and normally provides no feedback about a missed target.

It is also harder to associate alternate-consensus delivery with a particular content access than a combination of Adversary-Induced Circuit Creation and Recognizable Protocol Activity, which can provoke a chosen target and supply a recognizable event on the resulting circuits. Repeating an authority attack requires another voting period, continued authority control, and another favorable vote boundary. Divergent votes, missing signatures, and incompatible consensuses also create detection opportunities before or after the alternate consensus is used.

Mitigations affect different stages of this chain. Deployed vote-view comparison makes C more conspicuous and can shorten the period in which an alternate consensus remains useful, but does not necessarily prevent its creation. Client cross-checking or consultation with an equivocation monitor can reduce acceptance at D, at the cost of new availability and bootstrapping risks. Consensus transparency and hash chaining improve detection, potentially only after use, while Byzantine broadcast aims to prevent conflicting outcomes at C. Defense analysis must state which factor and time window a defense changes instead of treating detection and prevention as equivalent.

The vector nevertheless belongs above Relay Bandwidth Lying. Authority manipulation can change relay membership, flags, parameters, and the consensus view itself; it can partition clients or deny consensus availability in addition to biasing path selection. Bandwidth lying primarily changes selection probability within a shared public view. This is a comparative judgment about the capabilities and affected populations of the demonstrated attacks, not a claim that every authority manipulation is more successful than every bandwidth-manipulation attempt.

The same procedure should be used for future additions: state the specific capability established by the issue or research result, construct its conditional path to a concrete security outcome, and compare its targeting, repeatability, feedback, persistence, detection, and impact with the vectors immediately above and below it. Stronger hypothetical compromises may be documented as bounds, but should not determine placement unless they are requirements or consequences of the vector being analyzed.

3. Historical Attack Examples

The specific examples in this section were chosen to demonstrate how the attack vectors in this document combine. It focuses on historical cases known or suspected to involve direct Tor protocol or network weaknesses. We link public reporting where it exists and state when the available record does not establish enough detail to categorize an attack confidently.

A comprehensive empirical study of 136 court cases found that operational-security mistakes were the dominant real-world deanonymization angle, while attacks on the Tor protocol were exceptionally rare (see [ONION_WILD]).

We are interested in hearing from journalists, researchers, and legal organizations who learn about further court proceedings involving Tor.

3.1. CMU Tagging Attack

Perhaps the most famous historical attack was when a group at CMU assisted the FBI in performing dragnet deanonymization of Tor users, through their [RELAY_EARLY] attack on the live network. This attack could only work on users who happened to use their Guards, but those users could be fully deanonymized.

The attack itself operated on connections to monitored HSDIRs: it encoded the address of the onion service in the cell command header, via the RELAY_EARLY bitflipping technique from Section 1.1.2. Their Guards then recorded this address, along with the IP address of the user, providing a log of onion services that each IP address visited.

It is not clear if the CMU group even properly utilized the full path bias attack power here to deanonymize as many Tor users as possible, or if their logs were simply of interest to the FBI because of what they happened to capture. It seems like the latter is the case.

While this attack vector requires the Guard relay, it is of interest to any adversary that would like to perform dragnet deanonymization of a wide range of Tor users, or to compel a Guard to deanonymize certain Tor users. It is also of interest to adversaries with censorship capability, who would like to monitor all Tor usage of users, rather than block them. Such an adversary would use their censorship capability to direct Tor users to only their own malicious Guards or Bridges.

3.2. Guard Discovery Attacks with Netflow Deanonymization

Prior to the introduction of Vanguards-lite in Tor 0.4.7, it was possible to combine Adversary-Induced Circuit Creation with the attack vectors in Section 1.1.3, 1.2.3, or 1.3.4, to obtain a middle relay confirmed to be next to the user's Guard.

Once the Guard is obtained, netflow connection times can be used to find the user of interest.

There was at least one instance of this being used against a user of Ricochet, who was fully deanonymized. The user was using neither vanguards-lite, nor the vanguards addon, so this attack was trivial. It is unclear which covert channel type was used for Guard Discovery. The netflow attack proceeded quickly, because the attacker was able to determine when the user was on and offline via their onion service descriptor being available, and the number of users at the discovered Guard was relatively small.

3.3. Netflow Anonymity Set Reduction

Flow and connection records have been used, to varying degrees of success, to identify users who have posted violent threats in an area. In most cases, this has simply ended up hassling unrelated Tor users, without finding the posting user.

However, if the number of Tor users under consideration is small, due to either Guard discovery determining the exact Guard in use as above, or due to other external factors providing location information, then users can be deanonymized.

In a Harvard bomb threat case, for example, investigators used campus connection logs to reduce the set of suspects to a single Tor user; this was anonymity-set reduction, not evidence of end-to-end Tor traffic correlation.

Netflow records (or a similar measurement of aggregate Tor traffic volume) were also reportedly used to build suspicion of a datacenter in Germany which was emitting large amounts of Tor traffic, to eventually identify it as a Tor hosting service providing service to drug markets, after further investigation. It is not clear if a flooding attack was also used in this case.

3.4. Application Layer Confirmation

The first (and only) known case of fine-grained traffic analysis of Tor involved an application layer confirmation attack, using the vector from 1.3.4.

In this publicly documented case, a particular person was suspected as being involved in a group under investigation, due to the presence of an informant in that group. The FBI then monitored the suspect's WiFi, and sent a series of XMPP ping messages to the account in question. Despite the use of Tor, enough pings were sent such that the timings on the monitored WiFi showed overlap with the XMPP timings of sent pings and responses. This was prior to Tor's introduction of netflow padding (which generates similar back-and-forth traffic every 4-9 seconds between the client and the Guard).

It should be noted that such attacks are still prone to error, especially for heavy Tor users whose other traffic would always cause such overlap, as opposed to those who use Tor for only one purpose, and very lightly or infrequently.

4. Glossary

Base Rate (or Target Prevalence): The fraction of observed activity that actually belongs to the target class. For binary classification, this is the number of actual target instances divided by the total number of target and non-target instances. The precision metric depends on this fraction, even when true-positive and false-positive rates stay the same. Be wary of papers that report precision without explicitly stating their base rate.

Covert Channel: A kind of information leak that allows an adversary to send information to another point in the network.

Collusion Signal: A Covert Channel that only reliably conveys 1 bit: if an adversary is present. Such covert channels are weaker than those that enable full identifier transmission, and also typically require correlation.

Confirmation Signal: Similar to a collusion signal, a confirmation signal is sent over a weak or noisy channel, and can only confirm that an already suspected entity is the target of the signal.

False Negative: A false negative is when the adversary fails to spot the presence of an info leak vector, in instances where it is actually present. Specifically, the false-negative rate (FNR) is the fraction of actual target instances that the adversary misses: missed targets / all actual targets. In website fingerprinting evaluations that count wrong positives separately, FNR instead counts monitored visits rejected as unmonitored; incorrect destination assignments are recorded under WPR.

False Positive: A false positive is when the adversary attempts to use an info leak vector, but some similar unrelated traffic pattern or behavior matches, instead of their target. Specifically, the false-positive rate (FPR) is the fraction of non-target instances incorrectly flagged as targets: false positive alerts / all actual non-target instances. In open-world website fingerprinting, it counts unmonitored visits incorrectly identified as monitored. It is not the fraction of reported identifications that are wrong.

Global Adversary: An adversary that can observe all entrances and exits of the Tor network.

Guard Discovery: The ability of an adversary to determine the Guard in use by a service or client.

Identifier Transmission: The ability of a covert channel to reliably encode a unique identifier, such as an IP address, without error.

Local Adversary: An adversary that can observe only fractions of the Tor network entrance and exit capacity.

Oracle: An additional mechanism used to confirm an observed info leak vector that has a high rate of False Positives. Can take the form of DNS cache, server logs, analytics data, and other factors. (See [ORACLES]).

Path Bias (aka Route Manipulation, or Route Capture): The ability of an adversary to direct circuits towards their other compromised relays, by destroying circuits and/or TLS connections whose paths are not sufficiently compromised.

Precision: The fraction of reported positive identifications (alerts) that are correct. For binary classification, precision = TP / (TP + FP), where TP and FP are the counts of true and false positive alerts, respectively. Its denominator is all positive alerts, whereas the false-positive rate's denominator is all actual non-target instances. The fraction of alerts that are wrong is one minus precision, not the false-positive rate. For destination identification, naming the wrong monitored destination is an incorrect identification. Precision depends on target prevalence: a 0.1% false-positive rate does not imply 99.9% precision. See the example in Section 1.3.5, where 90% recall and a 0.1% false-positive rate yield only about 8.3% precision at a base rate of 0.01%.

ROC Curve (Receiver Operating Characteristic Curve): A plot of true-positive rate against false-positive rate as the classifier's decision threshold changes. The threshold determines how strong a match must be before the classifier reports a positive identification. A ROC curve shows the tradeoff between detections and false alarms, but does not directly show what fraction of alerts are wrong or account for target prevalence.

Traffic Analysis (Tor Threat Model Definition): Attacks where an adversary gains information or influences where they need to observe traffic, in order to maximize the utility of its c/n observation capability.

Traffic Confirmation (Tor Threat Model Definition): These are attacks where an adversary observes both ends of a communication and confirms that communication is taking place.

True Positive, True-Positive Rate (TPR), and Recall: A true positive is a correct detection of target activity. TPR, also called recall, is the fraction of actual target instances correctly detected: correct detections / all actual targets. For binary classification (target or non-target), recall equals one minus FNR. Under the convention used by [REALITYCHECK], monitored visits divide into correct identifications, wrong positives, and rejections as unmonitored, so TPR + WPR + FNR = 1. Here, one minus recall includes both wrong-destination predictions and rejected monitored visits.

Wrong Positive and Wrong-Positive Rate (WPR): In website fingerprinting, a monitored visit assigned to the wrong monitored destination. WPR is the fraction of all monitored visits assigned the wrong monitored destination, not the fraction of predictions that are wrong. Although recorded separately in some evaluations, such a prediction both misses the actual destination and incorrectly implicates another one.

Acknowledgments

This document has benefited from review and suggestions by David Goulet, Nick Hopper, Rob Jansen, Nick Mathewson, Tobias Pulls, and Florentin Rochet.

References

[ALPACA]

• https://petsymposium.org/2017/papers/issue2/paper54-2017-2-source.pdf

[AVAILABLE_BANDWIDTH]

• https://www.cs.columbia.edu/~sc2516/papers/chakravartyTA.pdf

[BAD_APPLE]

• https://www.usenix.org/legacy/events/leet11/tech/full_papers/LeBlond.pdf

[BACKLIT]

• https://www.freehaven.net/anonbib/cache/acsac11-backlit.pdf

[COUNTER_RAPTOR]

• https://arxiv.org/abs/1704.00843

[CARONTE]

• https://doi.org/10.1145/2810103.2813667

[CLOCK_SKEW]

• https://doi.org/10.1145/1180405.1180410

[DEEPCOFFEA]

• https://www-users.cse.umn.edu/~hoppernj/deepcoffea.pdf

[DEFCRITIC]

• https://www-users.cse.umn.edu/~hoppernj/sok_wf_def_sp23.pdf

[DEFECTOR]

• https://www.ndss-symposium.org/wp-content/uploads/2017/09/ndss2017_06B-2_Greschbach_paper.pdf

[DIRECTORY_CONSENSUS]

• https://www.freehaven.net/anonbib/cache/directory-oakland2024.pdf
• https://gitlab.torproject.org/tpo/core/tor/-/issues/40790

[DNSORACLE]

• https://www.usenix.org/system/files/usenixsecurity23-dahlberg.pdf
• https://gitlab.torproject.org/rgdd/ttapd/-/tree/main/artifact/safety-board
• https://gitlab.torproject.org/tpo/core/tor/-/issues/40674
• https://gitlab.torproject.org/tpo/core/tor/-/issues/40539
• https://gitlab.torproject.org/tpo/core/tor/-/issues/32678

[DUSTER]

• https://www.usenix.org/conference/raid2019/presentation/iacovazzi

[DOSSECURITY]

• https://www.princeton.edu/~pmittal/publications/dos-ccs07.pdf

[DROPMARK]

• https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf

[EPHEMERAL]

• https://www.ida.liu.se/~nikca89/papers/pets26a.pdf

[FLASHFLOW]

• https://gitweb.torproject.org/torspec.git/tree/proposals/316-flashflow.md
• https://www.robgjansen.com/publications/flashflow-icdcs2021.pdf

[FRONT]

• https://www.usenix.org/system/files/sec20summer_gong_prepub.pdf

[GUARDSETS_2015]

• https://www.freehaven.net/anonbib/cache/guardsets-pets2015.pdf

[GUARDSETS_2018]

• https://www.freehaven.net/anonbib/cache/guardsets-pets2018.pdf

[INTERSPACE]

• https://arxiv.org/pdf/2011.13471.pdf (Table 3)

[INFLOW]

• https://doi.org/10.1109/INFOCOM.2018.8486375

[LATENCY_LEAK_2007]

• https://www.freehaven.net/anonbib/cache/ccs07-latency-leak.pdf

[HOW_LOW_2013]

• https://www.robgjansen.com/publications/howlow-pets2013.pdf

[LOW_COST_TRAFFIC]

• https://doi.org/10.1109/SP.2005.12

[LYING_SCANNER]

• https://gitlab.torproject.org/tpo/network-health/team/-/issues/313

[METRICSLEAK]

• https://gitlab.torproject.org/tpo/core/tor/-/issues/23512

[NETFLOW_TICKET]

• https://gitlab.torproject.org/tpo/network-health/team/-/issues/42

[ONECELL]

• https://www.blackhat.com/presentations/bh-dc-09/Fu/BlackHat-DC-09-Fu-Break-Tors-Anonymity.pdf

[ONIONPRINT]

• https://www.freehaven.net/anonbib/cache/circuit-fingerprinting2015.pdf

[ONIONFOUND]

• https://www.researchgate.net/publication/356421302_From_Onion_Not_Found_to_Guard_Discovery/fulltext/619be24907be5f31b7ac194a/From-Onion-Not-Found-to-Guard-Discovery.pdf?origin=publication_detail

[ONION_LOCATION]

• https://petsymposium.org/popets/2025/popets-2025-0074.pdf

[ONION_WILD]

• https://petsymposium.org/popets/2024/popets-2024-0117.pdf

[ORACLES]

• https://petsymposium.org/popets/2020/popets-2020-0013.pdf

[PADDING_SPEC]

• https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/padding-spec.txt#L68

[PCP]

• https://arxiv.org/abs/2103.03831

[POINTBREAK]

• https://www.robgjansen.com/publications/pointbreak-sec2019.pdf

[QUICPRINT1]

• https://arxiv.org/abs/2101.11871
• https://news.ycombinator.com/item?id=25969886

[QUICPRINT2]

• https://netsec.ethz.ch/publications/papers/smith2021website.pdf

[RAPTOR]

• https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/sun

[RACCOON23]

• https://archives.seul.org/or/dev/Mar-2012/msg00019.html

[SAMPLED_IXP]

• https://doi.org/10.1007/978-3-540-75551-7_11

[RELAY_EARLY]

• https://blog.torproject.org/tor-security-advisory-relay-early-traffic-confirmation-attack/

[ROBFINGERPRINT]

• https://www.usenix.org/conference/usenixsecurity23/presentation/shen-meng

[REALITYCHECK]

• https://arxiv.org/html/2603.07412v1

[GTT23]

• https://arxiv.org/abs/2404.07892

[SBWS]

• https://tpo.pages.torproject.net/network-health/sbws/how_works.html

[SNIPER_2014]

• https://www.robgjansen.com/publications/sniper-ndss2014.pdf

[HSDIR_SNIPER_2024]

• https://dl.acm.org/doi/10.1145/3589334.3645591

[TOR_DESIGN]

• https://svn-archive.torproject.org/svn/projects/design-paper/tor-design.html

[TOR_DESIGN_UPDATES]

• https://blog.torproject.org/top-changes-tor-2004-design-paper-part-1/
• https://blog.torproject.org/top-changes-tor-2004-design-paper-part-2/
• https://blog.torproject.org/top-changes-tor-2004-design-paper-part-3/

[THROUGHPUT_FINGERPRINT]

• https://doi.org/10.1145/2046707.2046732

[TRAPPING_TOR]

• https://www.csit.carleton.ca/wshi/wp-content/uploads/2022/09/An_Anonymity_Vulnerability_in_Tor.pdf

[ULTRASOUND]

• https://doi.org/10.1515/popets-2017-0018

[USB_SIDE_CHANNEL]

• https://doi.org/10.1016/j.comnet.2018.05.018

[WFLIVE]

• https://www.usenix.org/system/files/sec22-cherubin.pdf

[WFNETSIM]

• https://petsymposium.org/2023/files/papers/issue4/popets-2023-0125.pdf