Tor e HTTPS protegem partes diferentes da navegação. HTTPS protege o conteúdo em trânsito até o site, mas não esconde, sozinho, seu endereço IP desse site. Tor faz a conexão sair por outro ponto da rede e distribui o caminho entre relays. Usar os dois não impede que um login revele ao destino qual é sua conta.
Para escolher a proteção, a pergunta útil não é “estou anônimo?”, mas “de quem quero esconder qual informação?”. Uma rede Wi-Fi, seu provedor de internet, um relay Tor e o serviço acessado observam posições diferentes. Também não têm necessariamente os mesmos registros ou capacidade de correlacioná-los.
Neste artigo
O caminho até um site comum
Em uma conexão HTTPS direta, o navegador estabelece uma conexão protegida com o serviço. O destino recebe a requisição e precisa ler o conteúdo para respondê-la. Criptografia de transporte não impede que esse serviço registre uma busca, associe uma ação à conta ou compartilhe dados segundo suas próprias práticas.
Com Tor Browser, o tráfego destinado à web comum passa por um circuito de relays. A entrada recebe a conexão do usuário; a saída fala com o destino. O desenho evita que um relay isolado tenha, por sua posição normal no circuito, tanto a origem quanto o destino final. HTTPS continua necessário no trecho entre saída e site. O Tor Project descreve essa separação entre entrada, saída e criptografia.
O quadro abaixo é uma síntese desse modelo, não o resultado de uma captura de rede. Ele considera um dispositivo sem comprometimento, certificados HTTPS válidos e um observador de cada vez. Não cobre inspeção instalada no próprio computador, cooperação entre observadores ou ataques de correlação. Serviços .onion têm outro caminho: não passam por um relay de saída para alcançar a web comum.
Quem vê o quê
| Quem observa | HTTPS direto | Tor com HTTP | Tor com HTTPS |
|---|---|---|---|
| Rede local e provedor | IP de origem e IP de destino; nome do site pode ficar exposto; não o corpo HTTPS | Origem e conexão com a entrada Tor; não o destino final pelo fluxo isolado | Origem e conexão com a entrada Tor; não o corpo nem o destino final pelo fluxo isolado |
| Relay de entrada Tor | Não participa | IP de origem e próximo relay; não o site final | IP de origem e próximo relay; não o site final |
| Relay de saída Tor | Não participa | Destino e conteúdo HTTP, inclusive credenciais enviadas sem proteção | Destino; não o conteúdo protegido por HTTPS |
| Site de destino | IP de origem da conexão, requisição e conta usada | IP da saída Tor, requisição e conta usada | IP da saída Tor, requisição e conta usada |
“Origem” significa o IP público que chega àquela conexão, não automaticamente nome civil ou endereço residencial. Redes compartilhadas e outras camadas de acesso mudam essa relação. “Nome do site pode ficar exposto” também não significa que todo caminho da URL fique visível: DNS, negociação TLS e suas configurações influenciam a exposição do domínio. A explicação da Mozilla sobre DNS criptografado e ECH ajuda a separar essas camadas; não comprova que estejam ativas em qualquer conexão. Não se deve transformar a tabela em promessa de que HTTPS revela todos os domínios ou de que os esconde sempre.
A visualização oficial de Tor e HTTPS ajuda a comparar essas posições. A coluna HTTP está aqui para explicar um risco, não como sugestão de teste: não desative o modo HTTPS-Only nem ignore alertas de certificado para experimentar.
Login muda a pergunta
Imagine duas visitas ao mesmo serviço. Na primeira, você lê uma página sem entrar na conta. Na segunda, entra com seu usuário habitual, ainda pelo Tor. O IP observado pelo serviço pode continuar sendo o da saída Tor, mas a segunda visita está ligada à conta por uma informação que você entregou deliberadamente.
Nesse cenário hipotético, Tor não “falhou”. O objetivo de ocultar o IP de origem do destino é diferente do objetivo de impedir identificação por login. Trocar de circuito também não faz o serviço esquecer ações que já associou a uma conta. Quem precisa separar contextos deve pensar nas informações fornecidas, não apenas no transporte.
O guia de uso seguro do Tor Browser alerta para essa distinção e para outro limite frequente: instalar o navegador não encaminha automaticamente todos os aplicativos do computador pela rede Tor. Um documento aberto em programa externo pode produzir conexões fora dele.
Três decisões práticas
Quero impedir que alguém no Wi-Fi leia o formulário. Confirme HTTPS válido e não avance diante de erro de certificado. Não basta o nome do site parecer correto. O conteúdo continuará acessível ao próprio serviço; o problema de confiança no destinatário permanece.
Quero reduzir a ligação direta entre meu IP e a visita ao site. Tor Browser é uma ferramenta pertinente para esse objetivo. Ainda é necessário avaliar login, dados enviados, arquivos abertos e limitações do dispositivo. Se você publica seu nome no formulário, o circuito não desfaz essa identificação.
Quero esconder que uso Tor. Essa é uma pergunta diferente de esconder o site visitado. A conexão com a rede Tor pode ser reconhecível. Não interprete a ocultação do destino final como ocultação automática da ferramenta usada, nem presuma que qualquer técnica anticensura resolva todas as formas de observação.
Onde a tabela deixa de ser suficiente
Um observador capaz de acompanhar entrada e saída pode tentar relacionar tempo e volume de tráfego. O próprio projeto explica os ataques que permanecem contra onion routing. Por isso, a frase “nenhum relay isolado vê o caminho inteiro” não equivale a “ninguém pode correlacionar uma conexão”.
Também ficam fora dessa proteção um computador comprometido e a divulgação voluntária de informações. Para o cotidiano, isso complementa, em vez de substituir, os hábitos de privacidade e proteção de dados.
A melhor verificação antes de navegar é formular uma frase concreta: “quero que este observador não obtenha este dado”. IP de origem, conteúdo, conta e uso de Tor são quatro dados distintos. Quando ficam separados, é mais fácil reconhecer o que a ferramenta entrega e o que ainda depende de você.
