This presentation provides a comprehensive overview of Tor's onion services, detailing their functionality, cryptographic underpinnings, and privacy benefits. The speaker, Clara, a Rust developer at the Tor Project, begins by distinguishing between "onion services" (the public term) and "hidden services" (the internal specification term), emphasizing their primary benefit of enabling location hiding and end-to-end encrypted communication between client and server, entirely within the Tor network, without involving exit relays.
The talk elaborates on the system's architecture, including "introduction points" for initial contact, "hidden service directories" (HSDs) for storing service descriptors, and "rendezvous points" for establishing direct, anonymous connections. Key cryptographic mitigations are highlighted, such as "key blinding" which generates daily ephemeral keys to prevent HSDs from linking descriptors to permanent onion addresses, and a "shared random value" in the hourly Tor consensus that makes HSD assignment unpredictable. The layered encryption of "hidden service descriptors" is explained, ensuring that HSDs cannot decrypt the sensitive introduction point information without the onion address's private key. The intricate introduction and rendezvous protocols, involving multiple Tor circuits and cryptographic handshakes, are then described, culminating in a 6-hop, zero-knowledge circuit between the client and the hidden service.
The presentation concludes by summarizing the high level of privacy achieved and outlining future developments like ACME for onions (for certificate issuance), improved encryption modes, and Rust reimplementation efforts. A lengthy Q&A session addresses various technical and operational aspects, including the role of directory authorities, post-quantum cryptography plans, and defenses against network surveillance.
Understanding Tor Onion Services: A Deep Dive into Anonymity and Cryptography
0:00 Introduction: The speaker, Clara, a Rust developer at the Tor Project, introduces the topic of Tor onion services, engaging the audience on their familiarity with Tor and onion services.
0:57 What are Onion Services?: Onion services are websites and applications exclusively accessible via the Tor network, ensuring traffic never leaves the Tor network (no exit relays involved). This provides location hiding and end-to-end encryption for both clients and servers.
2:08 Onion vs. Hidden Services: Originally called "hidden services," the term "onion services" is now used externally to de-emphasize the "hidden" aspect and highlight privacy features, while "hidden service" remains in internal specifications and code.
5:19 How Onion Services Work (High-Level Overview):
Onion addresses are cryptographically derived from an ED25519 public key.
Hidden services select "introduction points" (IPs) within the Tor network.
They create and sign a "hidden service descriptor" (listing IPs) and upload it to "hidden service directories" (HSDs).
Clients download this descriptor from HSDs, validate it, and connect to a chosen "rendezvous point" (RP).
The client then instructs the hidden service (via an IP) to connect to the RP.
The RP connects the client and hidden service, forming a 6-hop Tor circuit.
8:12 Directories and Consensuses: Tor clients rely on a "consensus" document, a signed list of all Tor relays with their properties (like 'HSDir' or 'Exit' flags), generated hourly by ~10 trusted "directory authorities" to maintain a consistent network view.
12:43 Hidden Service Directories (HSDs) & Privacy:
HSDs are ordinary Tor relays with a specific flag. Hidden services upload their descriptors to a subset of HSDs that changes daily.
Key Blinding (14:16): A cryptographic technique where a unique, ephemeral public key is derived daily for each onion address, preventing HSDs from linking the descriptor to the permanent onion address.
Shared Random Value (16:40): A random value, jointly generated by directory authorities and included in the consensus, makes the selection of responsible HSDs unpredictable in advance.
HSD Selection Algorithm (18:06): Uses consistent hashing (a "hash ring") to assign HSDs to services based on a combined hash of the blinded key, shared random value, and day, ensuring reproducible but randomized assignment. Each service is hosted on three HSDs ("replicas").
These documents, retrieved from HSDs, contain the necessary information for a client to connect.
They are layered: an unencrypted outer layer with meta-info, an optional encrypted middle layer for client authorization (which is always present to prevent side-channel attacks based on size), and an encrypted inner layer containing the crucial list of introduction points and ephemeral public keys for handshakes.
Encryption of inner layers using the onion address's secret ensures HSDs cannot decrypt or connect to the hidden service.
31:16 Inner Layer Contents: Contains supported handshakes, flags (e.g., for "single point hidden service" like Reddit's), and the actual list of introduction points, each with specific keys (onion, authentication, encryption) for the rendezvous protocol.
33:16 Introduction Protocol: The hidden service establishes circuits to its introduction points. Clients send encrypted introduction requests (containing rendezvous point details and handshake data) to an IP, which forwards it to the hidden service without knowing its content. No acknowledgment is sent to prevent probing service aliveness.
35:26 Rendezvous Protocol: The client connects to a chosen rendezvous point with a random "rendezvous cookie." The hidden service, having received the RP details from the IP, then connects to the same RP using the cookie. The RP then connects the two circuits, forming a 6-hop, end-to-end encrypted communication path where neither the client, server, nor intermediary relays know each other's direct identities.
37:31 Summary: Onion services offer significant privacy for both parties, with intermediate infrastructure having "zero knowledge" unless they know the onion address. This privacy is built upon core Tor primitives.
38:12 Future Plans: Upcoming features include "ACME for onions" (for TLS certificates), "Counter-Gallow mode" (general encryption improvements for Tor), and Rust reimplementation (RT) support for hidden services and relays.
40:20 Cryptography: Discussion on the use of ED25519 (adopted early, considered robust pre-quantum) and plans for Post-Quantum Cryptography (PQC) to be introduced layer by layer (starting with TLS).
41:57 Directory Authorities: Explained as ~10 trusted individuals, some affiliated with Tor, who collectively control the network through a 2/3 majority vote, responsible for signing the consensus. Efforts are made to ensure a diverse group to prevent malicious control.
43:04 Intermediary Knowledge: Confirmed that rendezvous and introduction points have zero knowledge of the hidden services, using ephemeral keys and relying on the multi-hop Tor circuits for anonymity.
44:32 DDoS Resilience of DAs: While DAs can be targeted, their consensuses are mirrored by thousands of other relays and are cryptographically signed, allowing clients to validate copies even if DAs are temporarily offline.
46:02 Government Control of Nodes: A "network health team" actively monitors relays for suspicious activity (e.g., large-scale, uncommunicative relay operators) and advises directory authorities to blacklist malicious relays from the consensus.
47:48 AES vs. ED25519: AES (symmetric) is used for bulk encryption after a shared secret is established using asymmetric cryptography like Curve25519, due to efficiency.
49:16 HS Directory Eligibility: Relays must meet certain criteria (online stability, bandwidth, known for some time) to be flagged as HSDirs; it's not random selection, but not prohibitively difficult.
50:09 Funding & Staffing: The Tor Project is a non-profit, relying on donations, and currently employs about 50 full-time staff, maintaining a "comfortable" but donation-dependent status.
51:52 Protocol Updates: New features are introduced gradually via "proposals," partially implemented, and adopted slowly. Minimum required versions for relays are enforced via the consensus to ensure network health and secure updates.
57:04 Traffic Analysis: Defenses against attacks based on packet sizes and timings include padding bytes and TLS primitives, an ongoing area of research.