A Tor onion service is a network service—often a website—that readers reach through the Tor network instead of through an ordinary public IP address and DNS route. A current version 3 onion hostname uses a 56-character label followed by .onion. That address is derived from the service’s cryptographic identity, so it participates in authenticating the connection rather than acting as a human-chosen label registered through conventional DNS.

For publishers, an onion service offers a way to make a site available without publishing its origin address as the destination. Client-to-service traffic remains inside Tor and does not use an exit relay. These are valuable properties, but they cover a specific part of the system. They do not automatically secure the web application, remove identifying content, create an audience, or keep a service online.

What makes an onion service different

A conventional website usually publishes a DNS name that leads, directly or indirectly, to an Internet-reachable server or edge service. A Tor onion service instead behaves like a Tor client: it makes outbound connections into the Tor network and establishes paths through relays. A reader must know the onion address and use Tor-aware software, normally Tor Browser, to connect.

The .onion suffix is a special-use name defined for Tor. Ordinary DNS resolvers are not supposed to resolve it. In a version 3 onion address, the encoded public-key material, checksum, and version allow Tor software to validate the address and authenticate the service reached through the protocol. A publisher does not purchase the address from a registrar. Control follows control of the corresponding private identity key.

This has several consequences:

  • The address is part of the service identity. Losing the private key means losing the established address. Leaking it can allow impersonation. Key storage and recovery planning are therefore launch requirements, not optional housekeeping.
  • The origin does not need an inbound public web port for the onion route. Tor establishes outbound circuits. The backend can listen locally or on a tightly controlled private path.
  • Anyone who knows the address can normally visit. A long, hard-to-guess address is not access control. Tor supports client authorization when a service must be restricted to people holding approved credentials.
  • Discovery is separate from reachability. Tor can carry a connection once the reader has the address, but the publisher still decides how that address is distributed and verified.

Tor Project documentation describes location hiding, end-to-end authentication, end-to-end encryption, and the ability to operate through outbound connections as central onion-service properties. Those properties make onion services useful for journalism, secure submission systems, censorship-resistant publication, private collaboration, and alternate access to established public sites. They do not make every onion site trustworthy; authenticity to an address is not the same as confidence in the person or organization behind it.

How a reader and service meet without a public destination address

The onion-service protocol separates introduction from the eventual conversation. At a high level, the service first selects Tor relays as introduction points and keeps circuits open to them. It creates a signed descriptor containing information a client needs to make contact and publishes that descriptor to the network’s onion-service directory system. This does not publish the origin server’s IP address as the service destination.

When a reader enters an onion address, the Tor client retrieves the appropriate descriptor and learns the current introduction points. The client independently chooses a Tor relay as a rendezvous point and builds a circuit to it. Through an introduction point, the client asks the service to meet at that rendezvous point and begins a cryptographic handshake.

The service then builds its own circuit to the rendezvous point. The rendezvous relay joins the two Tor circuits so application traffic can flow, but the protocol’s cryptography prevents that relay from simply impersonating the onion service. The client proves that it reached the identity represented by the address. Both sides use Tor paths, and no exit relay is needed because the destination is inside Tor.

This design is why “a website behind three proxies” is not an adequate description. Introduction points help clients signal the service; the rendezvous point joins independently built paths; distributed descriptors help clients learn where to introduce themselves; and the onion address anchors the service identity. Those roles can change over time without changing the public onion address.

The protocol also supports restricted discovery, commonly presented to operators as client authorization. In that mode, a reader needs a private credential in addition to the onion address. It is appropriate for a private team or controlled research service, but it adds credential distribution and revocation work. A public publication normally does not enable it, because public readers could not connect without prior enrollment.

Publishing remains an application and operations job

The Tor Hidden Services guide describes the product-specific route. The simplest onion-service deployment has three functional pieces: a web application, a Tor process, and a mapping that tells Tor which virtual service port leads to which local application endpoint. Tor’s setup guidance recommends local isolation, including Unix sockets where practical, to reduce accidental exposure on a local network. The onion-service key directory must have correct ownership and restrictive permissions.

From there, ordinary publishing responsibilities return. The operating system, Tor, web server, database, content-management system, themes, and plugins need updates. Administrator accounts need strong authentication and limited privileges. Backups must protect both content and service keys. Restore testing must confirm that the site and the same onion identity can be recovered.

The application should also be reviewed for information that can escape through the page itself. Common examples include author names, document metadata, third-party fonts or analytics, remote images, verbose server headers, default error pages, and links to accounts used elsewhere. Tor Project operational-security guidance specifically warns that web-server behavior and availability patterns may reveal information. A network route cannot redact content or decide which correlations matter to a particular publisher.

Transport choices inside the deployment deserve attention as well. Onion-service traffic is authenticated and encrypted through the Tor protocol. If Tor and the web server run on different machines, however, the connection between them needs its own protection. Some frameworks also require HTTPS features, and some publishers use HTTPS as an additional verification or usability signal. Tor’s HTTPS guidance treats this as a design decision rather than a ritual: understand which segment and browser behavior the additional layer is serving.

Finally, readers need a trustworthy copy of the onion address. An HTTPS clearnet page can authenticate a link to its onion counterpart or advertise it with Onion-Location. Tor treats the Onion-Location header as valid only when a non-onion page serves it over HTTPS. A publisher can also distribute the address through signed announcements, established profiles, print, partner directories, or direct channels. Copying an address from an unverified directory creates an obvious substitution risk because 56-character names are difficult to inspect visually.

Practical Takeaway

A publisher preparing an onion service should be able to demonstrate all of the following before launch:

  • The web application is reachable from Tor but not exposed on unintended interfaces.
  • The version 3 onion address has been recorded accurately, and its private identity keys are access-controlled and backed up.
  • A restore exercise can recover both the publication and its established address.
  • The service has been tested from a separate Tor Browser installation, not only from the host itself.
  • Content, headers, error pages, dependencies, logs, and uploaded files have been reviewed for unwanted identifying information.
  • The team knows whether the service is public to anyone with the address or protected by client authorization.
  • The public address is distributed through at least one channel readers can authenticate.
  • Monitoring checks the reader-visible onion route without adding invasive third-party trackers.

For a direct network comparison, see I2P vs. Tor for Publishers. An onion service is best treated as a first-class publishing endpoint, not a secrecy add-on. Tor provides a carefully designed private route and self-authenticating service identity. The publisher supplies secure application design, restrained data handling, reliable operations, honest audience guidance, and clear policies. Both halves are necessary.

Sources and Further Reading