Skip to main content

Glossary Infrastructure

Onion service v3

Also: Tor hidden service v3, v3 onion address, .onion v3

Origin: Tor proposal 224 (Roger Dingledine, Nick Mathewson, et al.); v3 was activated in Tor 0.3.2 (January 2018) and the legacy v2 protocol was deprecated in October 2021.

The third-generation Tor onion-service protocol, deployed network-wide in 2018, replacing the legacy 16-character v2 addresses with 56-character ed25519-based v3 addresses. The protocol improves cryptographic strength, defends against enumeration of services, and supports new operational primitives including client authorisation.

The third-generation Tor onion-service protocol, deployed network-wide in 2018 and now the only supported variant after the legacy v2 protocol was deprecated in October 2021, is the substrate on which the publication’s contact form and the operator’s incident-response channels are anchored. The protocol replaced v2’s 16-character base32 RSA-1024-derived addresses with 56-character base32 ed25519 public keys, eliminating the cryptographic-strength weakness of v2 (RSA-1024 is no longer considered safe), eliminating the enumeration-by-relay attack that v2 supported, and adding operational primitives that were not in v2 — most notably client authorisation, in which an onion service can require connecting clients to present a credential before the service even acknowledges its existence.

The cryptographic shape of a v3 address is the base32 encoding of the ed25519 public key concatenated with a checksum and a version byte. The full 56-character length is the price of cryptographic strength; the address is not memorisable, which is operationally a constraint and structurally a feature (an address that cannot be casually shoulder-surfed is harder to incidentally disclose).

Operating an onion service end-to-end well is a discipline. The host has to be patched, hardened, and behind a configuration that does not leak the underlying IP through banner pages, error pages, or side-channel timing. The service has to be configured to bind only to localhost (not to the public interface as well, which is the most-common operator-side leakage). And the application running on the onion has to be configured not to embed absolute URLs that resolve outside Tor — a common failure mode for content-management systems that auto-generate canonical URLs.

For an offshore-hosting operator the v3 onion is the substrate on which the operator’s most-sensitive subscriber-facing surfaces — the contact form, the support-ticket portal, the warrant-canary publication — are hosted. The publication has set out the operator’s view on hidden-service-side hardening in the upcoming field-note on the topic; the contact form is also reachable through a v3 onion published in the publication’s security.txt (when that surface lands; see the S7 roadmap entry).