EOTK / Tor Hidden Service

A Tor hidden service is a website accessible via a .onion address that resolves only inside the Tor network. Connections between user and site go through three Tor relay hops in each direction, with end-to-end encryption from user's Tor client to the hidden service. No exit node involvement. No public IP exposure on either side.

The use case for major sites running .onion mirrors:

• Users in censored jurisdictions can reach the content even when the public domain is blocked.
• Sources contacting investigative journalists can do so without revealing their network identity to anyone, including the journalist's ISP and the journalist themselves.
• Whistleblower platforms (SecureDrop, GlobalLeaks) require .onion access for source protection.
• Privacy-conscious users who don't want their browsing patterns exposed to ISPs or DNS providers.

Examples in current use: The New York Times (nytimes3xbfgragh.onion), BBC (bbcnewsv2vjtpsuy.onion), Facebook (facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion), ProtonMail, DuckDuckGo, plus most major privacy-focused services.

EOTK is a software toolkit (open source, built on Tor + nginx + Lua scripting) that automates the operational work of running a .onion mirror.

Without EOTK, running an .onion mirror manually requires:

1. Setting up a Tor hidden service.
2. Configuring a web server to handle the hidden service traffic.
3. Rewriting all references to the public domain in served content (HTML, CSS, JavaScript) so links inside the .onion mirror stay on the .onion.
4. Handling cookies, session state, CSRF tokens correctly across the dual-domain setup.
5. Managing TLS certificates if you want HTTPS .onion (yes, that's a thing now via the Onion v3 cert system).
6. Operational monitoring, performance tuning, abuse handling.

EOTK packages all of this. You point it at your public domain, run a setup wizard, and it generates the configuration to mirror your public site as an .onion. The mirror handles content rewriting transparently: links to example.com in served content become links to your .onion equivalent on the fly.

EOTK supports two main patterns:

Transparent proxy mode. The .onion mirror sits in front of your existing public site. User requests via .onion are proxied to the public origin (over Tor or a private network), responses are content-rewritten on the fly, and served back through the .onion. Easiest to deploy. Doesn't require changes to your application code. Works for nearly any website.

Dedicated origin mode. You run a separate copy of your site dedicated to .onion traffic. EOTK handles the Tor-side networking; your application handles the requests directly. More work to set up. Better isolation between public and .onion traffic. Required if your application needs to know it's being accessed via .onion (e.g., for source-protection workflows that should never touch the public side).

Most operators start with transparent proxy mode because it's the path of least resistance. If your application later needs proper .onion-aware behaviour, migrate to dedicated origin.

Standard EOTK deployment:

1. Server requirements. A Linux server (Debian/Ubuntu best supported), Tor installed, nginx, and EOTK Lua dependencies. Modest hardware works because Tor is not bandwidth-intensive on the hidden service side.
2. Generate the .onion address. EOTK generates a random v3 address by default. If you want a vanity address (recognisable prefix), use mkp224o separately to brute-force-generate one and import it. Vanity addresses take hours to days of CPU depending on how many leading characters you want.
3. Configure EOTK. Provide the public domain, the .onion target, any specific rewriting rules (custom CSP headers, special path handling). EOTK generates the nginx config.
4. Test internally. Browse to the .onion address via Tor Browser. Verify all links stay on .onion. Check forms, login flows, JavaScript-heavy interactions.
5. Publish. Add the .onion address to your public site's footer, "About" page, or contact section. Use the Onion-Location HTTP header so Tor Browser users on the public site automatically discover the .onion mirror.

• Mixed-content errors. Site loads resources from CDNs or third-party domains that aren't mirrored. Tor Browser blocks those resources by default. Audit external resources and either inline them, mirror them, or accept the broken-on-Tor experience.
• JavaScript-heavy SPAs that bypass content rewriting. EOTK rewrites HTML responses. JavaScript that constructs URLs at runtime can leak public-domain references that EOTK doesn't catch. Solution: build your app with relative URLs throughout, or detect .onion access and adjust.
• Cookies tied to public domain. Cookies set with Domain=example.com don't apply to the .onion address. Login state breaks. Either set cookies without Domain attribute (more permissive) or implement separate session handling for the .onion.
• HSTS headers. If your public site sets HSTS, browsers may try to upgrade .onion HTTP requests to HTTPS, which fails (since .onion uses Tor encryption, not TLS by default). Strip HSTS on .onion responses.
• Performance issues. Tor adds latency. Sites that work fine over the public web feel slow over .onion. Optimise: minimise round-trips, reduce JavaScript, lazy-load non-critical resources, cache aggressively at the .onion edge.
• Forgetting Onion-Location. The HTTP header that tells Tor Browser users on your public site that an .onion mirror exists. Without it, users have to find the .onion address manually. Add the header on every public-domain response.

Older Tor used short addresses (16 characters, hash of a 1024-bit key). These were deprecated in 2021. Modern Onion v3 addresses are 56 characters, hash of an Ed25519 key. Visually they look like:

facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion

Longer, harder to type, but cryptographically stronger. EOTK generates v3 by default. Anyone running v2 should migrate; v2 stopped working in late 2021.

v3 addresses also enable HTTPS-on-.onion via Tor's native cert system. Most major .onion services don't bother with HTTPS on .onion (Tor encryption is already end-to-end), but it's available if your specific use case needs it.

EOTK (Enterprise Onion Toolkit) is a reverse proxy that fronts existing clearnet sites with Tor hidden service equivalents. The architecture runs an EOTK instance (typically on dedicated infrastructure separate from the clearnet origin) that accepts connections on a Tor hidden service address and proxies them to the clearnet origin while rewriting content to use the onion address consistently.

The content rewriting is what makes EOTK valuable for non-trivial sites. Modern web pages reference many resources (images, CSS, JavaScript, fonts, API endpoints, links to other pages on the same site) and naive proxying that did not rewrite these references would cause Tor users to leak back to the clearnet through resource loads or to encounter broken navigation when following internal links. EOTK rewrites all of these so that the entire user experience stays within the Tor network.

The deployment model is operator-controlled: an organization that wants to provide an onion mirror of its existing site deploys EOTK in front of that site, configures the rewriting rules for the specific content patterns the site uses, and publishes the resulting onion address. EOTK does not require modifying the underlying site code; it operates entirely as an external proxy layer.

EOTK is used in production by major news organizations (The Guardian, Reuters, ProPublica all use EOTK for their onion mirrors), privacy-focused services, and security-research platforms. The codebase is open-source and actively maintained by Alec Muffett who is the original author and primary maintainer.

Production EOTK deployment requires several configuration decisions that the documentation covers but that benefit from operational context. The patterns below reflect what we have seen work across multiple deployments.

The EOTK process should run on dedicated infrastructure rather than alongside the clearnet origin. The reasoning is that Tor hidden service operation has different operational characteristics than clearnet web serving (different traffic patterns, different attack surfaces, different monitoring requirements), and separating concerns produces cleaner operations. Many EOTK deployments we have run use a small VPS (2 vCPU, 4 GB RAM) for the EOTK process plus the Tor daemon; the EOTK itself is lightweight and most of the resource consumption comes from the proxy traffic volume.

The configuration file (EOTK uses YAML configuration) specifies the clearnet site domain to mirror, the rewriting rules for content, the cipher suites and TLS configuration for the upstream connection to clearnet, and the Tor hidden service parameters. Most deployments use the default rewriting rules with minor customizations for site-specific patterns; aggressive customization is rarely needed and often introduces bugs.

Performance tuning matters for high-traffic deployments. EOTK can sustain hundreds of concurrent connections per process; deployments that exceed this should run multiple EOTK processes behind a load balancer or scale vertically with larger hardware. The Tor daemon itself has performance limits that EOTK inherits; deployments above approximately 10K daily unique visitors typically benefit from running multiple Tor instances for hidden service load distribution.

Monitoring and observability should track: the Tor hidden service availability (probes from external Tor clients), the upstream clearnet origin reachability (the same monitoring you would use for direct clearnet operations), the EOTK process health (CPU, memory, connection counts), and aggregate traffic metrics (request rates, response times, error rates). Standard production monitoring tools (Prometheus, Grafana, custom exporters) integrate cleanly with EOTK metrics.

EOTK provides a Tor access path to clearnet content; it does not provide complete anonymity from the operator perspective. The threat model matters because operators sometimes deploy EOTK expecting protection that the architecture does not actually provide.

What EOTK does provide: end-user anonymity for Tor visitors accessing the content (the visitor IP is not visible to the clearnet origin, only to the EOTK reverse proxy which sees the Tor exit IP), end-user privacy from network observers between the Tor client and the clearnet origin (the traffic is encrypted through the Tor network), and protection against censorship that blocks the clearnet origin domain (Tor connections evade most domain-based blocking).

What EOTK does not provide: complete protection of end-user identity if the underlying site requires authentication or tracks behavior through application-level mechanisms (cookies, fingerprinting, login state), protection against the operator logging or analyzing the traffic at the EOTK proxy layer, protection against compromise of the EOTK infrastructure that could expose the upstream clearnet relationship, complete protection from sophisticated traffic analysis that could correlate Tor traffic patterns with clearnet origin patterns.

For operators deploying EOTK with privacy-positioned framing (journalism platforms, whistleblower submission systems, censorship circumvention), the threat model needs to include the EOTK infrastructure itself as a potential point of compromise. Mitigations include: running EOTK on infrastructure separated from the clearnet origin, configuring EOTK to retain no logs, deploying in jurisdictions with legal frameworks that resist legal-process compromise of the infrastructure, monitoring the EOTK infrastructure for indicators of unauthorized access.

For operators deploying EOTK as a convenience for Tor-using customers without specific privacy requirements (commercial sites, content publishers), the threat model is less stringent. The operational practices can be more relaxed: standard logging is acceptable, infrastructure can be in any standard hosting jurisdiction, monitoring can use standard production tooling without special hardening.

EOTK is not the only option for deploying onion mirrors of clearnet sites. Several alternatives exist with different operational tradeoffs.

Direct configuration of the web server as a Tor hidden service: bypasses EOTK entirely and configures the existing nginx or Apache instance to bind to a Tor hidden service address. The approach works for simple sites where no content rewriting is needed but breaks down for non-trivial sites that reference resources across domains or that depend on JavaScript referencing the clearnet domain. Most production sites cannot use this approach cleanly.

Onion Browser Web Bridges: client-side approach where Tor Browser provides a rewriting layer for clearnet content. The approach has been proposed and partially implemented but never reached production deployment as a standard option. Operators currently cannot rely on it as a deployment path.

Custom reverse proxy with rewriting logic: some organizations have built custom proxy software specifically for their onion mirror needs. The approach is operationally expensive (development cost, maintenance cost) but produces tightly-fitted solutions for organizations with specific requirements. We have not seen this approach pay back outside of organizations with very specific compliance or threat-model needs.

Separate-copy architecture (not reverse proxy): deploy a separate copy of the content directly on Tor hidden service infrastructure without any clearnet connection. The approach provides the strongest privacy properties because the content does not flow back to clearnet, but it requires content synchronization between the clearnet copy and the Tor copy which adds operational complexity. Used by some journalism platforms with strong source-protection requirements.

For most operators evaluating onion mirror deployment, EOTK is the operationally correct starting point because it is proven, maintained, and well-documented. The alternatives become relevant only for specific use cases where EOTK constraints do not match the requirement.

EOTK deployments at production scale need monitoring patterns that match the architecture rather than borrowing patterns directly from clearnet web hosting. The Tor network adds operational characteristics that conventional web monitoring may not catch.

The metrics that matter most for production EOTK: Tor hidden service availability through external Tor client probes, upstream clearnet origin availability through standard HTTP monitoring, EOTK process health through standard system metrics (CPU, memory, connection count), aggregate request rate and response latency, error rate and error category breakdown. The combination produces visibility into both the Tor-side and the upstream-side health.

External Tor probing requires running monitoring infrastructure that connects to the Tor network and tests the hidden service from a real Tor client perspective. The probing catches Tor-network-specific issues that internal monitoring on the EOTK host would not see: hidden service descriptor publication failures, circuit establishment problems, intermediate node issues affecting reachability. Multiple geographic probe locations produce better coverage than single-location probing because Tor circuit routing varies by client location.

Capacity planning for EOTK is somewhat different from clearnet capacity planning because the Tor latency dominates request handling time for most operations. The CPU and memory requirements for EOTK itself remain modest; the bottleneck typically appears in connection-count limits as concurrent users build up on Tor circuits that take longer to establish and complete than equivalent clearnet connections.

For production deployments expecting more than 1,000 daily unique visitors, the standard pattern is running multiple EOTK processes behind a load balancer or scaling vertically with larger hardware. The Tor daemon itself has performance characteristics that benefit from running multiple instances for hidden service load distribution; deployments above approximately 10,000 daily unique visitors typically benefit from multi-Tor-daemon configurations.

EOTK is the most widely deployed solution for converting clearnet sites to Tor hidden service equivalents, but the broader landscape includes alternatives that match different operational requirements.

Direct Tor configuration of the existing web server: suitable for simple sites without external resource references. Bypasses EOTK entirely by configuring nginx or Apache to bind to a Tor hidden service. The approach works for static sites and simple applications but breaks down for modern web stacks that reference resources across domains.

Custom reverse proxy implementations: some organizations build their own proxy software for specific requirements. The approach is operationally expensive but produces solutions tightly fitted to specific needs that off-the-shelf options do not address.

Separate-copy architecture: running a separate copy of the content directly on Tor infrastructure without any clearnet connection. The approach provides stronger privacy properties but requires content synchronization between the clearnet and Tor copies.