Onion service introduction points are the relays a Tor hidden service uses to announce that it can be reached without revealing where it runs. They act as meeting places between visitors and the hidden service. Understanding them clarifies how onion services stay private and reachable.
This article explains how introduction points fit into the onion service design, how they connect a visitor to a service, and what they reveal and conceal. It also covers practical points for operators and readers who want a clear mental model of the system.
Why a Hidden Service Needs a Meeting Point
Imagine a small publishing group that runs a website reachable only through Tor. The group wants readers to find the site without knowing the server’s physical location or public IP address. Tor solves this with onion services, which are addressed by long names ending in .onion rather than by ordinary internet addresses.
The difficulty is that a visitor still has to reach the server somehow. The onion service design avoids publishing the server’s address at all. Instead, the server picks a few relays that will act as intermediaries, and those relays become the first point of contact for anyone trying to connect.
These intermediaries are the introduction points. They let the service be found and contacted while keeping its own network location hidden from the wider public.
What Introduction Points Actually Do
An introduction point is a Tor relay that a hidden service has chosen to relay connection requests on its behalf. The service maintains a long-lived circuit to each introduction point, so the relay always knows how to reach the service when a request arrives. The service does not need to be reachable from the open internet directly.
When a visitor wants to connect, the visitor’s Tor client sends a request through one of these introduction points. The introduction point does not learn the content of the conversation, and it only passes along the information needed to start the meeting. The actual data exchange happens later over a separate path.
Because several introduction points are normally used, losing one does not make the service unreachable. The operator can publish a fresh set when needed, which helps the service remain available over time.
Key Components Involved in the Connection
Several parts work together when a visitor reaches an onion service. Each has a distinct role, and knowing them makes the overall flow easier to follow. The main components are listed below.
- The onion service itself, which holds the content and keeps long-lived circuits to its introduction points.
- The introduction points, which are ordinary Tor relays that forward connection requests to the service.
- The onion service descriptor, a signed document that lists the introduction points and how to contact them.
- The rendezvous point, a relay the visitor and the service both agree to meet at for the actual data exchange.
- The directory system, which stores and serves descriptors so visitors can look up where to start.
These components do not all operate at once in the same way. The descriptor is the bridge between the service and the visitor, since it tells the visitor which introduction points to use. The rendezvous point comes into play only after the introduction step succeeds. Keeping these roles separate is one reason the design resists simple tracing.
How a Connection Is Set Up Step by Step
The process begins when the onion service selects its introduction points and builds a circuit to each one. It then publishes a descriptor, signed with its key, listing those points so that visitors can find them. The descriptor is stored in a distributed directory, where a visitor’s client can retrieve it using the service’s onion address.
When a visitor’s client wants to connect, it first looks up the descriptor and chooses a rendezvous point. It then sends an introduction request through one of the listed introduction points, carrying enough information for the service to locate the rendezvous point. The introduction point forwards this request over its existing circuit to the service.
The service decides whether to accept the request and, if it does, connects to the rendezvous point. The visitor’s client is already waiting there, and the two sides join their circuits, creating an end-to-end path through Tor with no single direct link between the visitor and the server.
What Introduction Points Can and Cannot See
An introduction point sees that a request for a particular service exists, since the request must be routed through it. It also has the data needed to forward the request, but the request is encrypted for the service, so the introduction point cannot read the content of the eventual conversation. This limits what any one relay learns.
The design also keeps the service’s network location from the visitor. The visitor reaches the service through the rendezvous point, so the visitor does not learn the server’s IP address during the normal process. The introduction point and rendezvous point see only their own pieces of the connection, which is the core privacy property of the design.
These protections have limits. Anyone who controls a large share of relays or can observe traffic at several points may be able to correlate activity, and no network can promise perfect anonymity. Operators and readers should treat onion services as strong privacy tools rather than guarantees.
Versions, Descriptors and Design Changes
Onion services have changed over time, and the way introduction points are described has changed with them. Readers may encounter older documentation, so it helps to understand the main variations and why they exist. The Tor Project publishes the current specifications, which are the authoritative reference.
Earlier Onion Service Design
The original onion service design used shorter onion addresses and different descriptor formats. Introduction points existed in that design too, serving the same basic role of meeting visitors on behalf of the service. The older approach relied on weaker key lengths, which later made it less suitable for long-term use.
Because the earlier design is still referenced in many tutorials and older posts, readers should check the publication date of any guide they consult. Instructions for one version may not apply to another, and mixing them can cause confusing connection failures.
Current Design and Stronger Keys
Newer onion services use longer keys and a revised descriptor format, which improves resistance to attacks on the directory and makes addresses harder to forge. The introduction point concept remains central, but the signed descriptor and the encryption around introduction requests are more robust in the current version.
Operators should expect that the exact fields and formats in a descriptor may change as the specifications evolve. Relying on the official specification, rather than memory or third-party summaries, helps avoid errors when configuring or troubleshooting a service.
Why Descriptor Design Matters for Users
The descriptor is the document that visitors depend on to find a service, so its design directly affects reliability and privacy. A well-designed descriptor should be signed, verifiable and resistant to tampering, so that a visitor can trust the list of introduction points it contains.
For everyday readers, the practical lesson is simple: a correct onion address is what lets a client verify it has reached the right service. Typing an address carelessly or following an unofficial link can send a visitor to an impostor, which is why careful address checking matters.
Operating an Onion Service Safely
Running an onion service involves more than starting Tor and publishing an address. The operator should keep the service’s private key secure, because anyone who obtains it can impersonate the service. Backing up keys in an encrypted, offline location and limiting who can read them reduces this risk.
Operators also benefit from choosing introduction points carefully and keeping the number of them reasonable. The Tor Project’s documentation describes the configuration options and their defaults, and the defaults are usually a sensible starting point. Changing them without understanding the effects can reduce reliability or expose more information than intended.
Operators should watch for signs that their service is failing, such as unreachable introduction points or stale descriptors. Regular checks and a documented recovery procedure help keep the service available without weakening its privacy properties.
Common Misunderstandings to Avoid
One common misunderstanding is that an introduction point is a server that hosts the content. It is not. It is only a relay that passes along the first step of a connection. The content lives on the onion service, and the introduction point never stores it.
Another misunderstanding is that using an onion service makes a visitor completely anonymous. Onion services protect the location of the service and add a layer of privacy for the connection, but they do not hide everything about a visitor’s behavior. Logins, cookies and personal information can still reveal identity, so privacy depends on the whole setup.
A third mistake is assuming that all onion addresses are equally trustworthy. The address is cryptographically tied to the service’s key, which is a strength, but a user must still confirm they have the correct address from a reliable source before trusting the content.
Practical Checklist for Readers and Operators
The following checklist summarizes the most useful habits for anyone working with onion services. It is written for general readers and operators who want to apply the concepts in this article without technical depth.
- Confirm the full onion address from a source you trust before connecting, since one character changes the destination.
- Keep the service’s private key offline, encrypted and backed up, so that it cannot be copied or lost.
- Review the current Tor Project documentation before changing introduction point settings or key formats.
- Monitor the service for failures and document a recovery plan for when introduction points become unreachable.
- Remember that onion services add strong privacy protection but do not make any user or operator fully anonymous.
These steps do not replace expert advice for high-risk situations. Readers facing serious threats should consult qualified security professionals and consider their own legal and personal circumstances. Applying even a few of these habits consistently strengthens both the privacy and the reliability of an onion service.
Looking Ahead: Learning More About Onion Services
Onion services continue to evolve, and the specifications are updated as researchers and developers identify better designs. Staying informed means reading the official Tor Project documentation and paying attention to release notes, rather than depending on secondhand summaries that may be out of date.
For readers who want to go further, a good next step is to study the descriptor format, the rendezvous process and the directory system in the current specification. Building a clear picture of how these parts fit together makes it easier to evaluate claims about onion service privacy and performance.
As you apply these ideas, start small and verify each step. Confirm your addresses, protect your keys and test your service before relying on it, so that the benefits of introduction points and the rest of the design work as you expect.