Hospede um site .onion no seu VPS com Tor

O que você está criando

Um site onion é um servidor web normal que responde apenas pela rede Tor. Instale o tor, adicione duas linhas a /etc/tor/torrc, leia o endereço que o tor gravar para você e depois faça o nginx escutar em 127.0.0.1, para que nada responda pelo IP público. A instalação demora dez minutos. O restante deste guia é a lista de pontos que podem causar vazamentos, porque a forma mais comum de um site onion falhar é a própria configuração apontar diretamente para o operador.

O Tor começou como "the onion router", e um serviço onion é um serviço que só pode ser acessado por ele. Um endereço da versão 3 tem 56 caracteres seguidos de .onion. Esses caracteres são a chave pública ed25519 do serviço, mais um checksum e um byte de versão, codificados em base32. Os endereços da versão 2 (16 caracteres) foram removidos da rede em 2021. Portanto, tudo o que você gerar hoje será v3. O endereço é a chave, o que tem duas consequências. A conexão é criptografada e autenticada de ponta a ponta, sem o envolvimento de uma autoridade certificadora. Perder o arquivo da chave significa perder o endereço permanentemente.

Seu servidor nunca aceita uma conexão de entrada. O Tor escolhe alguns relays como pontos de introdução, envia um descritor assinado aos servidores de diretório e encontra cada visitante em um relay de rendezvous escolhido pelo visitante. Todas essas conexões são de saída a partir do seu servidor. Não há nenhuma porta para abrir nem registro DNS para publicar. Se você quiser que o mesmo VPS ofereça algo de volta à rede, essa é outra tarefa, com características opostas, porque uma bridge obfs4 aceita conexões de entrada de clientes sob censura e precisa de uma porta acessível.

Instalar o tor a partir do repositório do Tor Project

O Ubuntu disponibiliza um pacote tor no repositório universe, mas este mantém-se próximo da versão que estava atual quando a versão do Ubuntu foi congelada. O repositório do próprio Tor Project acompanha a versão estável atual, que é a opção pretendida para o componente de software que determina se o seu endereço continua a ser seu. A existência de um pacote numa distribuição não indica se o projeto ainda está a ser desenvolvido. Vale a pena verificar isso em qualquer aplicação que aloje por conta própria, porque o Searx não recebe commits de código desde 2023, enquanto o SearXNG dá continuidade a esse projeto.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget
KEYURL=https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc
wget -qO- "$KEYURL" | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

A entrada do repositório usa o formato deb822, e Suites tem de ser o codename do seu Ubuntu. Leia-o a partir de /etc/os-release em vez de o escrever manualmente. Um codename incorreto produz um repositório que é resolvido corretamente, mas que não tem pacotes para a sua versão.

. /etc/os-release
sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $VERSION_CODENAME
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring

O pacote deb.torproject.org-keyring mantém a chave de assinatura atualizada. Assim, uma rotação de chaves não interrompe apt update daqui a um ano. Confirme que o tor iniciou e alcançou a rede:

tor --version
sudo journalctl -u tor@default -n 20

O journal deve terminar com Bootstrapped 100% (done): Done. Um tor preso em Bootstrapped 10% não tem uma rota de saída. Verifique a firewall de rede do seu fornecedor e as suas próprias regras de saída: sudo ufw status verbose deve mostrar allow (outgoing) como predefinido.

A partir daqui, há dois nomes importantes. O pacote executa o tor com o utilizador debian-tor, e a unidade em execução é tor@default.service, porque tor.service no Debian e no Ubuntu é um wrapper em torno da instância. Consulte o estado e os logs pelo nome da instância para obter sempre o processo real.

Configure o serviço onion no torrc

Anexe duas linhas a /etc/tor/torrc:

HiddenServiceDir /var/lib/tor/onion_site/
HiddenServicePort 80 127.0.0.1:8080

HiddenServiceDir é onde o tor mantém as chaves e o endereço deste serviço. Não crie esse diretório manualmente. O tor cria-o ao iniciar, com o proprietário e as permissões de que precisa. Um diretório criado por root causa a primeira falha da lista abaixo.

HiddenServicePort tem duas partes, e confundi-las é o erro inicial mais comum. O primeiro número é a porta à qual um visitante se liga dentro do túnel. Por isso, 80 é o valor esperado e não há motivo para alterá-lo. A segunda parte é o endereço local para onde o tor encaminha esse tráfego. Um HiddenServicePort 80 simples encaminha para 127.0.0.1:80. Especificar o endereço e usar uma porta alta mantém o vhost onion separado de qualquer serviço que já esteja escutando na porta 80.

sudo systemctl restart tor@default
sudo ls -l /var/lib/tor/onion_site/

A listagem deve conter hostname, hs_ed25519_public_key, hs_ed25519_secret_key e um diretório authorized_clients vazio.

Leia o seu endereço .onion

sudo cat /var/lib/tor/onion_site/hostname

É devolvida uma linha: 56 caracteres base32 e .onion. Essa cadeia é a identidade completa do site. Ninguém a atribui, ninguém a pode transferir e ninguém a pode retirar enquanto tiver o ficheiro de chave. Copie-a agora, porque todas as configurações abaixo precisam dela. O restante deste guia escreve-a como <your-address>.onion.

Servir o site a partir do nginx ligado a 127.0.0.1

sudo apt install -y nginx
sudo install -d -m 755 /srv/onion

Escreva /etc/nginx/sites-available/onion:

server {
    listen 127.0.0.1:8080;
    server_name <your-address>.onion;

    root /srv/onion;
    index index.html;

    server_tokens off;
    etag off;
    access_log off;
    error_log /var/log/nginx/onion.error.log error;
}

echo '<h1>hello from the onion</h1>' | sudo tee /srv/onion/index.html
sudo ln -s /etc/nginx/sites-available/onion /etc/nginx/sites-enabled/onion
sudo nginx -t
sudo systemctl reload nginx

Agora confirme duas coisas a partir do servidor. A primeira é que o nginx responde pelo nome onion, que corresponde exatamente ao cabeçalho Host que o tor enviará:

curl -s -H 'Host: <your-address>.onion' http://127.0.0.1:8080/

A segunda é que responde nesse endereço e em nenhum outro:

sudo ss -tlnp | grep 8080

A coluna de endereço deve mostrar 127.0.0.1:8080. Se mostrar 0.0.0.0:8080 ou *:8080, o site onion também está disponível na Internet pública. Esse é o primeiro item da lista de fugas. Uma linha listen 8080; sem endereço liga-se a todas as interfaces. Esse é o comportamento predefinido.

Abra o endereço no Tor Browser. O primeiro carregamento demora alguns segundos enquanto o cliente obtém o seu descritor e cria um circuito de rendezvous.

A documentação do próprio Tor Project prefere um socket Unix a uma porta de loopback: HiddenServicePort 80 unix:/var/run/tor/onion_site.sock, com o nginx a escutar nesse caminho. Um socket não pode ser alcançado por outro host, mesmo que o servidor passe posteriormente a ter uma segunda interface. A desvantagem são as permissões do ficheiro, porque o nginx cria o socket e o tor liga-se a ele como debian-tor. Por isso, os dois utilizadores têm de usar um diretório com permissões compatíveis. O loopback com uma saída ss verificada é mais simples de configurar corretamente. É essa a opção assumida no restante deste guia.

Com o site no loopback, o servidor não precisa de nenhuma regra de entrada para ele. Mantenha a porta 22 aberta para si e bloqueie as restantes (os valores predefinidos do ufw que vale a pena configurar num VPS). Lembre-se de que uma firewall não anula um serviço ligado a 0.0.0.0. Apenas filtra os pacotes que chegam à firewall. Os contentores tornam este problema mais evidente, porque a publicação de uma porta Docker escreve regras iptables antes das regras do ufw. Assim, -p 8080:80 coloca o backend onion no IP público, embora o ufw continue a indicar que a porta está bloqueada. Publique as portas dos contentores como -p 127.0.0.1:8080:80.

Os vazamentos que desanonimizam um site onion

O Tor oculta a localização do servidor. Nada no Tor oculta o que o servidor informa. Cada item abaixo é algo que a sua própria stack publica. Ler cada ferramenta de privacidade considerando os seus limites reais, e não a sua reputação, é o mesmo hábito que mostra o que um SearXNG autoalojado oculta, ou seja, o seu IP dos motores de pesquisa e nada mais.

O mesmo site a responder no seu IP público

Este é o caso que apanha muitas pessoas. Os scanners indexam continuamente a resposta HTTP de todos os endereços encaminháveis, e esses resultados são públicos e pesquisáveis. Sirva a mesma página no seu IP público e no seu endereço onion, e associá-los exige apenas uma consulta: o mesmo título, o mesmo hash do favicon, o mesmo ETag e a mesma ordem dos cabeçalhos. A linha listen 127.0.0.1:8080; acima corrige o problema. Verifique a partir de outra máquina, não a partir do servidor:

curl -sv --max-time 5 http://<your-public-ip>:8080/

Connection refused ou um timeout é o resultado correto. Qualquer HTML significa que o site está público. Se a máquina também executar um site clearnet, atribua a esse vhost a sua própria raiz e mantenha um bloco default_server explícito no listener público, para que um cabeçalho Host sem correspondência nunca possa cair no vhost onion.

Banners de versão

curl -sI http://127.0.0.1:8080/ | grep -i '^server'

Uma instalação padrão do nginx responde Server: nginx/1.24.0. Essa cadeia de versão, juntamente com a ordem exata dos outros cabeçalhos, cria uma impressão digital que associa o seu onion ao seu host clearnet. server_tokens off; reduz essa informação a Server: nginx. Isto não remove o cabeçalho, e o nginx não tem uma diretiva integrada para o fazer, portanto o módulo headers-more é a solução habitual se quiser eliminá-lo. O PHP acrescenta X-Powered-By até definir expose_php = Off. etag off; deve entrar na mesma lista, porque o nginx cria o ETag a partir da hora de modificação e do tamanho do ficheiro. Assim, os mesmos ficheiros copiados para dois servidores produzem o mesmo ETag em ambos.

URLs absolutas que apontam para o seu domínio clearnet

Uma tag rel="canonical", um og:url Open Graph, um feed RSS, um sitemap, uma mensagem de reposição de palavra-passe ou uma URL de logótipo definida diretamente no código. Qualquer um deles identifica o site clearnet dentro de uma página servida através do onion. Use caminhos relativos à raiz, como /static/logo.svg, e faça a aplicação ler a sua URL base a partir do host do pedido, em vez de usar uma constante. Os redirecionamentos são o mesmo erro noutro local: return 301 https://example.com$request_uri; num bloco catch-all envia o visitante onion para o seu domínio real, e o cabeçalho Location fornece-lhe diretamente essa resposta.

Um certificado TLS partilhado com o site clearnet

Um endereço onion autentica-se por si próprio, porque o endereço é a chave pública. Por isso, http:// numa ligação onion já é encriptado de ponta a ponta, e o Tor Browser trata-o como um contexto seguro. Instalar o seu certificado existente no vhost onion publica a ligação entre os dois, porque todos os certificados reconhecidos publicamente são registados nos logs de Certificate Transparency, que são públicos, permanentes e pesquisáveis por nome. Mantenha os certificados Let's Encrypt no vhost clearnet e deixe o vhost onion em HTTP simples.

Fontes e analytics de terceiros

Uma fonte de uma CDN (content delivery network) ou um script de analytics. O browser do visitante obtém cada recurso diretamente, por isso o terceiro fica a saber que alguém carregou a sua página e, normalmente, qual página. Além disso, os níveis de segurança mais restritivos do Tor Browser bloqueiam o pedido, deixando um layout danificado. Aloje localmente todos os recursos necessários à página.

Incompatibilidade do cabeçalho Host

Se server_name não corresponder ao cabeçalho Host enviado pelo tor, o nginx recorre ao servidor predefinido para esse endereço de listening. Num sistema com um único vhost, isto passa despercebido, porque o único bloco de servidor também é o predefinido. Se adicionar mais tarde um vhost clearnet, os pedidos onion podem começar a chegar a esse vhost, incluindo as respetivas tags canónicas e redirecionamentos. Execute novamente a verificação curl -H 'Host: ...' depois de cada alteração ao nginx e use grep no resultado para procurar o seu domínio real:

curl -s -H 'Host: <your-address>.onion' http://127.0.0.1:8080/ | grep -o 'https\?://[^"]*' | sort -u

Saber qual processo é proprietário de cada socket constitui grande parte deste trabalho (como funcionam as portas e os sockets em listening no Linux).

O que fica nos logs

Todos os pedidos chegam de 127.0.0.1, por isso o nginx não tem o endereço do visitante para registar, e access_log off; não lhe custa nada. A aplicação acima dele é diferente, porque uma encomenda, um endereço de email ou os metadados de um ficheiro carregado são da sua responsabilidade. Os seus próprios hábitos também contam: administrar a máquina através de um login sem proteção adequada fica fora de tudo o que o Tor protege. Por isso, trate o endurecimento do SSH no mesmo VPS como parte desta implementação.

Faça uma cópia de segurança da chave privada, porque ela é o endereço

/var/lib/tor/onion_site/hs_ed25519_secret_key é o serviço. Não existe registrador nem recuperação. Se a perder, o endereço desaparece. Se a copiar, qualquer pessoa que tenha a cópia pode servir o seu próprio conteúdo no seu endereço, sem que possa revogar nada.

sudo systemctl stop tor@default
sudo tar -C /var/lib/tor -czf onion-keys.tgz onion_site
sudo chmod 600 onion-keys.tgz
sudo systemctl start tor@default

Encripte esse arquivo (gpg -c onion-keys.tgz) e transfira-o para fora do servidor. A restauração num VPS novo consiste no arquivo e na propriedade que o tor espera:

sudo systemctl stop tor@default
sudo tar -C /var/lib/tor -xzf onion-keys.tgz
sudo chown -R debian-tor:debian-tor /var/lib/tor/onion_site
sudo chmod 700 /var/lib/tor/onion_site
sudo systemctl start tor@default
sudo cat /var/lib/tor/onion_site/hostname

O mesmo endereço volta a funcionar no novo hardware um ou dois minutos depois de o tor republicar o descritor. Essa é toda a migração: sem alteração de DNS e sem emitir novamente o certificado.

Onion-Location quando o site também está disponível na clearnet

Se o onion é uma conveniência e não um segredo, anuncie-o no vhost da clearnet:

add_header Onion-Location http://<your-address>.onion$request_uri;

O Tor Browser mostra então um botão .onion available na barra de endereços e oferece a mudança. O cabeçalho só é considerado quando a página da clearnet é servida por HTTPS e o valor é um URL onion válido.

Há uma regra do nginx que pode causar problemas. As diretivas add_header são herdadas por um bloco location apenas quando esse bloco não declara diretivas próprias. Por isso, um location com o seu próprio add_header descarta silenciosamente o Onion-Location. Repita-o nesse bloco ou mantenha todos os cabeçalhos de resposta num único local. Publicar este cabeçalho associa deliberadamente os dois sites. Isso é correto para um espelho e incorreto para qualquer site que deva permanecer sem ligação.

Endereços personalizados

mkp224o gera pares de chaves até que um deles produza um endereço que comece pelo prefixo solicitado. É uma pesquisa por força bruta, portanto não há nada para configurar além do prefixo e do tempo que está disposto a esperar.

sudo apt install -y git gcc libc6-dev libsodium-dev make autoconf
git clone https://github.com/cathugger/mkp224o
cd mkp224o
./autogen.sh
./configure --enable-amd64-51-30k
make
./mkp224o -d onionkeys blog

Cada resultado é colocado em onionkeys/<address>.onion/, que contém hostname e hs_ed25519_secret_key. Instale um parando o tor, copiando esse diretório para HiddenServiceDir e aplicando os mesmos chown e chmod 700 usados no restauro acima.

O comprimento do prefixo determina todo o custo. O endereço usa base32, portanto cada carácter adicional multiplica por 32 o número esperado de chaves. Um prefixo curto é encontrado num portátil. Um prefixo longo não é encontrado em nenhum equipamento que possua. Um prefixo personalizado também leva os leitores a reconhecerem apenas os primeiros caracteres, em vez do endereço completo. É esse o hábito explorado pelas cópias de sites onion usadas em phishing.

Modos de falha e as mensagens que verá

Nenhum ficheiro hostname depois do reinício. O Tor não arrancou ou recusou o diretório. sudo journalctl -u tor@default -n 50 identifica-o:

/var/lib/tor/onion_site/ is not owned by this user (debian-tor, 108) but by root (0). Perhaps you are running Tor as the wrong user?

É assim que se apresenta um diretório criado manualmente. Corrija o proprietário e o modo, ou elimine o diretório e deixe o tor criá-lo.

O Tor Browser mostra Onionsite Not Found (0xF0). O cliente não conseguiu obter um descritor. Para a rede, nada está publicado nesse endereço. Confirme se o tor está em execução e concluiu o bootstrap, compare caractere a caractere o endereço que introduziu com sudo cat /var/lib/tor/onion_site/hostname e depois verifique o relógio. O Tor precisa de uma hora correta para publicar e validar descritores, e timedatectl deve indicar System clock synchronized: yes.

O endereço é resolvido, mas a página nunca carrega. O Tor concluiu o rendezvous e depois falhou no último salto, entre o tor e o nginx. Esse salto é local, por isso o log do tor permanece silencioso. Execute curl -sI http://127.0.0.1:8080/ no servidor. Connection refused significa que o nginx está parado ou está à escuta num endereço diferente daquele para o qual HiddenServicePort aponta.

A página carrega e todas as ligações apontam para o seu domínio real. Existem URLs absolutos nos templates. Execute a verificação grep -o 'https\?://[^"]*' acima e corrija o que ela mostrar antes de partilhar o endereço.

Funciona e depois deixa de funcionar após um reinício. Reinicie o sistema uma vez de propósito antes de depender do site. Depois execute sudo systemctl status tor@default e sudo systemctl status nginx. Um serviço iniciado manualmente parece igual a um serviço ativado até a máquina ser reiniciada.

FAQ

Preciso de abrir uma porta na firewall para um serviço onion do Tor?

Não. O daemon tor estabelece apenas ligações de saída, para os servidores de diretório, para os pontos de introdução e para cada relay de rendezvous. Por isso, não é necessária nenhuma regra de entrada, e o próprio servidor Web escuta em 127.0.0.1. Mantenha o ufw com a política predefinida de negar o tráfego de entrada e permita o SSH. A mesma propriedade permite que um serviço onion funcione numa máquina atrás de NAT (tradução de endereços de rede), mesmo sem qualquer IP público.

Por que não consigo aceder ao meu endereço .onion no Tor Browser?

Comece pelo servidor e verifique cada camada. sudo journalctl -u tor@default -n 50 deve mostrar Bootstrapped 100% (done): Done. Depois, curl -sI http://127.0.0.1:8080/ no servidor deve devolver uma linha de estado. Em seguida, compare o endereço introduzido com o ficheiro hostname, porque um único carácter incorreto corresponde simplesmente a um serviço diferente. Onionsite Not Found (0xF0) significa que não foi encontrado nenhum descritor para o endereço. Normalmente, isto indica que o tor não está em execução ou que o relógio do sistema está incorreto.

Posso mover o meu site onion para um servidor novo e manter o mesmo endereço?

Sim. O endereço é derivado de hs_ed25519_secret_key. Por isso, copie todo o HiddenServiceDir para o novo servidor, defina o proprietário como debian-tor e o modo como 700, e inicie o tor. O endereço volta a estar ativo quando o descritor for republicado. Não existe nenhum registo DNS para atualizar. Se perder esse ficheiro, o endereço não pode ser recuperado. Faça uma cópia de segurança cifrada fora do servidor no dia em que o criar.

Um site onion precisa de um certificado HTTPS?

Não. O endereço com 56 caracteres é a chave pública do serviço. Por isso, a ligação já está cifrada e autenticada de ponta a ponta, e o Tor Browser trata http:// num nome .onion como um contexto seguro. Reutilizar o seu certificado clearnet no vhost onion é pior do que não fazer nada, porque os registos de Certificate Transparency são públicos e registam permanentemente os nomes que partilham um certificado. A única razão para comprar um certificado para um nome .onion é obter uma garantia de marca de uma CA que os emita. Essa ligação é pública por definição.