[$ xmrhost] _

$ man 7 tor

[$ ] Tor hosting — hidden services, relays, exits, bridges

// NAME

tor — pillar entry for Tor hosting on XMRHost. Definitions, threat models, configuration baseline, and links into the operational surface (plans, docs, notes).

// SYNOPSIS 

xmrhost-cli order --plan=tor-1 --region=<is|ro>     # hidden service (default)
xmrhost-cli order --plan=tor-2 --region=<is|ro>     # active hidden service / matrix homeserver
xmrhost-cli order --plan=tor-4 --region=<is|ro>     # high-traffic hidden service
xmrhost-cli order --plan=vps-2 --addons=tor-relay-config  # non-exit middle relay

// THE FOUR ROLES

$ man tor-roles

A Tor host operates one of four roles. The roles compose only in specific configurations; running the wrong role for the workload is the most common operational error.

  • Hidden service (v3 onion service) — a network service reachable only via Tor, addressed by a 56-character base32 .onion hostname derived from an Ed25519 long-term identity key (rend-spec-v3). The service does not advertise on the public DNS or IP routing. XMRHost's tor-1 / tor-2 / tor-4 plans target this profile with hardened tor.conf and onion-auth- gated sshd.
  • Non-exit middle relay — forwards traffic between other relays only. Carries no abuse-mail load (the IP never appears in destination logs). Recommended starting profile for an offshore VPS contributing to the Tor network. Available as an addon to the standard /node/vps plans (tor-relay-config addon, $5/mo).
  • Exit relay — forwards traffic to clearnet on behalf of clients. Higher abuse-mail load; published-contact obligations under Tor Project guidance. XMRHost does NOT run exits from its standard Tor tier — the workload routes to /node/lokinet-exit (different operator posture). Operators wanting a proper Tor exit should use a dedicated provider with explicit exit-relay AUP support.
  • obfs4 bridge — pluggable-transport-equipped Tor bridge. Wraps Tor traffic in an obfuscated random-looking byte stream. Used by clients in jurisdictions where Tor's wire signature is fingerprinted. obfs4 is an obfuscation layer, not an additional anonymisation primitive.

// THREAT MODELS PER ROLE

$ man tor-threat-model

The threat model is role-specific. Operating without a role-specific model is the practical security failure most often visible in post-incident write-ups.

// hidden service operator

  • Adversary — service-deanonymisation by traffic correlation; .onion-typo squatting; clearnet-side service-misconfig leak (the most common deanonymisation vector in 2014–2024 case law).
  • Controls — no clearnet listener (sshd via onion-auth, web on onion only); hardened tor.conf (HardwareAccel 1, SafeLogging 1); onion-auth client keys for gated services; vanity .onion only as convenience, not as mitigation against typo-squat (rend-spec-v3 recommends bookmark flow for this).

// non-exit relay operator

  • Adversary — bandwidth/CPU exhaustion DoS; Sybil-coordinated relay deployment; AS-level adversary running guard relays in the same AS as the operator (correlation mitigation: pick guards across distinct AS).
  • Controls — MyFamily declaration linking the operator's relays so circuit-construction avoids them as a triple; ContactInfo for abuse routing; reasonable BandwidthRate / BandwidthBurst caps so a misconfig doesn't saturate the upstream.

// exit relay operator

  • Adversary — abuse-mail volume; civil correspondence from rightsholders; criminal-investigation correspondence (rare but procedurally serious); upstream provider's exit-AUP enforcement.
  • Controls — published exit policy + ContactInfo; ExitPolicy reduce-policy or restrictive-policy depending on the provider; abuse-mail auto-responder; relationship with upstream counsel before going live.

// XMRHOST CONFIGURATION BASELINE

$ cat /etc/tor/torrc

Every XMRHost Tor plan ships with the following baseline applied at provisioning. Tenants extend rather than reset. 

# /etc/tor/torrc — XMRHost Tor baseline

# Identity + log
Nickname           xmrhost-tenant
ContactInfo        <set per tenant>
SafeLogging        1
Log                notice file /var/log/tor/notices.log

# Hardening
HardwareAccel      1
SocksPort          0
ControlPort        unix:/run/tor/control GroupWritable RelaxDirModeCheck
ControlSocket      /run/tor/control GroupWritable RelaxDirModeCheck

# Hidden service (v3) — present on tor-* plans
HiddenServiceDir            /var/lib/tor/onion-svc/
HiddenServicePort           80 unix:/run/xmrhost/web.sock
HiddenServiceVersion        3

# Onion-auth gates sshd via the same identity key
HiddenServicePort           22 unix:/run/xmrhost/sshd.sock
HiddenServiceAuthorizeClient v3-onion-auth

# Non-exit relay role only fires when the addon is enabled
# ORPort           443
# ExitRelay        0
# ExitPolicy       reject *:*
# MyFamily         <fingerprint set on order activation>

// the comment block at the bottom is the relay-config delta enabled by the tor-relay-config addon ($5/mo on /node/vps plans). The addon flips ORPort + MyFamily + sets a defensible ExitPolicy; the operator confirms upstream bandwidth is fine with the ramp before flipping.

// JURISDICTIONAL POSTURE

$ man tor-jurisdiction

Iceland and Romania are both permissive toward Tor relays and hidden services in the operator-side experience. Neither jurisdiction has codified anti-anonymity legislation that would criminalise running a non-exit relay or a hidden service. Hidden- service content is the tenant's responsibility under the same evidentiary standard that applies to any other hosted content (Höfundalög nr. 73/1972 in Iceland, Legea nr. 8/1996 in Romania — court process, not private notice). See /vs/iceland-vs-romania-offshore-jurisdiction for the long-form comparison.

Exit relays are a different operator posture. XMRHost's standard Tor tier does not run exits — the legal-correspondence load is material and the brand routes the workload to Lokinet exits where the OXEN-stake economic model fits better. Operators wanting Tor exits specifically should choose a provider with explicit exit-AUP support.

// XMRHOST TOR PLANS

$ ls /node/tor-hidden-service

// plan // spec // $/mo // fit
tor-1 1c / 2GB / 50GB $20 starter — one hidden service, light load
tor-2 2c / 4GB / 50GB $42 active hidden service, mid-traffic forum, matrix homeserver
tor-4 4c / 8GB / 50GB $85 high-traffic hidden service, larger forum, journalism intake

// SEE ALSO

$ ls /usr/share/doc/xmrhost/tor