Como hospedar um site .onion: serviços onion, endereços v3 e os vazamentos que desmascaram

O que é, de fato, um serviço onion

Um serviço onion é um servidor que nunca conta a ninguém onde está. Em vez de publicar um endereço no DNS e esperar por conexões, ele constrói circuitos de saída pela rede Tor até um punhado de relés que escolhe como pontos de introdução, e publica um descritor assinado dizendo "quem tiver esta chave pode ser contatado através destes relés". Um cliente que conhece o endereço busca esse descritor, escolhe um terceiro relé como ponto de encontro, e pede a um ponto de introdução que repasse um pedido para se encontrarem ali. Os dois lados constroem seu próprio circuito até o ponto de encontro, e nenhum dos dois chega a saber o endereço IP do outro, porque nenhum dos dois é informado dele.

O endereço em si é a parte interessante. Um endereço onion v3 tem 56 caracteres em base32 seguidos de .onion, e não é um nome que aponta para uma chave — ele é a chave: uma chave pública ed25519, um checksum e um byte de versão, codificados. Não há nada para consultar e nada para confiar. Quando seu cliente se conecta, o descritor que ele busca está assinado por essa mesma chave, de modo que o endereço autentica o serviço por construção. Nenhuma autoridade certificadora está envolvida, ninguém pode emitir um certificado para o seu endereço, e não existe log de transparência registrando que o serviço existe. A especificação do rendezvous vale a leitura se você quiser o handshake completo.

Essa lista é toda a proposta de valor, e ela explica a mistura de gente que roda esses serviços. As instâncias do SecureDrop em redações são serviços onion porque uma fonte não deveria precisar confiar no DNS. O Debian espelha seu arquivo através de serviços onion para que o ato de atualizar um pacote não fique visível como destino. Várias plataformas de consumo muito grandes publicam um endereço onion para que pessoas em redes censuradas possam alcançá-las sem um IP bloqueado no meio do caminho. Nada disso é exótico; é um transporte com um conjunto diferente de garantias.

O que ele protege — e a parte que não protege

A garantia do protocolo é estreita e forte: a camada de rede não revela onde o serviço roda. Um adversário capaz de observar grandes partes da internet ainda assim não consegue resolver seu endereço para uma máquina, porque não existe etapa de resolução para observar. Um provedor de hospedagem não pode receber o endereço e ser perguntado a qual cliente ele pertence, porque nada do lado do provedor sabe disso. Scanners não conseguem encontrar o serviço, porque ele não responde em nenhuma porta pública. E um ataque que tiraria um site comum do ar não tem onde mirar, o que explica por que o padrão aparece tanto em conversas sobre DDoS quanto sobre privacidade.

Tudo acima da camada de rede ainda é seu para errar, e é aí que mora a história real. Serviços já foram localizados porque a aplicação imprimiu um stack trace contendo um hostname real, porque o mesmo servidor web respondia no IP público com uma página idêntica, porque um certificado de outro domínio do operador estava instalado na mesma máquina, porque uma imagem carregava coordenadas GPS nos metadados, porque a máquina enviou e-mail que atravessou a internet aberta, ou porque um endpoint de status deixado aberto ao mundo listava o próprio endereço do servidor. O Tor cumpriu sua parte em todos esses casos. Quem estava por cima dele, não.

Então segure duas ideias ao mesmo tempo. O transporte é sólido e já é assim há anos; tratá-lo como o elo fraco é uma leitura equivocada de como essas investigações realmente aconteceram. E o transporte também é a metade fácil — a metade difícil é a disciplina sobre tudo o que a máquina diz e faz, que é sobre o que trata a maior parte do resto deste guia. Se o motivo de você estar aqui é uma pergunta mais ampla sobre o quão rastreável é um servidor alugado, a versão honesta dessa resposta é uma boa companhia para esta página.

Colocando um no ar: duas diretivas e um reinício

A configuração é genuinamente pequena, o que surpreende quem espera algo cerimonial. Instale o daemon tor, depois acrescente duas diretivas ao torrc: uma HiddenServiceDir nomeando um diretório que o Tor vai criar e possuir, e uma HiddenServicePort mapeando a porta virtual que os visitantes vão usar para o endereço local em que sua aplicação está escutando. Reinicie, e o Tor gera um par de chaves ed25519 e grava seu endereço em um arquivo hostname dentro desse diretório.

O erro mais comum de todos está na terceira linha. Uma instalação padrão de servidor web escuta em 0.0.0.0, o que significa o endereço IPv4 público e, geralmente, o IPv6 também. Coloque um serviço onion na frente disso e você passa a servir os mesmos bytes em dois lugares, um dos quais é indexado por todo scanner da internet. Qualquer um que compare um hash de página, um favicon, um ETag ou uma página de erro característica liga os dois em segundos. Vincule-se a 127.0.0.1 e depois confirme com ss -ltnp em vez de simplesmente presumir — a confirmação leva cinco segundos, e a suposição já custou tudo a muita gente.

Faça backup de hs_ed25519_secret_key em algum lugar criptografado e fora da máquina antes de ir adiante. Esse arquivo não está associado ao endereço; ele é o endereço. Perca-o e o endereço desaparece para sempre, sem recuperação e sem recurso. Vaze-o e qualquer outra pessoa pode colocar no ar um serviço que responde pelo seu endereço e é criptograficamente indistinguível de você. Trate-o como uma chave de assinatura, porque é exatamente isso que ele é — e, se o disco onde ele mora é alugado, criptografar esse disco é o passo complementar óbvio, com as ressalvas que aquele guia expõe.

Depois, feche a porta da frente. Um serviço onion não precisa de nenhuma porta de entrada — toda conexão que ele usa foi aberta por ele mesmo, de saída, para dentro da rede Tor. Você pode descartar todo o tráfego de entrada no firewall e o serviço continua funcionando perfeitamente. Quase nada mais do que você pode hospedar oferece isso, e isso elimina toda uma categoria de ataques que começam com uma varredura de portas. Acesse também sua própria administração através do Tor, e a máquina simplesmente para de responder à internet.

Endereços v3, prefixos personalizados e o problema de phishing que eles criam

Se um tutorial que você está lendo menciona endereços de 16 caracteres, ele está descrevendo um protocolo que não existe mais. Os serviços onion versão 2 usavam hashes RSA-1024 de 80 bits, curtos o suficiente para serem atraentes e fracos o suficiente para serem um problema; também eram enumeráveis, porque qualquer um rodando um relé de diretório podia colher os endereços que passavam por ele. O Tor Project anunciou o cronograma de descontinuação em 2020, desativou a v2 na série 0.4.6 em julho de 2021, e removeu o código por completo naquele outubro. Os endereços versão 3 têm 56 caracteres, são construídos sobre ed25519 e não vazam mais através de relés de diretório.

O comprimento é o preço disso, e é por isso que existem endereços personalizados. Ferramentas como o mkp224o geram pares de chaves em massa e guardam aqueles cujo endereço começa com um prefixo escolhido. Isso não enfraquece nada: você não está restringindo a chave, está descartando candidatas até uma acabar codificando as letras que você queria, e a sobrevivente é exatamente tão forte quanto qualquer outra. O que isso custa é tempo, e o custo é exponencial — cada caractere adicional multiplica o trabalho por 32, de modo que um prefixo de quatro caracteres é instantâneo em um notebook, seis ou sete caracteres é uma máquina rodando por horas, e dez se torna um empreendimento sério. Ninguém faz força bruta em um endereço completo de 56 caracteres; o espaço de busca é exatamente o ponto.

O verdadeiro perigo é o espelho do recurso. Se um prefixo reconhecível ajuda seus usuários a te identificar, ele também ajuda outra pessoa a gerar um quase-igual e colocá-lo numa página de phishing, porque os oito caracteres que um humano de fato lê são a única parte que ele confere. Defenda-o como fingerprints de chave sempre foram defendidos: publique o endereço completo em vários lugares independentes, assine-o com uma chave que as pessoas já possuam, coloque-o no cabeçalho Onion-Location do seu site clearnet, se tiver um, e diga em voz alta que você nunca vai anunciar um endereço novo apenas nas redes sociais. Um prefixo personalizado é um recurso de usabilidade, não de autenticação.

A superfície de vazamento que já desmascarou serviços de verdade

Esta é a seção que importa. O padrão em todo caso publicamente documentado é o mesmo: a camada de rede se manteve firme, e algo acima dela apontou para uma máquina específica, uma pessoa específica ou outra propriedade específica. A maioria desses casos é banal, todos são verificáveis em uma tarde, e verificar é o trabalho.

Dois desses merecem destaque porque pegam até gente cuidadosa. O primeiro é o tráfego de saída: uma máquina que nunca aceita uma conexão ainda pode se denunciar ao fazer uma. Atualizações de pacotes são normais e inevitáveis; um agente de monitoramento que reporta a um painel ligado ao seu nome não é, e nem uma aplicação que envia e-mail de redefinição de senha pela internet aberta a partir de uma máquina cujo propósito inteiro é não ser localizada. O segundo é a chave de host SSH. Reaproveitá-la entre máquinas é um hábito que parece organizado e cria um vínculo criptográfico permanente e pesquisável entre dois servidores que deveriam ser independentes.

Faça a auditoria como um estranho, não como o operador. Abra o serviço no Tor Browser em uma máquina que nunca teve contato com o projeto, leia cada cabeçalho de resposta, provoque um erro deliberadamente, veja o código-fonte de uma página que você não escreveu você mesmo, e observe o painel de rede em busca de qualquer coisa que a página busque em outro lugar. Depois, sente-se no servidor e observe o que sai dele durante um dia inteiro. O que você encontrar nesse dia é todo o sentido deste guia.

Autorização de clientes: um serviço que só algumas pessoas conseguem alcançar

Existe um modo que a maioria das pessoas não sabe que existe, e é a coisa mais elegante do protocolo. Com a autorização de clientes, o descritor que seu serviço publica é criptografado para um conjunto de chaves públicas x25519 que você indica. Um cliente sem a chave privada correspondente nem consegue descriptografar o descritor, o que significa que não consegue conhecer os pontos de introdução, o que significa que não consegue se conectar — e nem sequer consegue confirmar que existe alguma coisa ali. Você coloca as chaves públicas dos clientes em um diretório authorized_clients ao lado das chaves do serviço, um arquivo por cliente, e reinicia.

Compare isso com as formas usuais de restringir acesso. Uma allowlist de IPs exige saber onde estão seus usuários e deixa um serviço respondendo à internet para todo mundo mais escanear e identificar. A autenticação básica HTTP deixa uma tela de login parada ali, anunciando que algo existe. Uma VPN acrescenta um sistema inteiro a mais para rodar, com seu próprio endereço a expor. A autorização de clientes remove o serviço da vista de todo mundo que não está na lista, o que é uma propriedade categoricamente diferente: não uma porta trancada, mas a ausência de uma porta.

O encaixe natural são as superfícies administrativas. Coloque o site público em um serviço onion comum e o painel de administração, o painel de métricas, o console do banco de dados e o ponto de entrada SSH atrás de serviços autorizados separados, e as partes da sua implantação que de outra forma seriam sondadas continuamente simplesmente não podem ser encontradas. O custo é a distribuição de chaves — cada cliente precisa da sua chave privada instalada na configuração do Tor — o que é tranquilo para um punhado de operadores e impraticável para um público amplo. Use-a onde o público é contável.

Latência, redundância e as trocas honestas

Uma conexão onion atravessa seis relés: três escolhidos pelo cliente e três escolhidos pelo serviço, encontrando-se no meio do caminho. Esse é o preço de nenhum dos lados conhecer o outro, e ele aparece como latência, não como largura de banda — o primeiro byte é lento, a taxa de transferência depois costuma ser tranquila. Projete em torno disso: menos idas e voltas, cache agressivo, nenhuma cadeia de requisições tagarela, nenhuma página que precise de onze sub-recursos antes de renderizar. Um site que é agradável sobre um serviço onion costuma ser um site que já era bem construído desde o início.

Se o seu serviço não precisa, por si só, de anonimato de localização — uma grande plataforma pública que publica um endereço onion apenas para que usuários censurados consigam alcançá-la, por exemplo — o Tor oferece um modo de serviço onion único que usa um caminho de um único salto do lado do serviço. Ele reduz a latência praticamente pela metade e abre mão explicitamente do próprio anonimato do serviço, e o nome da diretiva de configuração diz isso quase literalmente. É a resposta certa para uma organização conhecida e exatamente a resposta errada para quem tem a própria localização como a coisa a ser protegida. Escolha-o de forma deliberada, ou não o escolha de jeito nenhum.

A redundância merece uma nota porque a abordagem ingênua falha. Você não pode simplesmente copiar o material de chaves para uma segunda máquina e rodar as duas — dois serviços publicando descritores para o mesmo endereço brigam pelo diretório e os clientes caem de forma imprevisível. O OnionBalance existe exatamente para isso: uma instância de front-end detém o endereço público e publica um descritor apontando para os pontos de introdução de vários serviços de backend, cada um com sua própria chave. Os backends podem ser reconstruídos ou movidos um de cada vez sem que o endereço jamais mude.

Rodando um serviço onion junto com um site comum

Muitos serviços onion são segundas portas da frente para algo que já existe publicamente, e isso é um projeto diferente de um serviço cuja localização é secreta. Decida qual dos dois você está construindo antes de escrever qualquer configuração, porque os dois querem coisas opostas. Se o objetivo é resistência à censura para um site que todo mundo já sabe que você roda, ligar os dois é o recurso desejado: publique um cabeçalho Onion-Location no site clearnet e o Tor Browser vai oferecer o endereço onion aos visitantes automaticamente. Se o objetivo é que ninguém saiba onde o serviço roda, então cada ligação entre os dois é um vazamento, e o número correto delas é zero.

É a meia-medida que machuca as pessoas. Rodar os dois a partir de uma única máquina, com um único banco de dados, um único domínio de cookie de sessão e um único conjunto de arquivos enviados, enquanto você diz a si mesmo que os dois públicos são separados, significa que uma única configuração errada colapsa a distinção — e você só vai descobrir quando outra pessoa descobrir primeiro. Se os dois precisam existir e não podem estar ligados, eles são duas implantações em duas máquinas com dois conjuntos de credenciais, e o custo operacional disso é o preço da propriedade que você queria.

Um detalhe prático caso você opte por ligá-los: mantenha sessões e cookies restritos por host. Um usuário que faz login no site clearnet e depois chega pelo endereço onion deveria receber uma sessão nova, não uma compartilhada, ou você terá construído um mecanismo que correlaciona as duas visitas para qualquer um que consiga ver uma das duas. E sirva ao endereço onion seus próprios links canônicos, para que o site não acabe redirecionando um usuário do Tor Browser de volta para o host clearnet que ele deliberadamente evitou.

O que a hospedagem realmente precisa acertar

Os requisitos são incomuns, e é por isso que uma hospedagem genérica costuma ser um mau encaixe. Você precisa de um caminho de saída desimpedido para a rede Tor, porque é o único tipo de conexão que seu serviço faz; alguns provedores filtram completamente o tráfego de diretório e de relés do Tor, e você vai descobrir isso na forma de um serviço que nunca publica um descritor. Você precisa de um provedor cuja política de uso aceitável trate o Tor por escrito, e não pelo silêncio, porque silêncio é o que vira um e-mail de encerramento na primeira vez que alguém reclamar de algo sem relação nenhuma. Você não precisa de um IP estável, de um domínio, de um certificado, nem de nenhuma porta de entrada — o que significa que a maior parte do que as empresas de hospedagem vendem como diferencial é irrelevante aqui.

O perfil de abuso é a surpresa agradável. Um nó de saída (exit) faz conexões para a internet aberta em nome de estranhos e, por isso, coleciona reclamações; esse é o trato, e é por isso que exits precisam de um provedor com uma postura documentada. Um serviço onion faz o oposto: toda conexão vem de dentro da rede Tor, ele nunca contata a internet aberta em nome de ninguém e, como consequência, praticamente não gera e-mail de abuso algum. É uma carga bem mais tranquila de hospedar do que o relé ao lado dele, e muito mais tranquila do que um servidor web público.

Na BitVPS, o Tor é permitido por escrito — relés, bridges, exits e serviços onion, todos igualmente, com o caso dos exits documentado na página de abuso em vez de deixado ao acaso. A página de hospedagem Tor cobre o dimensionamento de relés; serviços onion são mais leves. Na prática, um Growth a $13.50 com 4 vCPU, 8 GB de RAM e um uplink sem limite de tráfego roda um serviço onion sério com espaço de sobra para a aplicação por trás dele, e um Starter a $8.50 é suficiente para um pequeno. Escolha a localização pela sua postura legal, não pela latência: seis saltos tornam a diferença entre um datacenter próximo e um distante quase imperceptível.

A página de rede publica o ASN e o peering, o que importa aqui por um motivo indireto. Você não está expondo um endereço, então o motivo usual para se preocupar com a rede de um provedor desaparece — mas uma hospedagem que documenta sua infraestrutura publicamente também é uma hospedagem que já registrou por escrito o que faz quando alguém pergunta sobre um cliente, e é isso que você está realmente comprando.

Onde fica o limite

Vale ser direto sobre isso, porque a tecnologia carrega uma reputação que não bate com o tráfego real. Serviços onion são um transporte com uma propriedade de privacidade específica, e as pessoas que os rodam são, na esmagadora maioria, gente comum: redações recebendo denúncias, um arquivo de pacotes que não quer registrar qual máquina buscou qual atualização, projetos de mensageria e de autohospedagem, pessoas em países onde a internet comum é filtrada, e administradores que simplesmente preferem que sua interface de gerenciamento não seja varrível por scanners. Rodar um serviço onion é legal na grande maioria das jurisdições, e isso não é uma declaração sobre o que você está hospedando.

O que isso não é é uma mudança nas regras do jogo. Um provedor que ignora notificações de direitos autorais — e nós ignoramos, como aquele guia explica — ainda assim age contra material de abuso sexual infantil e ameaças críveis a pessoas, e age rápido: nossa janela publicada é de quatro horas para esses casos, contra quarenta e oito para todo o resto. Isso não é uma brecha em uma política por outro lado permissiva, é a política em si, e nenhum transporte muda isso. A política de uso aceitável é curta e vale a pena ler antes de construir, não depois.

A outra nota honesta é que anonimato é uma propriedade de sistema, não um produto que se compra. O endereço esconde a máquina; ele não esconde um rastro de pagamento, uma senha reaproveitada, um estilo de escrita, um domínio que você registrou anos atrás com o mesmo e-mail, ou um print de tela com os caminhos do seu próprio sistema de arquivos nele. Se o modelo de ameaça é sério, o transporte é a parte mais fácil dele, e a parte em que você vai gastar menos tempo. O passo a passo mais amplo cobre o resto dessa cadeia, e o explicador sobre bulletproof hosting é um antídoto útil para o marketing que cerca todo esse assunto.