Famílias de relays declaradas: por que a construção de caminhos do Tor evita circuitos do mesmo operador
Durante a maior parte da sua história, operar mais de um relay do Tor envolveu um pequeno dever administrativo: uma linha MyFamily em cada torrc, listando as impressões digitais de todos os outros relays sob o mesmo operador. Esse mecanismo deixou a rede, e operadores com vários relays declaram agora suas famílias com um sucessor baseado em chaves. O motivo da opção não mudou, e vale repeti-lo para quem adiciona um segundo relay hoje.
Para que serve uma declaração de família
Uma família de relays é um conjunto de relays sob o mesmo controle administrativo: uma pessoa, uma organização ou um host executando várias instâncias do tor. A declaração existe para a construção de caminhos. Os clientes do Tor evitam colocar dois membros da mesma família em um mesmo circuito, porque um circuito cuja entrada e saída respondem à mesma parte é exatamente o cenário de um ataque de correlação ponta a ponta: a entrada vê o cliente, a saída vê o destino, e um único operador com as duas visões pode cruzá-las.Quando dois relays declaram que pertencem à mesma 'família', os clientes do Tor não os usarão no mesmo circuito.A documentação da comunidade descreve a opção sucessora da mesma forma: a FamilyID, diz o texto, simplesmente informa aos clientes do Tor quais relays são controlados por uma única entidade, operador ou organização, para que relays do mesmo operador não sejam usados em várias posições de um circuito. Sem esse sinal, a seleção de caminhos trata relays aparentados como estranhos.
Quando os operadores esquecem de declarar
O desenho antigo dependia inteiramente de os operadores manterem o registro em cada relay e mantê-lo sincronizado. Um grupo que compartilha o operador mas não declara nada é invisível para a seleção de caminhos: a rede conta seus relays como participantes independentes. Isso distorce as estatísticas de diversidade usadas para descrever a rede e reduz a proteção que os clientes realmente recebem, porque a regra do cliente para exatamente na fronteira do que está declarado. O projeto OrNetStats, do pesquisador de relays veterano nusenu, acompanha o tema há anos. Ele agrupa relays em famílias efetivas - relays com uma configuração de MyFamily mútua - e entre suas perguntas permanentes estão quais grupos de relays têm possíveis configurações incorretas do MyFamily e quais representam risco de correlação ponta a ponta para os usuários do Tor. O relatório dedicado lista operadores apenas quando a combinação é realista: probabilidade de guard e de exit acima de zero, família não configurada corretamente e relays espalhados por mais de um bloco de rede /16 - ou seja, grupos que de fato poderiam segurar as duas pontas de um circuito. Uma vez configurada a família, nota o relatório, os relays somem da página em um ou dois dias. As informações de contato fazem parte da mesma história. A ContactInfo é uma cadeia sem autenticação, e o OrNetStats observa que isso permitiu personificar outros operadores de relays, algo que, segundo o projeto, já foi explorado na prática. Por isso ele exibe, quando disponíveis, identificadores autenticados de operador (AROI), que ligam os dados de contato a um controle de DNS ou de servidor web que o operador precisa realmente ter.De MyFamily a Happy Families
O mecanismo antigo também escalava mal. Cada relay precisava listar todos os outros membros, e cada mudança exigia atualizar a configuração de todos. A proposta 321, escrita por Nick Mathewson em maio de 2020, colocou um número no custo: segundo sua medição de fevereiro de 2025, as declarações de família somavam mais de 55 por cento do conteúdo dos microdescritores, e adicionar ou remover um servidor exigia mudar o torrc de todos os demais. Um pedido de comentários de novembro de 2021 sobre uma forma mais fácil de declarar famílias recebeu respostas de operadores, incluindo nusenu, e o desenho resultante preserva a propriedade de segurança mudando a mecânica: o operador gera uma vez uma chave de assinatura da família, entrega a chave a cada relay da família e define a opção FamilyId. A pertença é comprovada por certificados nos descritores, e as autoridades de diretório publicam linhas family-ids compactas em vez de listas de impressões quadráticas. O guia da comunidade chama o desenho de Happy Families; ele está implementado na série Tor 0.4.9 e no Arti 1.4.1. A transição se encerrou em 2026. A série 0.4.8 - a última a exigir MyFamily junto ao novo mecanismo - chegou ao fim da vida em 1º de junho, e 1º de setembro ficou definido como a data a partir da qual clientes 0.4.8 e anteriores não seriam mais mantidos funcionando na rede, com as antigas linhas de família obsoletas para economizar banda de diretório. O portal da comunidade afirma hoje que o MyFamily foi removido e direciona operadores de vários relays à FamilyID e a uma ContactInfo válida. As ferramentas seguiram: o papel ansible-relayor removeu o suporte a MyFamily em sua versão de junho de 2026, observando que todas as versões do tor suportadas falam o novo desenho.Orientações práticas para operadores de vários relays
- Execute uma versão do tor suportada em cada relay; a rede não carrega mais as antigas linhas de família.
- Gere uma chave de família com tor --keygen-family, copie o arquivo de chave para o KeyDir de cada relay, adicione uma linha FamilyId ao torrc e recarregue.
- Rotacione chaves em etapas: implante a nova FamilyId junto à antiga, espere alguns dias pela propagação e remova a linha antiga.
- Defina uma ContactInfo funcional - sempre exigida de operadores com vários relays - e considere publicar um AROI para que a identidade do operador não possa ser falsificada.
- Confira como a rede o vê: as páginas de famílias do OrNetStats e o relatório de correlação ponta a ponta mostram se seus relays estão agrupados corretamente.