Understanding Tor Hidden Services and Onion Routing

Created on March 29, 2024

2024   ·   tor   onion-services   network-architecture   privacy   ·   security

Tor hidden services, officially renamed “onion services” in 2015, represent a unique approach to anonymous communication on the internet. Unlike traditional Tor usage where clients browse the regular web anonymously, onion services allow servers themselves to operate anonymously without revealing their physical location or IP address. This bidirectional anonymity creates powerful privacy protections for both service operators and users.

The Architecture of Anonymity

Understanding how onion services work requires grasping several key concepts that differentiate them from both regular web services and standard Tor client usage.

Symmetric Anonymity: In a typical Tor connection to a regular website, only the client is anonymous—the website knows its own IP address and location. With onion services, neither party knows the other’s IP address or physical location. The service operator doesn’t know who’s connecting, and users don’t know where the service is hosted.

Onion Addresses: Instead of traditional domain names or IP addresses, onion services are accessed via cryptographic identifiers ending in .onion. Version 3 onion addresses (the current standard) are 56 characters long and look like thehiddenwiki3iw5nxcdmjcy7rgv4qu4mfrqgo3xuqrvlhh3byr3ad.onion. These addresses are derived from the service’s public key, making them self-authenticating—you know you’re connecting to the right service because the address itself proves cryptographic identity.

The Rendezvous Protocol: Onion services don’t listen for incoming connections in the traditional sense. Instead, they use a complex rendezvous protocol involving several types of specialized Tor relays.

How Connection Establishment Works

When an onion service starts up, it doesn’t simply announce itself to the world. The connection process involves multiple cryptographic steps designed to preserve anonymity for both parties.

Introduction Points: The onion service builds circuits to several randomly selected Tor relays, designating them as introduction points. These relays agree to relay introduction requests from clients to the service. The service publishes its introduction points to the distributed hash table (DHT) that Tor uses for onion service discovery, encrypting this information so only clients with the correct onion address can retrieve it.

Client Connection Process: When you want to connect to an onion service, your Tor client first retrieves the service’s descriptor from the DHT using the onion address. This descriptor contains the list of introduction points. Your client then builds a circuit to one of these introduction points and sends an introduction request.

Rendezvous Point Selection: Before sending the introduction request, your client selects a random Tor relay as a rendezvous point and establishes a circuit to it. The introduction request includes information about this rendezvous point.

Circuit Completion: The introduction point forwards your request to the onion service through its existing circuit. The service then builds a circuit to the rendezvous point. At this stage, both client and service have circuits to the rendezvous point, which connects them, allowing bidirectional communication without either party knowing the other’s location.

This multi-step process ensures that no single relay knows both the client and service identities. The introduction points know the service but not which clients are connecting. The rendezvous point sees two anonymous circuits connecting but doesn’t know which belongs to the client and which to the service.

Setting Up an Onion Service

Creating an onion service is technically straightforward, though operational security considerations add complexity.

Installation and Configuration: Setting up an onion service requires a Tor installation and appropriate configuration. On most Linux systems, this means installing the tor package and editing /etc/tor/torrc or creating a configuration file in /etc/tor/torrc.d/.

The basic configuration specifies which local service you want to expose and where Tor should store the service’s cryptographic keys:

HiddenServiceDir /var/lib/tor/my_service/
HiddenServicePort 80 127.0.0.1:8080

This configuration tells Tor to create an onion service that forwards connections on port 80 to a local web server running on port 8080. The service directory contains the private keys that establish the service’s identity and corresponding onion address.

Key Management: The service’s private key is stored in the HiddenServiceDir. This key is critical—anyone with access to it can impersonate your service or decrypt past traffic if they recorded it. The key should be backed up securely and protected with appropriate filesystem permissions. Losing the key means losing the onion address permanently, as these addresses cannot be regenerated or recovered.

Multiple Services and Ports: A single Tor instance can host multiple onion services, each with its own directory and address. Services can also expose multiple ports, mapping them to different local services:

HiddenServiceDir /var/lib/tor/service_one/
HiddenServicePort 80 127.0.0.1:8080

HiddenServiceDir /var/lib/tor/service_two/
HiddenServicePort 80 127.0.0.1:9000
HiddenServicePort 22 127.0.0.1:22

Vanity Addresses: While onion addresses are cryptographically derived and appear random, some operators generate “vanity” addresses with recognizable prefixes. This requires computational work—trying billions of key pairs until finding one whose derived address starts with the desired characters. Tools like Eschalot and mkp224o automate this process, though finding longer vanity prefixes requires exponentially more computation.

Legitimate Use Cases

Onion services serve important legitimate purposes beyond the negative associations often made with the “dark web.”

Whistleblowing Platforms: Organizations like The New York Times, The Guardian, and The Washington Post operate SecureDrop instances as onion services. SecureDrop is an open-source whistleblower submission system designed by the Freedom of the Press Foundation. By operating as an onion service, these systems allow sources to submit documents without revealing their identity or location, protecting whistleblowers from retaliation.

Secure Communication: ProtonMail and other privacy-focused email providers offer onion service access. This protects users in countries where these services might be blocked and provides additional privacy by keeping email access entirely within the Tor network.

Censorship Circumvention: In countries with aggressive internet censorship, onion services provide a way to publish and access information that would otherwise be blocked. The New York Times operates an onion service specifically to allow readers in censored regions to access journalism freely.

Privacy-Preserving Services: Facebook famously operates an onion service (facebookcorewwwi.onion, or its current v3 address). While this might seem contradictory given Facebook’s data collection practices, it serves several purposes: allowing access in censored regions, protecting user connections from surveillance, and providing end-to-end encryption for Facebook access.

Research and Development: Security researchers, cryptographers, and privacy advocates use onion services for experiments, demonstrations, and testing new privacy-preserving protocols.

Security and Operational Considerations

Operating an onion service securely requires careful attention to both technical configuration and operational security practices.

Application Security: The Tor network provides anonymity, not security. If the web application or service you’re hosting has vulnerabilities, those vulnerabilities still exist when accessed through Tor. In fact, many onion services have been compromised not through attacks on Tor itself, but through application-level vulnerabilities—SQL injection, cross-site scripting, authentication bypasses, or server misconfiguration.

Traffic Analysis Resistance: While onion services provide strong anonymity, they’re not immune to traffic analysis attacks. An adversary who can observe both a suspected server and onion service traffic might correlate patterns to identify the service location. This requires significant resources and is typically only a concern for services facing nation-state level adversaries. Mixing legitimate traffic, using decoy traffic, and careful operational security help mitigate these risks.

Timing Attacks: The rendezvous protocol involves multiple round trips, creating timing signatures. Researchers have demonstrated that sophisticated adversaries might be able to exploit these timing characteristics, though this remains primarily a theoretical concern for most operators.

Guard Discovery Attacks: Over time, an onion service tends to select a small set of guard nodes for its circuits. An adversary running many Tor relays might eventually become one of these guards, learning the service’s IP address. Tor has implemented various mitigations, including guard rotation policies and statistics obfuscation, but this remains an area of ongoing research.

Denial of Service: Onion services can be targeted with denial of service attacks. Because the introduction point mechanism limits how quickly services can handle new connections, attackers can flood introduction points with requests. Version 3 onion services include improved DoS protections, but this remains a challenge.

Physical Security: The server hosting an onion service must be physically secure. If an adversary can access the server, they can compromise it regardless of Tor’s anonymity protections. This includes considering cloud hosting risks—providers could be compelled to provide server access to law enforcement.

Metadata and Logging: Even with Tor, operational security mistakes can compromise anonymity. Servers should be configured to minimize logging, avoid leaking identifying information in error messages or HTTP headers, and generally treat all potential metadata as sensitive.

Operating an onion service comes with legal and ethical considerations that operators must understand.

Legal Compliance: Anonymity doesn’t mean legal immunity. Onion service operators are subject to the laws of the jurisdiction where they and their servers are located. Hosting illegal content or services remains illegal regardless of the anonymity Tor provides. Law enforcement agencies have successfully identified and prosecuted operators of illegal onion services through various means—application vulnerabilities, operational security mistakes, and traditional investigation.

Content Responsibility: Operators of platforms that host user-generated content must consider their responsibility for that content. While onion services can protect whistleblowers and free speech, they can also be misused. Responsible operators implement moderation policies, terms of service, and technical measures to prevent abuse while preserving legitimate privacy protections.

Ethical Operation: The decision to operate an onion service should be made thoughtfully, considering both the benefits it provides and potential harms. The privacy protections onion services offer enable important journalism, activism, and free expression, but also require careful stewardship.

The Evolution of Onion Services

Onion services continue to evolve with improvements to both security and usability. Version 3 onion services, introduced in 2017 and made mandatory in 2021, brought significant improvements over version 2: stronger cryptography (Ed25519 instead of RSA), better denial-of-service protections, improved distributed hash table design, and defense against guard discovery attacks.

Ongoing research and development focus on making onion services faster, more resistant to traffic analysis, easier to use, and more resilient to denial of service attacks. Features like OnionBalance allow load balancing across multiple backend servers while presenting a single onion address, enabling more scalable onion services.

The Tor Project continues to work on improving the onion service protocol, addressing both theoretical attacks identified by researchers and practical challenges identified by operators of production services.

Practical Recommendations

For those considering operating an onion service, several practical recommendations emerge from the experiences of the community.

Start with a clear understanding of your threat model. Who are you protecting against? What resources might they have? What would compromise look like? These answers guide technical and operational decisions.

Implement defense in depth. Rely on application security, operating system hardening, network isolation, and Tor’s anonymity protections together, not individually. Each layer compensates for potential weaknesses in others.

Stay informed about Tor developments, security advisories, and best practices. The Tor Project maintains documentation, mailing lists, and community resources specifically for onion service operators.

Test thoroughly before deploying services handling sensitive information. Security audits, penetration testing, and code review all contribute to identifying issues before they can be exploited.

Consider starting with a low-stakes service to gain experience with the technical and operational aspects before hosting anything critical.

The power of onion services lies in their ability to provide strong anonymity protections for both service operators and users. When implemented thoughtfully with appropriate security measures, they enable important communications and services that would otherwise be impossible or dangerous in many parts of the world.