Hospede um site .onion num VPS sem denunciar o servidor

Comece pelo que é realmente diferente, porque é mais do que um hostname de aparência estranha. Um site comum depende de uma cadeia de terceiros externos, e um serviço onion simplesmente não tem essa cadeia.

• Sem registrador e sem registro. Um endereço onion v3 é a codificação base32 de uma chave pública ed25519, mais um checksum e um byte de versão — cinquenta e seis caracteres, gerados na sua própria máquina numa fração de segundo. Ninguém vendeu isso para você, então ninguém pode tomá-lo de volta, e não há data de renovação. Isso é o exato oposto do modelo de risco no nosso guia sobre registrar um domínio em privado.
• Sem DNS. Nada resolve um nome .onion. O cliente pede à rede Tor um descritor assinado publicado sob essa chave, então não há resolvedor para envenenar, não há zona para vazar e não há nameserver para derrubar.
• Sem autoridade certificadora. O endereço é a chave pública, então o cliente verifica o serviço contra o nome que digitou. É isso que “autoautenticável” significa: não há terceiro respondendo pela identidade, porque identidade e endereço são o mesmo objeto.
• Sem porta de entrada. O serviço abre circuitos de saída para um punhado de pontos de introdução e espera ali. O seu firewall pode descartar todo pacote de entrada e o site continua funcionando. Nada está escutando num endereço público, então não há nada para escanear, nada para identificar e nada para inundar diretamente.

Uma observação histórica que ainda causa confusão: os antigos endereços de dezesseis caracteres acabaram. O suporte a serviços onion versão 2 foi removido do Tor em outubro de 2021, os endereços não funcionam mais em lugar nenhum, e qualquer coisa que você encontrar descrevendo-os está desatualizada. Tudo abaixo é v3, que é o único tipo que existe.

E seja claro sobre o que nada disso remove. Ainda existe uma máquina física num datacenter, um host que sabe que ela existe, uma conta que alguém pagou, e uma aplicação que pode ser invadida. Serviços onion tiram a camada de endereço do alcance de terceiros. Eles não tiram o servidor.

As pessoas chegam ao Tor querendo fazer uma de quatro coisas bem diferentes, e os perfis de risco não são nem remotamente comparáveis. Vale a pena saber para qual delas você está se inscrevendo.

• Um retransmissor intermediário repassa tráfego criptografado entre outros retransmissores. Ele carrega dados de outras pessoas, mas nunca toca na internet aberta em nome delas, então não atrai reclamações.
• Uma ponte é um ponto de entrada não listado para pessoas cujo acesso ao Tor está bloqueado. Mesmo perfil de tráfego de um retransmissor intermediário, com o endereço mantido fora do diretório público.
• Um retransmissor de saída é onde o tráfego de outras pessoas deixa o Tor e alcança a internet comum, sob o seu endereço IP. Esse é o que gera e-mails de abuso e correspondência jurídica, e precisa de tratamento deliberado — o nosso guia sobre retransmissores Tor cobre isso direito.
• Um serviço onion publica. Ele não carrega tráfego além do próprio, nunca contata a clearweb em nome de ninguém, e portanto não produz nenhum relatório de abuso contra o seu IP. Não há saída, portanto nada sai.

Esse último ponto vale a pena examinar com calma, porque costuma ser mal compreendido. Rodar um serviço onion é, operacionalmente, a coisa mais silenciosa que você pode fazer na rede Tor. O seu servidor faz conexões de saída que parecem tráfego comum de cliente Tor; ele nunca aparece como a origem de uma conexão para o servidor de outra pessoa; e a coisa com que a maioria das pessoas se preocupa — o comportamento de outra pessoa recaindo sobre o seu IP — é estruturalmente impossível.

Você também não precisa rodar um retransmissor para rodar um serviço onion, e é melhor manter os dois separados. Um retransmissor quer largura de banda, uma ORPort pública e um ContactInfo publicado. Um serviço não quer nada disso. Se você quiser fazer os dois, faça-os em dois servidores.

Aqui está a parte em que a documentação oficial é rasa, e a parte que realmente determina se o exercício valeu a pena. O Tor, configurado como abaixo, é extremamente improvável de ser a coisa que denuncia o seu servidor. O software por trás dele, sim, porque esse software foi escrito partindo do princípio de que um servidor web quer ser encontrado.

Estes são os canais, mais ou menos na ordem em que costumam pegar as pessoas:

• O mesmo conteúdo no IP público. Se o seu servidor web também escuta em 0.0.0.0, qualquer um que escaneie a internet vê a página idêntica tanto num endereço IP quanto num endereço onion. Scanners de internet inteira indexam continuamente cada porta aberta, e os resultados são pesquisáveis por hash do corpo e por hash do favicon. Uma única consulta liga os dois. Essa é, de longe, a forma mais comum de um serviço onion ser desmascarado, e é um erro de configuração de uma linha só.
• Banners de servidor e páginas padrão. Uma instalação padrão de nginx ou apache2 responde a hostnames desconhecidos com uma página padrão, imprime a sua versão no cabeçalho Server, e frequentemente revela o hostname real da máquina na saída de erro. Cada uma dessas coisas é uma alça de correlação.
• URLs absolutas. Redirecionamentos, tags canônicas, sitemaps, feeds RSS, tags Open Graph e e-mails de redefinição de senha adoram todos emitir uma URL completa da clearweb. Uma única dessas dentro da versão onion de uma página já basta.
• Requisições de saída que a aplicação faz. Analytics, fontes web, ativos de CDN, serviços de avatar, tiles de mapa, webhooks e verificações de atualização todos se originam do IP real do servidor, e vários deles dizem a um terceiro qual página estava sendo renderizada naquele momento. Um site self-hosted com uma fonte carregada do domínio de outra pessoa tem uma trilha de auditoria que não pretendia ter.
• E-mail. Qualquer coisa que a máquina envie carimba o seu IP real nos cabeçalhos Received. Se o serviço precisa enviar e-mail, isso é um problema de design a ser resolvido deliberadamente — comece pelo nosso guia de servidor de e-mail, e assuma por padrão que ele não deveria enviar nada.
• Chaves e fingerprints reaproveitados. A mesma chave de host SSH respondendo tanto no IP público quanto num endereço onion os liga permanentemente. O mesmo vale para o mesmo certificado TLS, o mesmo favicon, o mesmo identificador de analytics, ou a mesma página de erro característica em dois projetos.
• Certificate Transparency. Se a mesma máquina alguma vez servir um domínio da clearweb por HTTPS, o certificado desse domínio é gravado para sempre em logs públicos e de só-acréscimo. Isso nomeia a máquina, não o onion, mas nomeia a máquina.

O formato comum de todos esses casos é o mesmo: o Tor escondeu o endereço, e outra coisa no servidor o publicou. O passo oito abaixo é uma checklist para encontrá-los antes que outra pessoa o faça.

Antes de instalar qualquer coisa, responda a uma pergunta, porque tudo o que vem depois depende dela: a localização física deste servidor é um segredo que você está tentando manter?

Existem três respostas honestas, e elas levam a construções genuinamente diferentes.

• Sim, a localização é o ponto principal. Então esta máquina faz exatamente um trabalho. Nenhum site na clearweb, nenhum registro DNS público apontando para o seu IP, nenhum e-mail, nenhum outro serviço escutando em lugar nenhum. Pague por ela de um jeito que não associe o seu nome — o nosso passo a passo de Monero cobre a mecânica, e as contas no-KYC significam que não há nada para entregar além de um endereço de entrega. Você mantém a configuração completa de três saltos. Todo atalho abaixo que troca anonimato por velocidade está fechado para você, e tudo bem, porque você não está otimizando para velocidade.
• Não, o servidor já é público. Você roda um site comum e também quer um endereço onion — para leitores sob censura, para pessoas que preferem não resolver o seu domínio, ou porque você gostaria de oferecê-lo. Ninguém está escondendo nada, então você pode usar um serviço onion de salto único, cortar o circuito de seis saltos para três, e anunciar o endereço a partir do site na clearweb com um cabeçalho Onion-Location. Isso é um recurso de alcançabilidade, e é um motivo completamente legítimo para estar aqui.
• Em algum lugar no meio. É aí que a maioria das pessoas realmente está, e é a posição perigosa, porque “meio escondido” não é uma propriedade que um servidor pode ter. Escolha um lado. Se a localização importa de verdade, construa como se importasse. Se não importa, pare de pagar o custo de latência por uma propriedade de anonimato que você não está mantendo.

Anote a resposta antes de continuar. Quase todo erro no assunto deste guia vem de construir para o primeiro caso e operar como se fosse o segundo.

Se a localização do servidor não é um segredo, rodar os dois é simples e genuinamente útil — é assim que grandes organizações de notícias, o Debian e vários mecanismos de busca oferecem os seus sites. Dois mecanismos e uma troca para entender.

Anuncie-o com Onion-Location. Um único cabeçalho no site da clearweb faz o Tor Browser mostrar um botão “.onion disponível” na barra de endereço, e oferecer a troca. O cabeçalho só é respeitado em páginas servidas por HTTPS, e o valor precisa ser uma URL onion válida:

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

Existe um equivalente em HTML para hosts onde você não pode definir cabeçalhos, que tem a mesma exigência de HTTPS:

<meta http-equiv="onion-location" content="http://<your-address>.onion">

Também coloque o endereço em algum lugar que um humano possa ler, no rodapé ou numa página sobre. O cabeçalho só alcança quem já usa o Tor Browser; o rodapé alcança todo o resto.

Considere um serviço onion de salto único. Uma conexão onion normal tem seis saltos — três escolhidos pelo cliente, três pelo serviço — e os três do serviço existem puramente para esconder onde ele está. Se isso não é um segredo, você pode eliminá-los. A melhora de latência é grande e perceptível de imediato. A configuração é abrupta de propósito:

# /etc/tor/torrc — these are INSTANCE-WIDE, not per service
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
SOCKSPort 0

As duas opções são exigidas juntas, a porta SOCKS precisa estar desabilitada, e elas se aplicam a todo serviço onion nessa instância do Tor — não há como isentar um serviço individualmente. O Tor vai se recusar a iniciar se você definir uma sem as outras, o que é o software te fazendo um favor. Se uma única instância hospeda um serviço cuja localização é pública e outro cuja localização não é, rode duas instâncias, ou melhor, dois servidores.

E aceite a troca. Publicar os dois endereços declara que o mesmo operador roda ambos, e servir conteúdo idêntico nos dois os torna trivialmente vinculáveis de qualquer forma. Esse é o acordo, e para um site público não custa nada. Mantenha a higiene mesmo assim: nenhuma URL absoluta da clearweb dentro da versão onion, cookies restritos por host para que uma sessão não viaje entre eles, e uma política de segurança de conteúdo que não puxe ativos de fora.

Por padrão, qualquer um que conheça o seu endereço pode alcançar o serviço. A autorização de cliente muda isso na camada de rede, e não na camada de aplicação, e essa diferença importa mais do que parece.

Com a autorização ativada, o descritor que o seu serviço publica é criptografado para um conjunto de chaves de cliente. Um visitante sem uma dessas chaves não consegue descriptografá-lo, não consegue descobrir os pontos de introdução, e portanto não consegue se conectar de forma alguma — ele não chega a uma página de login, não recebe uma recusa, não recebe nada. O serviço não está apenas não listado; ele é invisível.

Gere um par de chaves x25519 por cliente. Toda ferramenta usada aqui já está numa máquina Debian:

openssl genpkey -algorithm x25519 -out alice.prv.pem

# private key — goes to the client, never to the server
grep -v 'PRIVATE KEY' alice.prv.pem | base64 -d | tail -c 32 | base32 | tr -d '='

# public key — goes on the server
openssl pkey -in alice.prv.pem -pubout | grep -v 'PUBLIC KEY' \
  | base64 -d | tail -c 32 | base32 | tr -d '='

No servidor, coloque a chave pública num diretório authorized_clients dentro do diretório do serviço. O nome do arquivo é arbitrário, desde que termine em .auth, o que faz da revogação uma questão de apagar um único arquivo:

mkdir -p /var/lib/tor/onion-site/authorized_clients
echo "descriptor:x25519:<ALICE-PUBLIC-KEY>" \
  > /var/lib/tor/onion-site/authorized_clients/alice.auth
chown -R debian-tor:debian-tor /var/lib/tor/onion-site
systemctl reload tor@default

No cliente, a chave privada vai no diretório indicado por ClientOnionAuthDir, num arquivo terminado em .auth_private, com o endereço repetido dentro dele. O Tor Browser tem o seu próprio diretório para isso dentro da sua pasta de dados, e vai pedir uma chave se encontrar um serviço que precise de uma:

# /var/lib/tor/onion-auth/mysite.auth_private
<address-without-the-.onion>:descriptor:x25519:<ALICE-PRIVATE-KEY>

Essa é a ferramenta certa para um site de staging, um painel administrativo, um repositório privado de arquivos, ou um Nextcloud self-hosted que só você usa — qualquer coisa em que a resposta honesta para “quem deveria conseguir ver que isso existe?” seja “ninguém além de nós”. O custo é real e é administrativo: você precisa levar as chaves até as pessoas por um canal em que confia, e precisa se lembrar de removê-las depois.

Serviços onion falham de jeitos bem particulares, e nenhum deles parece uma interrupção comum. Quatro coisas valem a pena configurar antes de você precisar delas.

Negação de serviço é o problema operacional de verdade. Como não há endereço IP para filtrar, as defesas de sempre não se aplicam, e uma inundação deliberada de requisições de introdução é barata de enviar. O Tor tem duas respostas, ambas definidas por serviço no torrc: HiddenServiceEnableIntroDoSDefense 1 limita a taxa de requisições nos pontos de introdução, e HiddenServicePoWDefensesEnabled 1 faz os clientes resolverem um pequeno quebra-cabeça de prova de trabalho que fica mais difícil sob carga, de forma que visitantes legítimos esperam um momento enquanto uma inundação se torna cara. Ative as duas desde o início; o custo, quando nada está te atacando, é insignificante.

Mantenha o relógio certo. Descritores são publicados e consultados contra períodos de tempo derivados de um valor compartilhado da rede. Um servidor cujo relógio desviou muito publica no lugar errado e se torna inalcançável, enquanto parece perfeitamente saudável nos seus próprios logs. Garanta que um cliente NTP esteja rodando, mantenha a máquina em UTC, e verifique isso quando um serviço misteriosamente parar de resolver.

O monitoramento precisa passar pelo Tor. Nenhum serviço comercial de uptime consegue sondar um endereço .onion, o que significa que a resposta de sempre não está disponível para você. Rode a verificação você mesmo, a partir de uma segunda máquina que não seja a que hospeda o serviço — um cron job rodando torsocks curl -s --max-time 60 contra uma URL conhecida, comparando a saída com uma string conhecida, já basta e não custa nada.

Planeje mais de uma instância se o uptime importa. O OnionBalance permite que vários servidores de backend compartilhem um único endereço onion: uma instância front-end guarda a chave dona do endereço e publica um descritor apontando para os pontos de introdução dos backends, então você ganha distribuição de carga e failover sem o endereço jamais mudar. São mais peças móveis do que a maioria dos sites precisa, mas é a resposta suportada oficialmente, e vale saber que ela existe antes de você se encurralar numa única máquina.

Um último hábito operacional: reiniciar o Tor deixa o serviço offline por alguns segundos enquanto ele republica, e uma reinstalação que apaga /var/lib/tor o deixa offline para sempre. Trate esse diretório do jeito que trataria uma chave privada, porque é isso que ele é.

Um endereço onion remove o registrador, o resolvedor, a autoridade certificadora e a porta aberta. Ele não remove mais nada, e ser preciso sobre o que resta é o que separa uma ferramenta útil de uma falsa sensação de segurança.

Ele não corrige a aplicação. Uma aplicação web vulnerável por trás de um serviço onion é uma aplicação web vulnerável; a primeira coisa que muitos atacantes fazem depois de conseguir execução de código é fazer uma requisição de saída que revela o endereço real do servidor. Dê à máquina os dez minutos do nosso guia de hardening do Debian, mantenha-a corrigida, e trate-a como exposta mesmo que nada esteja escutando.

Ele não esconde o servidor de quem o administra. Nós sabemos que um servidor existe, quando foi implantado, e qual é o seu endereço IP, porque fomos nós que o alocamos. Isso é verdade para todo host, em qualquer lugar, e quem te disser o contrário está vendendo alguma coisa. O que podemos dizer com precisão é o que fazemos com isso, que está descrito no nosso relato honesto do que um VPS pago em cripto esconde.

Ele não derrota sozinho um adversário paciente e bem financiado. O volume e o timing do tráfego são visíveis nas bordas da rede, e um serviço que fica quieto sempre que uma pessoa específica está dormindo está te dizendo algo. Também não ajuda se o conteúdo te identifica: o mesmo estilo de escrita, a mesma chave PGP, o mesmo avatar ou o mesmo apelido de fórum usado como identidade pública fecha o ciclo, não importa quão bom seja o transporte.

Do nosso próprio lado, para você se calibrar: serviços onion são bem-vindos em todos os planos e não precisam de nada especial da nossa parte, porque não abrem portas nem geram tráfego de abuso. Rodamos contas no-KYC que precisam apenas de um endereço para entregar as credenciais. Tratamos a correspondência de direitos autorais de rotina como uma questão operacional, e não como uma remoção automática, agimos sobre ordens judiciais válidas na jurisdição em que o servidor está, e o piso rígido é absoluto e se aplica aqui exatamente como em qualquer outro lugar: sem CSAM, sem conteúdo de terrorismo, sem exceções. Leia a política de uso aceitável e como tratamos relatórios de abuso antes de construir algo que você lamentaria ter que mudar de lugar. A nossa página de VPS amigável a Tor tem a orientação de planos.