Onion services can publish a public onion address without revealing the server’s location. The older term hidden services still appears in some guides, but modern Tor documentation generally uses onion services.
With introduction points, a Tor Browser request doesn’t knock directly on a server’s network door. The tor network relays it through staged circuits, allowing the client and service to communicate without learning each other’s IP address.
Once you see how these parts fit together, the design becomes easier to understand. It supports anonymous communication and location hiding, but it doesn’t guarantee that every onion site is safe.
Key Takeaways
- Introduction points accept a client’s initial request but do not carry the final website traffic or reveal the onion service’s IP address.
- A rendezvous point joins separate client and service circuits after matching a temporary cookie, keeping both endpoints inside the Tor network.
- A v3
.onionaddress is derived from a public key and identifies the service cryptographically rather than pointing to a public server location. - Location hiding does not guarantee complete privacy or safety; insecure applications, operational mistakes, traffic analysis, and denial of service attacks remain possible.
- Secure hosting, protected private keys, client authentication, careful address verification, and appropriate rate limits are still necessary.
Why v3 Onion Addresses Aren’t Domain Names
A normal website name points users toward a server location through DNS. Modern v3 onion services use 56-character addresses ending in .onion. Unlike a DNS name, an onion address identifies a cryptographic service identity, not a public IP address or certificate authority.
The address starts with a public key
The 56-character format is derived from the service’s 32-byte ed25519 public key, plus a checksum and version information. This structure gives the address a stable identity without revealing the service’s network location.
The result is a self-authenticating destination. The onion address identifies the intended service through its public key, while the corresponding private key remains protected by the service and isn’t published in the address or descriptor.
This identity doesn’t prove that the operator is safe or honest or provide access control. A restricted onion service can require client authentication separately, even when its public address is self-authenticating.
Older v2 addresses are no longer supported. The term hidden services is legacy terminology, and current documentation favors the v3 design for modern onion services. The Tor Project’s onion service overview explains why modern onion services use the v3 design and why older hidden services are no longer supported.
Signed descriptors tell clients where to begin
The address doesn’t contain the service’s real location. Instead, the service creates a signed service descriptor and publishes it through selected hidden service directory relays, often called HSDirs. A configuration file points Tor to the service directory or local service mapping.
The service descriptor contains the information a client needs to start an anonymous connection, including current introduction-point information and the cryptographic material required by the protocol. HSDirs are part of the Tor network and act like a distributed hash table, storing signed records so clients can find the descriptor without a conventional DNS lookup. The descriptor changes over time, but the public onion address stays tied to the service identity.
What Onion Service Introduction Points Actually Do
Introduction points are often misunderstood. They aren’t the onion server, and they aren’t the final relay where private traffic meets.
They are contact relays used by onion services. Older documentation may call these systems hidden services. Their job is to pass an introduction request from a client to a service that has already prepared a connection to them.
They accept introductions, not website traffic
Before any visitor arrives, an onion service chooses several relays on the Tor network as introduction points. It builds a Tor circuit to each relay, then lists them in its signed descriptor.
Its configuration file maps the local web port into Tor, while the signed descriptor lists the relays available for introductions.
A client downloads the descriptor and chooses one available introduction point. It builds its own anonymous circuit to that relay and sends a request intended for the service.
Readers comparing older directory descriptions may also see the term hidden services.
The introduction point can see that it has circuits associated with both sides of the request. It doesn’t learn the host’s public IP address, and it doesn’t become the path for the final website session. This separation keeps one relay from holding the whole picture.
The client uses the introduction point only once
The client delivers a message through the introduction point, then moves on to a different relay for the actual meeting. That relay is called a rendezvous point.
This is the main reason an introduction point isn’t the final meeting point. It passes along a private invitation. It doesn’t carry normal page requests after the connection is established.
If one introduction relay goes offline, a client may select another listed in the descriptor. The service stays reachable without exposing its network location.
How Rendezvous Circuits Create a Private Meeting
The rendezvous point is the relay connecting the client and service sides. This design supports anonymous communication within the tor network. The current term, “onion services,” is preferred over “hidden services.” Neither endpoint directly connects to the other over the public internet.
This part of the protocol is sometimes called the rendezvous dance. It has several steps, but the purpose is direct: both sides join the same temporary connection.
A rendezvous cookie matches both circuits
The client first selects a relay to become the rendezvous point. It builds a path through Tor to that relay and creates a random cookie for the connection.
The basic process works like this:
- The client asks the relay to wait for a service circuit that presents the same cookie.
- The client sends the relay details and cookie through one of the service’s introduction points.
- The relay forwards the request through its existing circuit to the service.
- The service decrypts the request, builds its own separate tor circuit to the chosen relay, and presents the matching cookie.
- The rendezvous point connects the two circuits after the cookie matches.
The cookie is a random, temporary one-time secret, not an identity document. It matches the client and service circuits, but doesn’t prove a user’s identity. It isn’t client authentication, which is a separate access-control feature. The relay uses it to join the right client circuit with the right service circuit without exposing either IP address. Tor’s rendezvous connection explanation shows the final cookie check in this process.
Six hops are a useful mental model
After the connection reaches the rendezvous point, traffic commonly crosses three Tor relays on the client side and three on the service side. The meeting relay links those paths, creating the familiar six-hop model.
There is no exit node involved. The browser isn’t leaving Tor to reach a public web server. Both ends remain inside Tor circuits, with end-to-end encryption protecting traffic across the connection.
That doesn’t mean every path is identical or permanent. Circuits can rotate, fail, or be rebuilt. The important point is that the service’s public IP address is never handed directly to the client.
What Onion Services Hide, and What They Don’t
Location hiding is one of the main security benefits of this design (formerly called hidden services). It keeps the physical host location out of the descriptor, the address, and the client’s view.
Still, privacy isn’t automatic. A badly managed server can expose itself through its own software, logs, or administrator behavior.
The service’s guard still sees part of the picture
The service creates outbound paths to its introduction relays and a rendezvous point, the final meeting relay.
The service’s guard relay can see the server connecting to the tor network. It doesn’t see the final client or the full destination path.
That limited view is useful protection, but it isn’t perfect anonymity against a powerful observer. Traffic analysis could still correlate timing or volume across both sides over time.
An address ending in .onion hides a network location. It doesn’t erase unsafe logs, browser fingerprints, exposed admin panels, or a vulnerable web application.
These are application and operational leaks, not failures of the relay protocol. Avoid third-party analytics, remote fonts, external images, and scripts that call public services. Each one can share visitor data or create a link between the service and a public infrastructure account.
Denial of service attacks still need attention
A hidden IP address doesn’t stop application-layer abuse or denial of service attacks. Attackers can still flood forms, make expensive search requests, or open too many connections.
Tor’s current onion-service DoS guidance covers controls such as rate limiting at introduction points, proof-of-work defenses, and limits for established rendezvous circuits. These controls can reduce denial of service pressure, but they don’t replace secure application code. Administrators should audit rate limits and related settings in the relevant configuration file, then plan capacity for further denial of service attempts.
Hosting and Finding Onion Sites Without Taking Shortcuts
A privacy-focused setup keeps the application and Tor process separated where possible. This reduces the damage if one component is compromised.
Keep the web service off the public network
Whonix users often place the application on Whonix Workstation while Tor-facing duties remain on Whonix Gateway. The same separation works with carefully isolated Linux virtual machines or containers.
Run small, maintained server software such as Nginx. Bind the application to a local interface, and keep the public-facing firewall port for its normal service closed when the site is onion-only. Define the minimal Tor service mapping in the Tor configuration file, then review local bindings and permissions in that configuration file during hardening.
Keep the onion service private key protected in encrypted backups. Maintain a separate encrypted, tested backup and confirm that it restores correctly. Never place the private key in a public repository, share it with link directories, or expose it through the web application.
For restricted access, review client-side or service-side settings in the relevant configuration file. Use client authentication to limit access to authorized users, rather than relying only on the published address.
For organizations with written authorization and a defined scope, Pro Ethical Hackers For Hire can test a service for configuration mistakes before launch. Testing can also examine application abuse that could cause a denial of service.
High-traffic services can also use OnionBalance. This onion balance setup distributes requests across backend onion services without changing the public onion address. It can improve availability during a denial of service, but it doesn’t eliminate the attack.
Directories are hints, not proof
People using Tor Browser often search for verified Tor websites, deep web sites, or directories promoted as Verified onion links. Some directories use the older term hidden services, but a listing isn’t proof of legitimacy on the Tor network.
Names such as Tor Taxi and Tor Watch may appear in search results, while phrases like “deep web market places” are often used to attract risky traffic. Fake clones, phishing pages, and copied addresses are common. Check an onion address against a project’s official public channel, signed announcement, or trusted research source.
For research and education, Verified Tor Onion Links can help readers locate published onion resources. Compare the full 56-character v3 address carefully before entering credentials or sharing sensitive information.
Frequently Asked Questions
What is an onion service introduction point?
An introduction point is a Tor relay that accepts an initial request from a client on behalf of an onion service. It is not the onion server and does not carry the normal website session after the connection is established.
Does an introduction point know the onion service’s IP address?
No. The introduction point can see circuits associated with the request, but it does not learn the service host’s public IP address. The service connects to the Tor network through its own circuits.
What is the difference between an introduction point and a rendezvous point?
The introduction point passes a private invitation from the client to the service. The rendezvous point is a separate relay that joins the client and service circuits for the actual connection.
Does a .onion address prove that a site is trustworthy?
No. A v3 onion address is tied to a cryptographic service identity, but it does not prove that the operator is safe or honest. Users should verify the full address through an official or trusted source before sharing sensitive information.
Can onion services still be attacked or exposed?
Yes. Application-layer abuse, denial of service attacks, software vulnerabilities, unsafe logs, and administrator mistakes can still harm or expose a service. Secure configuration, isolation, rate limits, and careful operational practices are needed in addition to Tor’s location hiding.
Final Thoughts
Onion services protect a server’s location through separate relays and temporary paths. The introduction relay passes an invitation, while a rendezvous point connects the meeting paths.
This design offers location hiding, a verified onion address, and encrypted communication without traditional DNS. These security benefits still depend on secure hosting and careful browsing. Client authentication is separate from address verification, and denial of service remains possible.