Projeto Tor está migrando para Rust

 (itsfoss.com)
4 pontos por GN⁺ 2025-12-14 | 2 comentários | Compartilhar no WhatsApp
  • O código central da rede Tor está sendo migrado da linguagem C para o Arti, baseado em Rust
  • O código existente em C tem vulnerabilidades como buffer overflow, use-after-free e corrupção de memória
  • A nova versão Arti 1.8.0 remove padrões previsíveis e reduz o risco de rastreamento por meio de uma reformulação do timeout de circuitos
  • Foi adicionado um novo comando para que operadores de serviços onion possam migrar chaves automaticamente do Tor baseado em C para o Arti
  • Esta transição é um importante avanço técnico do projeto Tor para melhorar segurança e estabilidade

Principais mudanças no Arti 1.8.0

  • O destaque desta versão é a aplicação da reformulação do timeout de circuitos (circuit timeout rework)

    • No Tor anterior, o Circuit Dirty Timeout (CDT) controlava o momento de encerramento do circuito com um único temporizador
    • Esse método era previsível, permitindo que observadores de tráfego identificassem padrões
    • O Arti 1.8.0 introduz timeouts baseados em uso e temporizadores individuais, fazendo com que os circuitos sejam encerrados em momentos aleatórios quando aceitam novas conexões ou ficam ociosos
    • Isso reduz o risco de fingerprinting

  • Adição do novo comando experimental arti hsc ctor-migrate

    • Operadores de serviços onion podem migrar restricted discovery keys do Tor baseado em C para o keystore do Arti
    • Essas chaves são usadas para autenticação de clientes, e o novo comando permite a migração automática sem trabalho manual

  • Melhorias adicionais

    • Vários componentes internos foram aprimorados, como a arquitetura de roteamento, a implementação de protocolos, o suporte a cache de diretório e a configuração do listener da porta OR
    • Os detalhes completos das mudanças podem ser consultados no changelog oficial do Arti 1.8.0

Contexto da migração para Rust

  • A rede Tor é operada com base na linguagem C desde o início dos anos 2000
  • Porém, a base de código em C tem gerado vulnerabilidades de segurança de forma contínua devido a problemas de segurança de memória
  • Por isso, o projeto Tor está promovendo o projeto de reescrita Arti, aproveitando a segurança de memória do Rust
  • O Arti reimplementa as funcionalidades do Tor em Rust com o objetivo de reforçar segurança, estabilidade e manutenção

Significado técnico

  • A migração para Rust aponta para um fortalecimento fundamental da estrutura de garantia de anonimato do Tor
  • A eliminação de comportamentos previsíveis dos circuitos e a automação do gerenciamento de chaves contribuem para elevar o nível de proteção da privacidade dos usuários
  • As atualizações contínuas do Arti são vistas como um sinal de aceleração da substituição gradual do Tor baseado em C

Leituras relacionadas

2 comentários

 
GN⁺ 2025-12-14
Comentários do Hacker News

  • Recentemente fiz o teste do EFF Cover Your Tracks e só o Tor Browser com o JS desativado apareceu como totalmente resistente a fingerprinting
    Até mesmo o Tor com JS ativado foi avaliado como apenas “parcialmente” resistente, e no Firefox o resultado nem aparecia mesmo com JS desativado. Foi um resultado bem assustador, então fiquei curioso com os testes de outras pessoas

    • Essa ferramenta tem falhas na forma de medir proteção contra fingerprinting. Ela acaba dando nota pior para proteções que usam randomização e nota melhor apenas para abordagens de binning.
      Por outro lado, ferramentas como fingerprinting.com/demo, que testam só persistência, também têm problema.
      O verdadeiro sinal de risco é falhar nos dois testes
    • Quando testei no Safari do macOS, recebi o resultado de “forte proteção contra rastreamento na web”.
      Ainda assim, embora o Tor Browser certamente se destaque, é difícil concluir por esse teste sozinho que seja fácil distinguir fingerprints entre usuários do Tor
    • O Tor Browser tenta ampliar os buckets de fingerprint com técnicas como arredondamento do tamanho do canvas. No fim, o maior bucket inevitável é o de “usuários do Tor” em si
    • Quando testei no Debian com o Tor Browser na configuração padrão, obtive 8,24 bits de informação identificável.
      Quanto mais eu aumentava o nível de segurança, mais os bits de identificação subiam, mas ao desativar totalmente o JS eles voltavam a cair.
      Ou seja, desativar o JS oferece o maior anonimato

  • Seria bom se a Mozilla tivesse levado mais adiante a transição para Rust (oxidizing) no Firefox. Isso também teria sido positivo para o ecossistema Rust

    • Ainda assim, a equipe do Chrome continua avançando com a adoção de Rust
    • Mesmo depois de a Mozilla ter demitido em massa desenvolvedores de Rust, a proporção de Rust no código do Firefox passou de 12%. No Chromium, é menos de 4%, então relativamente pouco
      Se Rust tivesse permanecido como a “arma secreta” da Mozilla, talvez sua adoção tivesse até demorado mais para se espalhar
    • Acho que o fracasso do projeto Servo não foi um problema do Rust, mas sim uma limitação interna da Mozilla

  • Se usar Rust ajuda a resolver os problemas deles, então parece uma escolha racional.
    Linguagem é uma ferramenta que se ajusta de formas diferentes conforme o projeto, a equipe e o problema

    • Muitas vezes, histórias sobre otimização de dependências ou melhoria de desempenho são mais interessantes do que essas “mudanças de linguagem”
    • O post original não atacava C, então acho que nem havia necessidade de mencioná-lo
    • É um fato óbvio que linguagens memory-safe são tecnicamente superiores do ponto de vista de segurança.
      Isso não é papo de fanboy de Rust, e sim um problema de resistência parecido com a época em que médicos ou pilotos rejeitavam checklists
    • Rust é adequado para este caso, mas é inadequado para a maioria dos projetos de UI.
      Em UI, iteração rápida e GC são importantes, e desempenho importa menos. Fazer UI em Rust pode virar um inferno de manutenção
    • Não gosto da atitude de “vamos reescrever tudo em Rust”, mas no caso do Tor Rust é a ferramenta certa.
      Isso porque o Tor roda em um ambiente multithread em que segurança e desempenho importam ao mesmo tempo.
      Zig também pode ser uma alternativa, mas ainda não está maduro. Abordagens como a do Tigerbeetle, que priorizam determinismo (determinism), também são interessantes

  • A maior reclamação sobre o projeto Tor é a queda de velocidade. Não parece que migrar para Rust vai deixá-lo mais rápido

    • O onion routing envolve um trade-off entre privacidade e desempenho. A latência de rede é a principal causa
    • A lentidão do Tor se deve mais à falta de nós do que ao código. A nova versão só será mais segura, não mais rápida
    • O tráfego dá duas voltas no planeta, então existe latência física inevitável. No fim, é o limite da velocidade da luz
    • O Tor serve para garantir anonimato, não para streaming de vídeo
    • Criar uma rede anônima rápida é muito difícil. Ainda assim, o Tor recente está muito mais rápido do que antes, e atuar apenas dentro da onion aumenta o anonimato

  • Essa transição para Rust aconteceu com apoio do Zcash Community Grants. Até P&D com criptomoedas pode gerar bons resultados

    • Isso lembra a expressão “Pecunia non olet” (dinheiro não cheira).
      Embora venha a piada de que criptomoeda talvez seja pior do que urina

  • Fico preocupado com o risco jurídico de operar um nó de saída do Tor. Será que existe uma forma de permitir isso só com base em whitelist?

    • Vale consultar o guia oficial do blog do Tor sobre operação de nós de saída.
      Se possível, recomenda-se registrar em nome de uma organização, e se você quiser ajudar com mais segurança, é melhor operar um relay
    • Se quiser evitar atenção jurídica, uma opção é operar uma bridge.
      Ou então rodar um guard/middle relay, o que também ajuda bastante a rede
    • Nó de saída é complicado, mas você também pode doar banda hospedando coisas como torrents de ISO de Linux ou um servidor de tiles de OpenMap.
      Só que é preciso bloquear alguns ASNs da China. Há muito tráfego falso de download

  • A adoção de Rust parece o processo de substituir pilares de madeira por aço em uma fortaleza antiga.
    O código em C do Tor carrega décadas de concessões de segurança e marcas de desempenho, então uma rustificação gradual é a forma mais realista de aumentar a segurança
    O ponto principal não é uma “reescrita total”, e sim reduzir as áreas sem memory safety.
    Se apenas as partes mais arriscadas — parsing, criptografia e fronteiras de protocolo — forem migradas para Rust, o Tor ficará mais robusto
    Também é interessante pensar que no futuro isso pode evoluir para pluggable transports em Rust ou um runtime híbrido

  • Na verdade, essa decisão não é recente. O Tor iniciou em 2020 o projeto Arti, baseado em Rust, e em 2022 anunciou o Arti 1.0
    Eles concluíram que seria difícil refatorar gradualmente a base em C e disseram estar satisfeitos com a velocidade de desenvolvimento, portabilidade e entrada de novos contribuidores proporcionadas por Rust
    Mesmo recentemente, o changelog do Arti mostra que o desenvolvimento segue ativo

    • O Arti foi projetado para poder ser embutido como biblioteca em outros apps.
      Por exemplo, um app de mensagens poderia usar a rede sem precisar de um daemon Tor separado. Acho que essa é uma mudança ainda maior
    • Também há quem diga que o título é exagerado. A equipe do Tor vem avançando com cautela há muito tempo
    • Este link é uma referência muito melhor do que o texto original. A estratégia parece tão clara que praticamente encerra de antemão o debate sobre “por que Rust?”
    • Também foi levantada a dúvida sobre Rust realmente ter portabilidade entre sistemas operacionais melhor do que C

  • Tor não é só um conceito, mas um nome que engloba o protocolo (onion routing), a rede e também a implementação de referência

    • Onion routing é o protocolo, e Tor é a rede e a implementação sobre ele
    • Tor é de fato um produto que pode ser baixado e é composto por vários componentes
    • Então dizer que “estão reescrevendo o Tor em Rust” não é exatamente errado

  • Houve até uma sugestão em tom de brincadeira de que talvez bastasse compilar o Tor com Fil-C para ganhar memory safety de graça

    • Mas essa migração é um projeto que começou antes mesmo do surgimento do Fil-C