Anonimato & OPSEC
Freenet e Hyphanet: vulnerabilidades, XSS e privacidade
Falhas documentadas do Freenet histórico, hoje Hyphanet: rastreamento do inseridor, XSS no Fproxy e diagnóstico de roteamento, com modelos locais.
O histórico do Freenet ajuda a entender uma dificuldade central das redes de privacidade: cifrar os dados não elimina todas as informações observáveis. O formato de um bloco, o tempo de encaminhamento, uma resposta de diagnóstico e uma página administrativa podem criar superfícies independentes de ataque. Entre 2025 e 2026, o projeto publicou correções que tornam essa discussão concreta.
Há uma distinção essencial para acompanhar essas falhas. O Freenet histórico é mantido como Hyphanet. O projeto atual chamado Freenet, anteriormente Locutus, possui outra arquitetura. Esta matéria trata das vulnerabilidades e correções do ramo histórico. Não atribui esses defeitos automaticamente ao software novo. A mudança de identidade está explicada no site oficial do Hyphanet e pode ser contrastada com a FAQ do Freenet atual.
Como definir a superfície de teste de uma rede distribuída
Uma auditoria útil começa separando dados armazenados, operações de inserção, roteamento e interface local. A proteção do conteúdo não resolve automaticamente a exposição do publicador. Da mesma forma, uma vulnerabilidade no navegador usado para administrar o nó pode ter consequências diferentes de um defeito no protocolo entre participantes.
Considere uma publicação fictícia com três entidades: quem insere, quem encaminha e quem consulta. O relatório deve especificar qual papel o adversário ocupa, quais informações ele já conhece e se consegue observar uma conexão direta. Sem isso, expressões como desanonimização podem esconder condições importantes do experimento.
Outro cuidado é distinguir uma identidade de rede de uma pessoa. Um nó pode operar em um endereço compartilhado ou em infraestrutura administrada por outra organização. Mesmo quando uma associação técnica é demonstrada, a conclusão sobre autoria humana exige evidência adicional. Essa distinção evita ampliar o impacto além do que o teste comprova.
Datastore e chaves: integridade não equivale a autoria
A documentação técnica do Hyphanet descreve armazenamento distribuído de partes cifradas e diferentes famílias de chave. CHK identifica conteúdo estático; SSK utiliza assinatura; USK facilita acompanhar revisões de publicações; KSK oferece nomes legíveis, com limitações contra disputa de nome e spam. A chave completa de recuperação pode conter material necessário para decifrar o objeto.
Há duas perguntas distintas ao receber uma publicação: o objeto corresponde ao identificador esperado e quem está autorizado a publicar uma atualização? Um hash pode ajudar na primeira propriedade sem oferecer, sozinho, uma política de autoria. Um nome legível também não deve ser tratado como prova de controle exclusivo. O teste deve declarar qual propriedade espera de cada referência.
| Referência | Foco da revisão |
|---|---|
| CHK | Conteúdo esperado e chave completa de recuperação |
| SSK | Assinatura e identidade autorizada |
| USK | Revisão selecionada e confiança na atualização |
| KSK | Ambiguidade do nome e conteúdo inesperado |
Rastreamento do inseridor: correções nos builds 1502 e 1503
O anúncio dos builds 1502 e 1503 descreve uma falha reportada por Xu Yonghuan. Diferenças temporais e na estrutura dos dados permitiam distinguir inserção de encaminhamento. A análise dependia de conexão direta e de conhecimento das chaves dos blocos envolvidos.
Segundo os mantenedores, a correção mitigou integralmente o vetor ativo descrito. Gravações detalhadas anteriores podiam manter utilidade para uma análise passiva retrospectiva. O anúncio também ressalta a diferença do modo puramente friend-to-friend, com amigos confiáveis, para o vetor apresentado. O build 1503 corrigiu uma regressão de threads da primeira mitigação.
O documento não apresenta um identificador CVE para essa falha. Isso não diminui a necessidade de atualização, mas muda a forma de registrar o caso: use o boletim do fabricante, builds afetados quando identificados e a correção correspondente. Inventar um número CVE tornaria o inventário menos confiável.
O que avaliar além do conteúdo de um pacote
Como exercício de revisão, modele uma operação que cria um objeto e outra que apenas o retransmite. Compare tamanho, fragmentação, ordem de envio, persistência em disco e tempo até a próxima resposta. O objetivo é identificar diferenças vinculadas ao papel, sem concluir que cada diferença seja explorável em qualquer topologia.
Uma captura de um único evento raramente resolve a questão. Agendamento do sistema, armazenamento lento e congestionamento também alteram tempos. Um ensaio controlado precisa repetir as duas operações com a mesma carga e registrar variabilidade. A atribuição só deve avançar quando explicações alternativas forem testadas.
XSS no Fproxy: uma fronteira local atingida por conteúdo remoto
Os builds 1504, 1505 e 1506 incluem a correção de um XSS na página de progresso de downloads do Fproxy. O fluxo JavaScript interpretava atualizações com innerHTML e não mantinha o vínculo necessário entre a resposta e a chave esperada. O anúncio identifica o pesquisador bertm e informa a retirada do código JavaScript envolvido.
O GLSA 202608-33 do Gentoo, publicado em agosto de 2026, registra pacotes anteriores a 0.7.5_p1505 como afetados pelo XSS. O anúncio de correção do projeto é de fevereiro; o boletim posterior da distribuição não deve ser apresentado como descoberta de uma nova falha em agosto. Nenhum número CVE específico é listado nesse boletim.
Há duas propriedades a revisar em interfaces semelhantes: a atualização pertence à operação corrente e o valor recebido será apresentado como dado. A primeira envolve associação entre pedido, chave e resposta. A segunda envolve o contexto de renderização. Validar apenas uma delas deixa parte do fluxo sem proteção.
Laboratório local: apresentação literal e escape no contexto HTML
Este modelo original utiliza uma marcação inofensiva e não executa JavaScript. Ele mostra como uma cadeia deixa de ser interpretada como um elemento quando é codificada para o contexto de texto HTML. Não é uma reprodução do payload do Fproxy e não comprova que o programa real esteja corrigido.
from html import escape
from html.parser import HTMLParser
class Leitor(HTMLParser):
def __init__(self):
super().__init__(convert_charrefs=True)
self.texto = []
self.elementos = []
def handle_starttag(self, tag, attrs):
self.elementos.append(tag)
def handle_data(self, data):
self.texto.append(data)
mensagem = "<b>LAB-16</b>"
pagina = "<p>" + escape(mensagem, quote=True) + "</p>"
leitor = Leitor()
leitor.feed(pagina)
assert "b" not in leitor.elementos
assert "".join(leitor.texto) == mensagem
print({"texto_literal": True, "elementos": leitor.elementos})Em uma interface baseada no DOM, atribuir uma mensagem simples a textContent é uma opção quando a finalidade é exibir texto. Templates com HTML permitido exigem um tratamento diferente e uma lista explícita de elementos seguros. Escapar texto HTML não é uma solução universal para atributos, URLs, CSS ou código JavaScript.
A lógica de associação também merece um teste próprio. Um identificador antigo não deve atualizar o painel de uma operação nova. Cancelamento, reconexão e conclusão precisam invalidar callbacks pendentes. Uma boa suíte verifica resposta atrasada, troca de seleção, erro parcial e ausência do objeto esperado, além de exemplos contendo caracteres especiais.
Build 1507: consultas de diagnóstico e privacidade do roteamento
O build 1507, publicado em 13 de setembro de 2026, corrigiu a ausência de aleatorização da localização em consultas de diagnóstico. O problema foi comunicado por Cynthia Blub. A versão também ajustou o tratamento do ruído na fronteira do espaço circular de localização.
Nesse contexto, localização é uma coordenada lógica de roteamento, não uma medição de latitude, longitude ou GPS. O erro não deve ser descrito como vazamento direto da posição geográfica. O anúncio informa ainda que esse é o último build com suporte a Java 8 e prepara a migração para Java 17. Não há CVE atribuída no texto da correção.
Por que a fronteira de um anel merece um teste específico
Em um espaço circular, valores próximos de zero e de um podem ser vizinhos. Tratar essa representação como uma reta produz diferenças artificiais: somar uma pequena perturbação a uma posição próxima do fim pode resultar em um valor fora do intervalo, truncamento ou concentração na borda.
O modelo abaixo é um exercício matemático com amplitude arbitrária. Não reproduz a escolha de distribuição, as conexões ou os parâmetros do Hyphanet. Ele valida somente duas propriedades: resultado dentro do intervalo e distância medida sobre um círculo.
def deslocar(posicao, deslocamento):
if not 0 <= posicao < 1:
raise ValueError("Posicao invalida")
return (posicao + deslocamento) % 1
def distancia_circular(a, b):
diferenca = abs(a - b)
return min(diferenca, 1 - diferenca)
resultado = deslocar(0.99, 0.02)
assert abs(resultado - 0.01) < 1e-12
assert abs(distancia_circular(0.99, resultado) - 0.02) < 1e-12
for posicao in [0, 0.001, 0.5, 0.999]:
for delta in [-0.04, 0, 0.04]:
novo = deslocar(posicao, delta)
assert 0 <= novo < 1
assert distancia_circular(posicao, novo) <= 0.040000001
print("Fronteiras circulares validadas")Adicionar ruído não prova anonimato por si só. É preciso avaliar a distribuição resultante, o que o observador consegue repetir e se existe outra informação que anula a perturbação. Testar apenas se o valor mudou deixa sem resposta a pergunta de segurança: quanto da associação original continua inferível?
Matriz de ameaças e evidências para uma revisão profissional
| Superfície | Propriedade avaliada | Evidência necessária |
|---|---|---|
| Inserção e encaminhamento | Indistinção entre papéis nas condições declaradas | Topologia, carga, versão, medições e controles |
| Página de progresso | Dados permanecem dados e pertencem à operação correta | Resposta sintética, seleção corrente e comportamento do DOM |
| Diagnóstico | Saída não revela diretamente estado privado | Contrato de saída, fronteiras e distribuição observável |
| Atualização | Pacote legítimo e runtime compatível | Canal, assinatura, versão efetiva e resultado da migração |
| Plugins | Capacidades limitadas ao uso necessário | Inventário, permissões, dependências e configuração |
Uma mudança defensiva também pode introduzir falhas de continuidade. O plano de teste deve conferir consumo de threads, descritores, memória e comportamento durante carga prolongada. Essa revisão é especialmente útil em software que permanece funcionando por dias, pois um teste rápido de inicialização não exercita o acúmulo de recursos.
Como verificar uma instalação sem expor a identidade do operador
- Identifique o ramo: confirme que o pacote é do Freenet histórico/Hyphanet e registre o build, em vez de depender somente do nome da pasta.
- Confira o canal: valide a procedência do instalador, mecanismo de assinatura e configuração de atualização. Não confunda espelho de download com autoridade de assinatura.
- Revise o runtime: compare o Java exigido pelo build pretendido com o instalado. Planeje migração e recuperação antes de alterar o serviço.
- Limite a administração: mantenha interfaces locais e plugins administrativos acessíveis somente ao público necessário.
- Defina a topologia: documente quais pares são confiáveis e quais conexões diretas existem. Uma configuração friend-to-friend não elimina todos os riscos da aplicação.
- Teste em isolamento: use arquivos fictícios e modelos locais, sem rastrear participantes ou republicar material de terceiros para medir comportamento.
- Preserve a privacidade do relatório: remova chaves de publicação, endereços de pares e arquivos pessoais que não sejam necessários para demonstrar a propriedade testada.
Registre o que foi efetivamente observado. Uma versão instalada abaixo da correção é uma exposição conhecida; não prova exploração. Um marcador exibido literalmente demonstra uma propriedade daquele componente; não certifica toda a interface. Um processo estável durante uma janela limitada não comprova ausência de vazamento de recursos em qualquer carga.
Perguntas frequentes sobre a segurança do Freenet
Toda falha séria precisa ter um número CVE?
Não. Um projeto pode divulgar uma vulnerabilidade e sua correção sem um identificador CVE. Para acompanhar a exposição, registre o anúncio original, a implementação e os builds relevantes. Não complete o inventário com números encontrados para produtos de nome parecido.
A coordenada de roteamento mostra onde a pessoa está?
A coordenada lógica não representa diretamente uma posição geográfica. Uma eventual atribuição geográfica dependeria de outras fontes e de uma análise separada. Confundir essas duas informações amplia indevidamente a conclusão do diagnóstico.
Esses casos afetam o Freenet novo?
A matéria não demonstra essa transferência. Nome semelhante não torna duas arquiteturas equivalentes. Verifique código, versão e comunicado específico do produto antes de atribuir uma vulnerabilidade.
Conclusão: privacidade também depende da interface e da operação
A revisão de uma rede distribuída ganha precisão quando identifica a fronteira afetada: papel do participante, estado de roteamento ou interface de administração. Isso orienta testes diferentes e evita apresentar toda correção como uma quebra geral de anonimato.
Para o operador, atualizar, revisar plugins e controlar o acesso administrativo são ações mensuráveis. Para o pesquisador, o diferencial é formular uma propriedade, testá-la com controles e documentar seus limites. O resultado deve permitir que outro profissional reproduza a avaliação sem precisar coletar identidades ou informações privadas de uma rede pública.
