História do Tor: do onion routing aos dias atuais

A história do Tor, resumida

A história do Tor começa em 1995, no U.S. Naval Research Laboratory, um laboratório de investigação da U.S. Navy. David Goldschlag, Michael G. Reed e Paul Syverson desenvolveram aí os primeiros protótipos de encaminhamento onion. A linha cronológica do Tor Project diz que a pergunta colocada foi se “havia uma forma de criar ligações à Internet que não revelassem quem está a comunicar com quem”. A rede que é utilizada atualmente foi disponibilizada em outubro de 2002, com o código publicado sob uma licença de software livre e aberto. O Tor Project, Inc. foi fundado como organização sem fins lucrativos em 2006.

Todas as datas abaixo provêm da linha cronológica publicada pelo Tor Project, das suas notas de versão ou das suas próprias páginas de suporte. Quando uma afirmação é contestada, como no caso de quem financia o trabalho, a secção indica quais são as evidências e onde pode verificá-las.

O que o onion routing realmente faz

O onion routing separa dois factos que a Internet normalmente mantém associados: quem é você e o que pediu. O seu cliente Tor escolhe três relays e cria um circuito através deles. Encapsula o seu tráfego em três camadas de encriptação, uma por relay. Cada relay remove uma camada, conhece apenas o endereço do próximo salto e encaminha o pacote. É daí que vem o nome.

O primeiro relay, chamado guard, vê o seu endereço IP, mas não o destino. O último relay, o exit, vê o destino, mas não o seu endereço IP. O relay intermédio não vê nenhum dos dois. Nenhum relay individual detém as duas partes, e esse é todo o argumento de segurança. É também por isso que os relays devem ser operados por pessoas sem relação entre si. Se uma organização operasse o seu guard e o seu exit, a separação desapareceria e a encriptação não lhe daria qualquer proteção.

A fraqueza conhecida é a correlação de tráfego. Um observador que consiga monitorizar simultaneamente as duas extremidades de um circuito pode comparar o momento e o tamanho dos pacotes que entram com os dos pacotes que saem. O Tor não protege contra um atacante que consiga monitorizar toda a Internet ao mesmo tempo, e o artigo de design de 2004 de Roger Dingledine, Nick Mathewson e Paul Syverson, "Tor: The Second-Generation Onion Router", afirma isso no seu modelo de ameaças.

Por que uma rede privada teria sido inútil

Esta é a parte que os resumos curtos omitem. Ela explica todo o restante desta página.

Uma organização militar ou de inteligência não consegue obter anonimato numa rede que transporta apenas o seu próprio tráfego. O anonimato é uma propriedade de uma multidão, não uma propriedade de uma cifra. Se cada ligação que sai da rede pertence a um único escritório, então um observador que vê uma ligação sair já aprendeu a resposta. A encriptação continua a funcionar perfeitamente. O anonimato não existe, porque não há ninguém com quem confundir essa ligação.

Por isso, o projeto tinha de ser público, e o tráfego tinha de ser misturado com o tráfego de outras pessoas. O código foi disponibilizado sob uma licença de software livre em outubro de 2002, e qualquer pessoa podia executar um relay. Jornalistas, ativistas, investigadores e pessoas comuns que evitavam uma rede de publicidade passaram a formar a multidão que protege todos os outros utilizadores dentro dela. Dingledine e Mathewson apresentaram este argumento em 2006, num artigo chamado "Anonymity Loves Company: Usability and the Network Effect", apresentado no Workshop on the Economics of Information Security. A conclusão é que a dimensão e a variedade da base de utilizadores são propriedades de segurança do sistema. Não são um número de marketing.

Do código alfa a uma organização sem fins lucrativos

A cronologia do Tor Project e os artigos publicados registam estas etapas:

• Outubro de 2002: a rede Tor é implementada, com o código distribuído "sob uma licença de software livre e aberto".
• Final de 2003: a rede funciona com "cerca de uma dúzia de nós voluntários, sobretudo nos EUA, além de um na Alemanha".
• 2004: Dingledine, Mathewson e Syverson publicam o artigo de conceção "Tor: The Second-Generation Onion Router".
• 2004: a Electronic Frontier Foundation (EFF) começa a financiar o trabalho no Tor.
• 2006: é fundada a The Tor Project, Inc., uma organização sem fins lucrativos 501(c)(3), para manter o desenvolvimento.
• 2007: começa o trabalho nas bridges, porque as firewalls nacionais começaram a bloquear a lista pública de relays.
• 2008: começa o desenvolvimento do Tor Browser.

Duas datas posteriores são importantes para compreender como a rede é utilizada atualmente. A cronologia do Tor Project situa o uso do Tor durante a Primavera Árabe no final de 2010, para proteger a identidade dos utilizadores e permitir o acesso a sites bloqueados. Também regista os documentos de Snowden de 2013 como o momento em que o papel do Tor se tornou amplamente conhecido, e afirma que os documentos mostraram que o Tor não tinha sido quebrado nessa altura. Nenhum dos eventos alterou o protocolo. Ambos alteraram quem o instalava.

Quem financia o Tor e como verificar

O Tor Project responde a esta questão nas suas próprias páginas de suporte: "The Tor Project is supported by a mix of government grants, private foundations, and individual donors." O financiamento público faz parte dessa mistura e existe desde o início. A página de apoiantes identifica o U.S. Department of State, a Ford Foundation, o Open Technology Fund, a Craig Newmark Philanthropies e empresas como Brave, DuckDuckGo, Mullvad VPN e Fastly. As contas auditadas são publicadas como publicações no blogue, sendo as mais recentes relativas ao exercício financeiro de 2023 a 2024, publicadas em dezembro de 2025. A posição declarada do projeto é que "talking openly about our sponsors and funding model is the best way to maintain trust with our community".

A questão útil não é quem pagou. É o que o dinheiro poderia comprar. O Tor não é um serviço no qual inicia sessão. É uma especificação de protocolo, um cliente cujo código-fonte pode ser consultado e uma rede de relays operados por terceiros. Quem quisesse introduzir uma backdoor teria de a colocar num de três pontos, e todos podem ser verificados.

• No código-fonte. O cliente é open source e o protocolo é especificado publicamente. Investigadores académicos publicam regularmente ataques ao Tor e têm todos os incentivos profissionais para encontrar primeiro uma falha.
• No binário. As compilações do Tor Browser são determinísticas desde agosto de 2013, pelo que um compilador independente pode reconstruir uma release e compará-la byte a byte com o download publicado. Um binário que não corresponda ao respetivo código-fonte pode ser detetado sem confiar na pessoa que o disponibilizou.
• Nos relays. O Tor Project não opera a rede. "The Tor network relies on volunteers to donate bandwidth", e os guards, relays intermédios, exits e bridges pertencem a milhares de operadores sem relação entre si. Comprometer um financiador não compromete esses operadores.

A declaração do próprio projeto é curta: "Tor has no backdoors. The software is open source, its code can be independently audited, and every release is signed to protect against tampering." Essa frase só tem valor porque cada cláusula identifica algo que pode verificar diretamente.

Existe uma ressalva real, relacionada com prioridades e não com integridade. O financiamento por subsídios determina que trabalho é feito primeiro, pelo que a evasão à censura tem recebido financiamento mais consistente do que, por exemplo, o desempenho da rede. Esta é uma crítica legítima ao projeto. É diferente de afirmar que "o código está comprometido", e a resposta exige ler os relatórios financeiros, não confiar nas garantias de ninguém.

Os serviços ocultos tornaram-se serviços onion

Um serviço onion é um servidor que nunca revela o seu endereço IP. O cliente e o servidor constroem o seu próprio circuito até um ponto de encontro dentro da rede, pelo que nenhum dos lados fica a conhecer o endereço do outro. O endereço não é um nome atribuído a alguém por um registo. É derivado da chave pública do servidor, razão pela qual um endereço .onion parece ser composto por caracteres aleatórios.

A cronologia dos serviços onion regista os lançamentos:

• 8 de abril de 2004: os serviços ocultos são implementados pela primeira vez, no Tor 0.0.6pre1.
• 21 de setembro de 2007: surgem os serviços ocultos da versão 2, no Tor 0.2.0.7-alpha.
• 19 de dezembro de 2016: começa o desenvolvimento da versão 3, no Tor 0.3.0.1-alpha.
• 9 de janeiro de 2018: é lançada a versão 3, no Tor 0.3.2.9.

A mudança de "serviços ocultos" para "serviços onion" aconteceu gradualmente, e não numa data específica. A documentação do Tor Project ainda usa os dois termos. O termo antigo descrevia a coisa errada. Muitos sites onion são públicos, indexados e divulgados; o que está oculto é a localização do servidor, não o site. O nome original sobrevive no ficheiro de configuração, que funciona como um vestígio histórico. É assim que ainda se declara um serviço em torrc:

HiddenServiceDir /var/lib/tor/my_service/
HiddenServicePort 80 127.0.0.1:8080

O diretório contém as chaves do serviço e um ficheiro hostname que contém o endereço. A linha da porta associa uma porta no endereço onion a um endereço local na mesma máquina. Assim, o servidor Web pode continuar associado a 127.0.0.1 e nunca escutar numa interface pública. A versão 3 é a predefinida. Por isso, um serviço criado hoje com estas duas linhas obtém um endereço v3.

Um endereço onion também não é um nome de domínio. A RFC 7686, publicada em outubro de 2015, reservou .onion como nome de domínio de utilização especial, para que os resolvers comuns deixassem de encaminhar estas consultas para o DNS público (sistema de nomes de domínio). A regra definida é direta: "Os servidores autoritativos DEVEM responder às consultas para .onion com NXDOMAIN." Compare isto com a forma como um nome de domínio comum é resolvido e a diferença torna-se evidente. Um nome DNS é-lhe atribuído por um registo e é consultado através de servidores que não controla. Um endereço onion é uma chave pública. Por isso, autentica-se a si próprio e não é necessária qualquer consulta.

Por que os endereços .onion antigos deixaram de funcionar

Os dois formatos de endereço não são compatíveis, e o formato antigo foi desativado permanentemente.

[
  {
    "version": "v2 (retired 2021)",
    "address_length_chars": 16,
    "service_key": "RSA-1024",
    "address_hash": "SHA-1, truncated to 80 bits"
  },
  {
    "version": "v3 (current)",
    "address_length_chars": 56,
    "service_key": "Ed25519",
    "address_hash": "SHA3-256"
  }
]

Um endereço v2 tinha 16 caracteres porque continha apenas os primeiros 80 bits de um hash SHA-1 da chave pública RSA-1024. Um endereço v3 tem 56 caracteres porque contém a chave pública Ed25519 completa, além de um checksum e um byte de versão. O endereço v3 é mais longo porque deixou de truncar a chave, portanto o próprio endereço passou a ser a identidade completa do serviço.

A descontinuação seguiu um calendário anunciado:

• 15 September 2020, Tor 0.4.4.x: o Tor começa a avisar os operadores e clientes de que o v2 está obsoleto.
• 15 July 2021, Tor 0.4.6.x: o suporte ao v2 é removido da base de código.
• 15 October 2021: as novas versões estáveis do cliente para todas as séries suportadas desativam o v2.

O motivo declarado era criptográfico. "À medida que a compreensão humana da matemática e da criptografia evoluiu, a base da versão 2 tornou-se frágil e, naquele momento, insegura." Um hash SHA-1 truncado para 80 bits e uma chave RSA de 1024 bits já estavam abaixo de um nível razoável em 2021, e o formato do endereço não permitia alterar nenhum dos dois.

A consequência para o leitor é simples e deve ser exposta claramente. Todos os links .onion com 16 caracteres publicados antes de 2021 estão permanentemente inativos, e não existe redirecionamento. Não era possível atualizar um endereço v2, porque o endereço era a chave antiga. Os operadores tiveram de criar um novo serviço e publicar o novo endereço por um canal que os utilizadores já consideravam confiável.

Bridges e transportes conectáveis: a censura continuou a mudar

A lista de relays públicos é publicada de propósito, para que o cliente possa escolher o seu próprio caminho em vez de confiar a escolha a um único servidor. Essa mesma lista publicada é uma lista de bloqueio pronta para qualquer país que queira impedir o Tor. O trabalho nas bridges começou em 2007. Uma bridge é um relay que não aparece na lista pública. Pode pedir um pequeno número delas pela Web ou por email, e um censor não pode bloquear endereços que não consegue enumerar.

O bloqueio passou depois dos endereços para o perfil do tráfego. A inspeção profunda de pacotes reconhece o protocolo Tor na rede, independentemente do endereço IP de destino. A resposta foram os transportes conectáveis: uma camada que altera o aspeto do tráfego Tor sem alterar o seu funcionamento. No Tor Browser atual, estes transportes são fornecidos num único binário chamado lyrebird, sucessor do obfs4proxy, e o lado do cliente é composto por três linhas de torrc:

UseBridges 1
ClientTransportPlugin meek_lite,obfs4,snowflake,webtunnel exec [PATH]/lyrebird
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Substitua [PATH] pelo diretório que contém o binário lyrebird e copie a linha Bridge completa do site de bridges do Tor Project, em vez de a escrever manualmente. Cada transporte resolve um método de bloqueio diferente:

• obfs4 faz com que o tráfego não tenha um aspeto reconhecível, sem um cabeçalho de protocolo que um filtro possa identificar. A recomendação do próprio Tor é experimentá-lo primeiro, porque é um transporte que randomiza o tráfego e funciona para a maioria das pessoas.
• snowflake encaminha a ligação através de proxies temporários executados por voluntários em browsers comuns, por isso o endereço ao qual se liga está sempre a mudar. Chegou ao Tor Browser estável na versão 10.5, em 6 de julho de 2021.
• meek encaminha a ligação através de um grande fornecedor de cloud, fazendo com que o tráfego pareça destinado a esse fornecedor. Bloqueá-lo implica também bloquear o fornecedor.
• webtunnel segue a abordagem oposta à do obfs4. Em vez de não ter um aspeto identificável, parece uma ligação HTTPS normal a um servidor Web, ao "encapsular a ligação de payload numa ligação HTTPS semelhante a WebSocket". O Tor Project lançou-o no Tor Browser estável em 12 de março de 2024, para redes que permitem apenas uma lista curta de protocolos.

Esta sequência mostra a evolução real dos últimos vinte anos. Cada novo transporte existe porque uma técnica de bloqueio específica começou a funcionar, e as datas desses lançamentos registam o que os censores estavam a fazer nesse ano.

O Tor não é uma VPN, e um VPS também não

Muitas pessoas chegam ao Tor depois de ler sobre VPNs, por isso é importante ser preciso. Uma VPN (rede privada virtual) envia o seu tráfego para um servidor gerido por uma empresa, e essa empresa vê o seu endereço real e o destino no mesmo momento. O Tor envia o seu tráfego através de três relays geridos por pessoas diferentes, por isso nenhum deles tem acesso aos dois factos. São modelos de confiança diferentes, com modos de falha diferentes. A diferença entre um VPS e uma VPN explica onde cada um se enquadra.

Se pretende um túnel privado entre máquinas que controla, em vez de anonimato dentro de uma multidão, precisa de uma VPN gerida por si. Pode alojar uma VPN WireGuard num VPS com cerca de quarenta linhas de configuração. Isto protege o seu tráfego contra a rede local e o seu fornecedor de Internet. Não lhe oferece anonimato perante a empresa que aloja o servidor, porque alugou esse servidor com os seus próprios dados de pagamento. A questão separada de se o alojamento VPS é seguro trata de uma ameaça diferente: quem mais consegue aceder à sua máquina.

Executar um relay é o sentido oposto, e a rede depende disso. Bridges, guards, middle relays e exits precisam todos de operadores, e o guia de relays do Tor Project deixa claro que "executar um relay requer conhecimentos técnicos e empenho". Os exits implicam exposição legal, porque o tráfego de outras pessoas sai para a Internet com o seu endereço IP e o seu fornecedor de alojamento receberá reclamações. Leia esse guia antes de iniciar um, não depois.

FAQ

O Tor foi criado pelo governo dos EUA?

O encaminhamento onion começou no U.S. Naval Research Laboratory em 1995, onde David Goldschlag, Michael G. Reed e Paul Syverson criaram os primeiros protótipos. O Tor foi o projeto da geração seguinte, iniciado por volta de 2001 e 2002 por Roger Dingledine, Nick Mathewson e Paul Syverson, e a rede foi disponibilizada em outubro de 2002 sob uma licença de software livre. O Tor Project, Inc. é uma organização sem fins lucrativos independente, com estatuto 501(c)(3), desde 2006. A origem governamental é real e também explica por que a rede teve de ser aberta a todos: uma rede que transporta o tráfego de uma única organização não dá anonimato a essa organização, porque cada ligação que sai dela identifica o remetente pelo simples facto de a utilizar.

O financiamento governamental significa que o Tor tem uma backdoor?

A resposta do Tor Project é: "O Tor não tem backdoors. O software é open source, o código pode ser auditado de forma independente e cada release é assinada para proteger contra adulteração." O que torna isto verificável, e não apenas uma promessa, é a estrutura existente. O protocolo é especificado publicamente, as compilações do Tor Browser são determinísticas, pelo que um compilador independente pode recriar uma release e compará-la com o binário publicado, e os relays são operados por voluntários, não por financiadores. O financiamento influencia o trabalho que é feito primeiro, e os relatórios financeiros auditados no blogue do Tor mostram de onde veio o dinheiro. Essa é uma questão de prioridades, não do código.

Por que motivo o meu endereço .onion antigo deixou de funcionar?

Era um endereço da versão 2, e os onion services v2 foram descontinuados em 2021. O Tor começou a emitir avisos sobre isso em 15 de setembro de 2020, removeu o suporte a v2 da base de código no Tor 0.4.6.x em 15 de julho de 2021 e desativou-o nas releases estáveis em 15 de outubro de 2021. Um endereço v2 tem 16 caracteres antes de .onion e um endereço v3 tem 56. Não existe redirecionamento nem caminho de atualização, porque o endereço era derivado da chave antiga. Por isso, o operador teve de criar um novo serviço e publicar o novo endereço.

O Tor é igual a uma VPN?

Não. Uma VPN envia o seu tráfego para um servidor operado por uma empresa, e essa empresa pode ver em conjunto o seu endereço IP real e o seu destino. O Tor envia o tráfego por três relays operados por pessoas diferentes. O primeiro relay vê o seu endereço sem ver o destino, e o último vê o destino sem ver o seu endereço. O Tor é mais lento e foi concebido para fornecer anonimato contra um observador que não monitoriza toda a internet. Uma VPN é mais rápida e foi concebida para proteger a privacidade perante a rede local e o fornecedor de internet.

O que é um transporte plugável e preciso de um?

Um transporte plugável é um wrapper que altera o aspeto do tráfego do Tor na rede sem alterar o funcionamento do Tor. Assim, um filtro que reconheça o protocolo Tor não consegue identificá-lo diretamente. Só precisa de um se o Tor simples não conseguir estabelecer ligação, o que normalmente significa que a sua rede ou o seu país o está a bloquear. O Tor Browser inclui obfs4, snowflake, meek e webtunnel num único binário chamado lyrebird. Comece pelo obfs4, porque é um transporte que randomiza o tráfego e funciona para a maioria das pessoas. Se essa ligação nunca for concluída, experimente webtunnel ou snowflake.