Tor Network (Onion Routing)

What onion routing changes

A direct connection exposes a relationship between a source address and a destination address to observers along the path. Tor routes a connection through several relays so that one ordinary relay’s view does not include both ends. Layered encryption separates the information available at each hop. This improves privacy; it does not promise anonymity against every adversary. Tor Project introduction.

The useful system-design question is not “is this anonymous?” but “which observer can learn which relationship?” An ISP, an entry relay, an exit relay and a website have different views. An account login can identify a person to the website even when the source IP is hidden.

A circuit to an ordinary website

This table describes a simple circuit, not an assurance against colluding observers, compromised devices or traffic correlation. HTTPS still matters: Tor’s path protection does not substitute for the website’s authenticated encrypted connection.

Why layers alone are not an implementation

It is tempting to demonstrate Tor with nested calls to a generic encrypt() function. That picture omits authenticated circuit establishment, key derivation, cell framing, relay selection, flow control and many other protocol requirements. A few RSA/AES calls cannot produce a Tor-compatible client, and a home-built version should not be treated as a privacy tool.

For learning, use the diagram as a model of information separation and read the Tor protocol specifications. For actual browsing, use maintained Tor software and its supported configuration. No custom encryption code on this page is needed to illustrate the routing tradeoff.

Onion services use a different path

An onion service does not require an exit relay to connect to an ordinary public destination. The service establishes introduction points, and a client uses a rendezvous arrangement so both sides connect through Tor. The onion address is tied to service identity; it is not simply a normal hostname hidden behind an exit. Tor Project: onion service overview.

The diagram deliberately omits introduction and descriptor-discovery messages. Its purpose is to show that the service’s ordinary public address does not have to be disclosed to the client, and that “Tor always uses an exit” is incorrect.

Limits that affect a design

Timing and volume still exist. Encryption hides content but does not make packet timing disappear. An observer with sufficiently broad visibility may correlate traffic entering and leaving a system.

The endpoint can disclose identity. Logging in to a personal account, publishing identifying text or running a compromised browser changes the threat model. Network routing cannot undo an explicit disclosure to the application.

Availability and latency vary. Additional relays, congestion, route selection and blocking can affect throughput and responsiveness. A fixed “200–500 ms” number would not describe all circuits or workloads. Measure the actual operation and avoid assuming that a successful small request predicts large-transfer performance.

A VPN changes who must be trusted. A conventional single-provider VPN gives that provider a different view of the traffic than Tor’s distributed relay arrangement. Neither label alone proves safety; compare the observer, endpoint exposure and operational assumptions.

Worked review: a confidential document portal

Consider a fictional portal that accepts documents through an onion service. Hiding the server address solves only one part of the problem. The reviewer should separately inspect account recovery, uploaded-file metadata, application logs, outbound analytics requests and document-handling procedures. A third-party script that links a visitor to another account could defeat the intended separation without attacking Tor at all.

A useful review artifact is a table of data leaving each component: browser, service, log collector and document processor. For every field, state who can read it, why it is retained and when it is deleted. That exercise reveals application-level identity leaks that a relay diagram cannot show.

Worked comparison: privacy and response time

Suppose a read-only reference page is usable with a two-second response, while an interactive call requires continuous low latency. The same privacy goal does not imply the same transport design for both. Evaluate the page’s request count and payload size first; moving dozens of third-party resources onto an otherwise private page can add both observers and latency. Keep the protocol’s privacy properties separate from the application’s performance budget.

Related Concepts

• Proxies — which side an intermediary represents
• TCP Handshake — transport behavior beneath applications
• OAuth and OIDC — application identity and authorization