Darknet Explained: How Tor Works — and Why I Rarely Use It Today

A documentary and a practical question

Katharina was watching a public-broadcasting documentary about the darknet. What stayed with me was a fairly ordinary question: Is there anything there that I actually need today?

I have tried Tor Browser, experimented with onion services and OnionShare, and looked into Tor routing. Cryptocurrency wallets, blockchains and local mining experiments were part of that period too. I know about Silk Road and the history of darknet marketplaces. None of this required a hood or a screen full of green letters. I already had a terminal.

I still find the architecture interesting. Its everyday usefulness for me has become more limited. That describes my own Linux workstation and home-server routine. It does not describe the requirements of a journalist, a confidential source or someone living under intrusive surveillance.

Surface web, deep web and darknet are different things

The surface web is the publicly accessible part of the web that search engines can discover and index. Public availability does not mean a page has actually been indexed. The deep web includes content outside ordinary search indexes: your private mailbox, an authenticated dashboard or an internal database. Most people use it regularly. Nothing about that definition means illegal.

A darknet is a network with special access conditions, such as dedicated software or intentionally restricted participation. Many focus on privacy or anonymity. Web content available through such networks is often called the dark web. Everyday language mixes these terms; a technical explanation benefits from keeping them separate.

Tor, originally “The Onion Router”, is one particular system. Its network consists of relays; Tor software constructs connections through them. Tor Browser combines access to this network with a browser adapted for privacy. Onion services expose services through .onion addresses. Tor is neither a synonym for every darknet nor solely a way to visit onion websites.

Tor Browser can also visit an ordinary HTTPS website. That connection leaves Tor through an exit relay. A connection to an onion service stays within the Tor routing system. Those are separate cases, and the illustration below treats them separately.

From ARPANET to overlays and Turtle F2F

ARPANET connected its first computers in 1969 and was an important early packet-switched network. The Internet Society’s history describes the development from these research networks towards interconnected independent networks using TCP/IP; ARPANET switched to TCP/IP in 1983. It was not an anonymity network. Connecting computers and sharing computing resources were central goals.

An overlay adds a logical network structure on top of existing connections. Participants still rely on the underlying infrastructure, but apply additional routing rules. Ordinary client-server traffic reaches a destination server. Tor interposes relays and distributes knowledge of the route. Friend-to-friend systems instead build immediate neighbourhoods around existing relationships.

Onion routing research began at the US Naval Research Laboratory in the mid-1990s. The Tor Project dates the initial public Tor deployment to 2002. The 2004 Tor design paper records its approach and limitations; the official project history explains its development.

Turtle F2F illustrates a different research direction. In “Turtle: Safe and Private Data Sharing” (USENIX, 2005), the authors describe a peer-to-peer architecture built on existing trust relationships. Communication travels through friends and their neighbours rather than direct connections to arbitrary participants. It is a historical research example, not a current substitute for Tor Browser. Tor did not evolve from Turtle.

How Tor reaches an ordinary website

The Tor client uses signed information about the network, selects suitable relays and constructs a circuit incrementally. The simplified model for ordinary browsing has three relays: guard, middle and exit. The client negotiates keys with individual relays. A circuit is a logical path, not a newly installed physical connection.

The client wraps outgoing data in layers of encryption. Each relay removes its layer and forwards the result. The guard sees the incoming IP address and the next hop. The middle sees its neighbours. The exit connects to the public website and knows the destination. The normal protocol does not give a single relay both the original client IP and the complete destination information.

Guards are intentionally used over longer periods. Repeatedly picking an entirely new entry would increase the chance of eventually encountering an attacker-controlled entry. The entry-guard explanation and path-selection specification give the details.

Tor does not replace HTTPS. The Tor encryption for ordinary web traffic ends at the exit. HTTPS additionally protects content between the browser and website. An exit can observe the connection destination and metadata; it cannot simply read properly protected HTTPS content. Unencrypted HTTP can be read or modified there. The website sees its own session contents and the exit IP. A login can still tell it your name. Tor and HTTPS protect different parts of the problem.

Onion services: introduction, rendezvous and no exit

An onion service publishes a signed descriptor containing information for contacting it through introduction points. The client retrieves it over Tor and checks it in the context of the onion address. That address is tied to the service’s cryptographic identity; it does not work like ordinary DNS resolving a public server IP.

The client establishes a circuit to a rendezvous relay it chooses. A separate circuit to an introduction point passes rendezvous information to the service. The service connects to the meeting point through Tor as well. A handshake establishes the protected end-to-end session.

The rendezvous relay joins the two circuits and forwards encrypted data. It is not an exit and does not open a direct public connection to the hidden webserver. The diagram shows the established data path. Descriptors and introduction points belong to the earlier contact process. The Tor Project’s overview and rendezvous specification describe that process.

For ordinary anonymised onion services, the project overview describes six relays in total: three selected by the client, including the rendezvous point, and three selected by the service. Special configurations exist; the illustration represents the usual learning model. A cryptographic address authenticates a service key, not an operator’s honesty. A phishing site can have a perfectly valid onion address of its own.

What Tor is useful for

A useful application is separating sensitive research from your connection’s IP address: health questions, political topics or information blocked on your local network. Other uses include source communication, independent access to information and keeping certain communication relationships away from local observers. The required protection depends on the adversary and their capabilities.

Sometimes the fact that two parties are communicating is itself sensitive. Content encryption alone does not hide that relationship. Tor distributes knowledge of the path and can therefore offer protection beyond an ordinary encrypted direct connection. It does not remove every opportunity for metadata analysis.

OnionShare uses onion services for tasks such as sharing files. Experimenting with it was a useful way for me to understand the architecture. It does not require a conventional upload to a public cloud service; recipients, files and endpoints still matter to the trust model. The Tor Project explains OnionShare as part of the ecosystem.

Learning is a legitimate use too. Understanding a circuit or making a local service reachable is interesting networking work. For me that usually means curiosity. For someone else, the same technology may have much more consequential uses.

Newsrooms and whistleblowers: a protected route for sources

A newsroom can provide a confidential entrance so that people can submit information without identifying themselves at first contact. SecureDrop is maintained by the Freedom of the Press Foundation and uses onion services for that purpose. The New York Times appears in the official SecureDrop directory, alongside other news organisations.

An onion website for reading and a confidential document submission system have different jobs. One publishes material. SecureDrop provides a source-contact system with a dedicated newsroom workflow. Using Tor does not make these services interchangeable.

The SecureDrop guidance before submission explains why routing alone is insufficient. Employer-controlled devices and monitored networks, identifying document metadata, a tip’s contents or knowledge of who could have supplied it may all matter. A newsroom can learn a source’s identity from the material itself. Tor does not guarantee safe whistleblowing in every circumstance.

Anonymity is not suspicious by default. It can be necessary for exposing wrongdoing. Anyone considering a submission should read the specific newsroom’s current instructions and SecureDrop’s official guidance. This article explains the technology; it does not replace that safety workflow.

An open, reliable internet connection is not universal

My own connection is a poor basis for assuming what everyone else can access. Government restrictions, DNS interference, surveillance, outages, infrastructure, cost and restrictions on international services can all limit access. A failed connection alone does not tell us which cause applies.

Historical OONI measurements in Iran and Cuban ParkNets document specific censorship observations with limited geographic and temporal coverage. For North Korea, a 2019 UN statement describes controlled information access and the distinction between an intranet and the global internet. These are different situations, not interchangeable country examples or a live diagnosis for October 2026.

My Iran DNS Behavior Observer concerns observed DNS behaviour. Incomplete interpretations and placeholders must be read as such. A DNS anomaly alone does not prove government interference. North Korea Connectivity has a limited measurement base: probe counts do not establish successful reachability or internet access for residents.

The Cuba Internet Weather Observer presents selected network indicators. Latency at available vantage points demonstrates neither nationwide connection quality nor government intervention. These pages are related technical observations. They do not directly measure Tor availability.

Tor can circumvent some blocks when a usable path to the network exists. Bridges and pluggable transports can help when direct connections are blocked. Tor cannot create missing mobile coverage or repair a failed submarine cable. An overlay still needs a working network path. A map or proximity to a national border cannot establish whether access is possible or safe for a particular person.

How anonymous is Tor really?

Privacy concerns limiting personal information. Anonymity concerns linking an action to a person. Pseudonymity means acting under a substitute name. Confidentiality protects content from unauthorised access; network encryption is one tool for achieving it. Operational security concerns practical choices that preserve these goals in a particular environment.

Used correctly, Tor hides the original connection IP from an ordinary destination website. That addresses a specific identification route. It does not establish whether the computer is clean, an account displays your real name or a message identifies you. A threat assessment therefore starts with a concrete question: Who can observe or control which information?

Endpoints and files: Malware can read information before encryption. Browser vulnerabilities can bypass protections. Documents opened externally may cause other applications to connect directly. Tor Browser does not automatically protect every application on the operating system. Added extensions, unsafe software and careless script permissions can change the risk; the official browser security guidance is a better starting point than an old configuration recipe.

Accounts and behaviour: Signing into a personally identifying account reveals identity to that service despite Tor. Reused names, writing style, activity times and volunteered personal details can connect pseudonyms. This does not require breaking encryption: the information has been supplied at another layer.

Observation and correlation: With a direct connection to a known Tor guard, an ISP can generally recognise Tor use. Bridges can change that visibility without guaranteeing universal invisibility. An adversary with suitable observation at both ends can correlate timing and traffic patterns. Tor’s documentation explicitly discusses these limitations. They imply neither perfect protection nor effortless identification of every user.

Tor reduces specific risks. It does not eliminate every way of identifying someone. A small operational mistake can defeat an otherwise carefully designed network setup. For my experiments, that is a useful technical lesson. For an endangered source, it belongs in a serious assessment of their circumstances.

Bitcoin: pseudonymous addresses, public traces

One observation stayed with me from experimenting with cryptocurrency: a substitute name on a payment does not erase its traces. Spending or exchanging the funds often introduces additional information.

Bitcoin transactions are publicly traceable. Addresses are pseudonymous identifiers, not identity documents. Reuse and transaction graphs can expose connections; external information may link addresses to people. An address still does not automatically establish a cryptographically verified civil identity. Bitcoin.org discusses these privacy limits.

Identity checks at regulated exchanges and information held by payment recipients can introduce further links; requirements depend on providers and jurisdictions. Not every graph-analysis inference has the same evidential strength. The central point remains: Bitcoin is not fully anonymous. Tor can protect the network route of a suitable application without deleting the blockchain’s public transaction history.

Reputation under a pseudonym: ask the healer

My longstanding healer in WoW Classic has a name other players recognise. Good groups invite that character because they associate the name with dependable healing. Reputation emerged through repeated behaviour. Nobody placed a passport next to the mana potion.

If the account were sold or compromised, the same name could still appear above the character while someone else controlled it. The tank might discover the change before the nameplate did.

Stable online pseudonyms work similarly: verifiable work and reliable behaviour can build reputation. They do not automatically prove present control. Signed messages and key continuity can help, but secure keys and judgement still matter. Marketplaces such as Silk Road also illustrate historical reputation and escrow models; scams, misrepresentation, exit scams and legal risks remain part of that history. A rating system does not make an offer lawful or trustworthy.

Wallets, a Raspberry Pi and an Antminer learning project

I built wallet software, created an experimental cryptocurrency of my own, mined it with an Antminer and ran local mining-related infrastructure with a website. The coin had no meaningful monetary value. Learning how the components worked together was the point. It was a fairly noisy learning environment.

A public record from that period is my tutorial “How to install any QT-Wallet on the Raspberry Pi / Pi3B+”, published on 13 July 2019. It covers installing and compiling a Qt wallet on a Raspberry Pi, using BankSocietyCoin as its example. That does not establish that BankSocietyCoin was my experimental coin.

The old commands, dependencies and package workarounds document historical hands-on work. They are not current recommendations for handling money securely. I would not reuse that old build uncritically today. Cryptocurrency and Tor are technically different systems; my interest in distributed processes, privacy and networking connects the experiments.

Why I rarely use the darknet now

Most of my present-day questions are easier to answer on the ordinary web. The Internet Archive is useful for historical documents and web archives. WinWorld offers a route into retro software research. GitHub provides source code, unusual projects and inspectable development. Public security research, documentation and networking or reverse-engineering communities cover much of the rest.

Availability does not establish a licence. An old program being downloadable does not mean it is freely licensed or may be redistributed without restriction. Ordinary websites need source criticism too.

My Linux infrastructure, conventional encrypted connections and deliberate privacy settings cover most routine tasks. These days I open Tor more often for a specific technical question than to search for a hidden collection of treasures. Someone trying to reach blocked reporting or protect a source can reasonably make a very different choice.

An interesting architecture with a specific purpose

The darknet contains criminal offerings and very real risks. It also supports research, confidential source contact and independent access to information. Tor is an impressive technical response to particular network-observation problems, with clear limitations.

For me, the architecture remains the interesting part: how can knowledge of a connection be distributed so that one intermediary does not see everything? I rarely need to browse onion sites to appreciate that. Understanding the system, taking its limits seriously and choosing a tool for a concrete task is usually enough. Katharina’s documentary ended up becoming a networking discussion after all. The surprising part was probably only how quickly that happened.

Sources, historical context and image rights

Research date: 11 October 2026. Country reports are explicitly historical findings. Personal experiences come from my technical retrospective; the illustration and prose were created for this article. No Wikimedia images or third-party diagrams are reproduced. Linked sources remain the work of their respective authors.

• Tor: network overview
• Tor: entry guards
• Tor and HTTPS
• Tor: correlation and remaining attacks
• Tor: onion-service protocol overview
• Tor: rendezvous protocol specification
• Tor: path-selection constraints
• Tor: project history
• Internet Society: A Brief History of the Internet
• USENIX 2005: Turtle: Safe and Private Data Sharing
• USENIX 2004: Tor: The Second-Generation Onion Router (PDF)
• Tor: bridges and pluggable transports
• Bitcoin.org: Protect your privacy
• SecureDrop: New York Times directory entry
• SecureDrop: Before you submit
• Tor: OnionShare
• Dennis Hilk: Qt wallet on Raspberry Pi (13 July 2019)
• OONI: Iran, measurement findings 2014–2017
• OONI: Cuban ParkNets (2017)
• OHCHR: DPRK end-of-mission statement (2019)
• Tor Browser: security guidance