Who Knows What: Where Tor's Promise Ends
“No Tor node knows both the user and the destination.”
That is a good summary of the design. It is not yet a threat model.
The sentence describes what a single relay directly receives in the basic circuit. It does not say what happens when two relays cooperate, when an observer sees both ends, when the browser gives an identity to the site, or when the device is already compromised.
To understand where Tor’s promise ends, we must stop asking only “am I anonymous?” The useful question is more precise: which property do I want to hide, from which observer, and under what conditions?
First: Separate Five Properties
The client IP address indicates the network connection from which traffic originates. The destination is the server or service the client wants to reach.
The application identity is what the user or browser communicates within the application: an account, email address, web cookie, or another identifier.
Content includes exchanged requests, messages, and data. Traffic metadata instead includes timing, direction, and amounts observable even when content is encrypted.
Protecting one property does not automatically protect the others.
The Basic Circuit Distributes Direct Knowledge
Consider an Internet-bound circuit: client, guard, middle, exit, and site.
The guard, the first relay, directly receives the client’s connection. It therefore knows the client’s IP address and the next relay, but the protocol does not give it the final destination.
The middle knows the relays adjacent to its segment. It directly receives neither the client’s IP address nor the external destination.
The exit opens the connection to the site. It knows the destination and the data needed to reach it, but the circuit does not directly give it the client’s original IP address.
The site receives a connection from the exit. It can read application data addressed to it and any identity supplied by the user, but it does not directly receive the client’s IP address through the circuit.
This is direct knowledge: information delivered to that actor by the protocol or local connection. It does not yet include what can be inferred by combining observations.
One Point and Two Ends Are Not the Same Adversary
A local-network observer can see the client connect to a guard or bridge. It does not automatically see which site will emerge at the other end.
An exit can see the destination, timing, and volume of the external connection. It does not automatically receive the origin.
But if the same adversary controls or observes relevant points near both ends, it can compare patterns. A packet sequence entering at one time and a compatible sequence leaving shortly afterward can support a correlation.
Collusion occurs when distinct participants share their observations. Correlation is the inference that links flows using characteristics such as timing and volume.
Tor does not promise complete protection against a global observer capable of seeing and correlating both relevant ends with sufficient precision. “Global” does not mean magic or omniscience; it describes observational reach much broader than that of a single relay.
Correlation is not automatic identification. Resolution, position, traffic duration, noise, and adversary capability determine how linkable the two flows are.
Circuit Encryption Ends at the Exit
For Internet-bound traffic, Tor protects the path from client to exit. After the exit, the connection continues to the site.
If the application uses plaintext HTTP, a malicious exit can observe or modify content within the limits of the application protocol.
If the browser uses correctly authenticated HTTPS, Transport Layer Security (TLS) creates separate protection between browser and site. The exit still knows the destination needed for the connection and can observe local metadata, but cannot freely read or rewrite protected HTTP content.
Tor and TLS therefore solve different problems. Tor separates the client’s location from the destination through the path. TLS protects application content between browser and site.
An Account Can Reveal Identity Without Revealing Location
Suppose we open Tor Browser and sign in to a personal account.
The site receives the identity associated with the account because we provide it through the application. Tor can continue hiding the original IP address, but it cannot prevent the site from reading a username intentionally sent to it.
Saying “you are no longer anonymous” would be too vague. The site may know the declared identity while still not directly knowing the network location. The two properties can remain separate.
The same applies to cookies, forms, uploaded documents, and other application data. The path cannot erase information the endpoint receives as part of its function.
Two Different Kinds of Fingerprinting
Website fingerprinting tries to recognize activities or destinations from traffic patterns: observable sizes, timing, directions, and sequences.
Browser fingerprinting, by contrast, uses attributes exposed by the browser or device, such as combinations of capabilities, configurations, and behaviors observable by the site.
The two techniques can work together, but they are not synonyms. The first analyzes the network flow; the second distinguishes the client through the application interface.
In both cases, the outcome depends on the available signals, defenses, and points the adversary can observe.
A Compromised Endpoint Sees Before or After Tor
The Tor path begins when an application correctly hands traffic to the Tor client. It ends when the data reaches the intended application endpoint.
Malware, browser exploits, misconfiguration, or applications that bypass the proxy can observe or send data outside that path. A compromised program can read content before encryption or learn the user’s identity directly on the device.
This does not mean the circuit was decrypted. It means the adversary moved the observation point beyond the boundary the circuit protects.
At the Rendezvous, the Roles Change—not the Method
An onion connection does not use a public exit. Client and service build circuits to a shared rendezvous point.
The RP associates the two circuits and observes timing, volume, and the pair’s local relationship. But it does not directly receive the endpoints’ original addresses and does not terminate the cryptographic virtual hop between client and service.
Here too, we must specify capability. An isolated RP, a client-side guard, a service-side guard, and an external observer possess different information. Combining them without declaring collusion would create a new adversary, not a property of a single relay.
A More Serious Way to Say “Tor Protects”
Every claim about Tor’s security should complete five fields:
- property: IP address, destination, identity, content, or pattern;
- observer: relay, site, local network, multiple participants, or endpoint;
- observed points: entry, exit, application, or device;
- direct information: what arrives without inference;
- attack condition: collusion, correlation, absence of TLS, or compromise.
At that point, the phrase “no node knows everything” becomes useful again. It describes the initial distribution of knowledge. The threat model explains which capabilities must be added to reassemble it.
Tor’s security does not arise from a total absence of information. It arises from the cost and conditions required to connect information that the protocol delivers separately.
Technical Sources
Dingledine, Mathewson, and Syverson, Tor: The Second-Generation Onion Router (“Threat Model,” “Attacks and Defenses”); Tor Project Support, Attacks on onion routing (traffic confirmation), Tor Browser best practices (accounts and endpoints), Fingerprinting protections (browser), HTTPS encryption and Tor (boundaries); Wang and Goldberg, On Realistically Attacking Tor with Website Fingerprinting , PoPETs 2016(4); Tor Specifications, The rendezvous protocol (“Joining”). Consulted August 14, 2026.