en
TLS and HTTPS Internals for Tor Hidden Services
Tor hidden services encrypt connections using the Tor protocol - the connection between a Tor client and a .onion service passes through multiple layers of encryption provided by the Tor circuit construction process. This built-in encryption raises a common question: does a .onion service need HTTPS (TLS) in addition to Tor encryption? The answer depends on the threat model and architecture. This guide explains what Tor's encryption covers, where gaps exist, when adding TLS provides meaningful additional security, and how to manage TLS certificates for .onion addresses (which cannot obtain certificates from public CAs in the standard way). Understanding the Tor encryption model helps operators make informed decisions about their security architecture rather than blindly adding TLS or blindly omitting it.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
What Tor Encryption Covers
Tor hidden service connections establish end-to-end encryption between the client Tor process and the server Tor process through the rendezvous point mechanism. The encryption uses: (1) per-hop symmetric encryption on each relay in both the client circuit and service circuit (using AES-256-CTR), (2) public key authentication of the hidden service identity (Ed25519 and X25519 as part of v3 onion authentication), and (3) forward secrecy via ephemeral key exchange during circuit establishment. This encryption is transparent to the application layer - the Nginx or application server receives plaintext on its loopback interface (127.0.0.1:80 or a Unix socket). The security guarantee is: no relay on either circuit, no entity at the rendezvous point, and no network observer can read the application-layer content.
Where Tor Encryption Has Gaps
Tor's encryption does not protect against all threats. Gaps: (1) if the server is compromised and runs malicious software, Tor encryption is irrelevant - the attacker reads plaintext directly, (2) if the Tor hidden service key is compromised, an attacker can impersonate the service (though cannot decrypt past sessions due to forward secrecy), (3) the client's browser must trust the displayed content - XSS attacks injecting malicious scripts are not prevented by Tor encryption, (4) for multi-hop architectures where the Tor hidden service proxies to a backend server (database, API, microservice) the traffic between Tor and the backend is unencrypted unless separately secured. The loopback path (127.0.0.1:application) is unencrypted - on a single-server setup this is fine, but in containerized or multi-service architectures, this loopback traffic may cross a network interface or container boundary that should be TLS-protected.
When to Add TLS to a .onion Service
Adding TLS to a .onion service is recommended in these scenarios: (1) multi-server architecture where Tor terminates on a different host than the application - the internal network path should be TLS-encrypted, (2) application requires HTTPS for functionality (HTTP Strict Transport Security, secure cookies, browser APIs that require HTTPS), (3) compliance requirements that mandate TLS regardless of transport layer (PCI-DSS, some healthcare regulations), (4) defense in depth for high-security services where compromising Tor encryption alone is insufficient for attackers. Adding TLS to a simple single-server .onion service is low value - Tor's encryption already provides equivalent protection and the certificate management overhead is non-trivial for .onion addresses.
Certificate Options for .onion Addresses
Public CAs (Let's Encrypt, DigiCert) do not issue certificates for .onion addresses through standard ACME challenge methods because .onion addresses are not resolvable on the public internet. Options for .onion TLS: (1) self-signed certificates - generate with openssl req -x509, configure the browser to trust the certificate by fingerprint, works well for private or internal-facing services where you control all clients, (2) private CA - create your own CA with step-ca or XCA, issue certificates for .onion addresses from your CA, distribute the CA certificate to all users (via Tor Browser's certificate store), (3) CAB Forum approved: a small number of CAs (DigiCert and a few others) issue Extended Validation (EV) certificates for .onion addresses under a special validation procedure that requires proving control of the .onion private key. EV .onion certificates cost hundreds of dollars per year and are primarily used by legitimate businesses (Tor-accessible bank portals, SecureDrop instances). Tor Browser ships trust for standard CAs so EV certs work without additional client configuration.
Configuring Nginx with TLS for Hidden Services
When adding TLS to a .onion hidden service, configure Nginx to listen on port 443 with the .onion TLS certificate: generate the private key and certificate (openssl req -x509 -newkey rsa:4096 -keyout /etc/nginx/ssl/onion.key -out /etc/nginx/ssl/onion.crt -days 365 -nodes -subj '/CN=youraddress.onion'). In torrc, point the HiddenServicePort to port 443: 'HiddenServicePort 443 127.0.0.1:443'. In nginx.conf, configure the SSL virtual host with your .onion certificate. Use strict TLS 1.3 only (remove TLS 1.0/1.1 support). Redirect HTTP (port 80) to HTTPS (port 443) to enforce TLS. Set HSTS headers with max-age=31536000. For Tor Browser clients, distribute the certificate's SHA-256 fingerprint so users can verify the cert manually: openssl x509 -fingerprint -sha256 -noout -in onion.crt.
Related Services
Why Anubiz Host
100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.