Tor ou VPN: decida por quem cada caminho o obriga a confiar
Uma VPN acumula a sua confiança num só operador; o Tor reparte-a pelos relays. Decida pela cobertura, por quem o pode ligar a um site e pelo que pode verificar.
Escolher entre o Tor e uma VPN resume-se a que parte pode tolerar que veja as duas pontas de uma ligação. Uma VPN concentra essa visão num operador que escolheu. O Tor reparte-a pelos relays, pelo que nenhum relay individual se destina a saber quem é e o que descarregou.
Nenhuma das duas disposições o torna anónimo por si só. Escolha aquela cuja confiança restante consegue dizer em voz alta e depois corrija as partes que deixa descobertas.
Conte quem o pode ligar a um destino
Com uma VPN, cada fluxo coberto chega à saída do operador antes de chegar ao destino. Esse operador vê necessariamente o seu endereço de origem e, para tudo o que não esteja cifrado através dele, o destino que pediu. O TLS mantém o conteúdo da página fora dessa visão, mas normalmente deixa o nome do anfitrião visível enquanto a ligação é estabelecida. Uma parte pode, por isso, ligá-lo a um site, e essa ligação é precisamente a confiança que concede.
O Tor separa essas metades por três relays: um guarda que conhece o seu endereço mas não o destino, um relay intermédio que não conhece nenhuma das pontas e uma saída que conhece o destino mas não você. O desenho assume que nenhum relay combina os dois factos, o que é uma suposição mais fraca e mais útil do que confiar numa só empresa. Não assume que os relays sejam honestos e não derrota um observador que vigia as duas pontas do caminho.
Ambos os desenhos partilham um ponto fraco, e ele fica no destino. Se iniciar sessão, o serviço liga essa sessão à sua conta seja qual for a rota que os pacotes tomaram. O encaminhamento muda de onde um pedido parece vir, não o que a página lhe pede para fornecer.
A cobertura importa mais do que o diagrama de encaminhamento
Uma VPN encaminha na camada de rede, pelo que cada aplicação do dispositivo herda o túnel, a menos que a exclua deliberadamente. Essa amplitude é a razão pela qual funciona ao mesmo tempo para um cliente de correio, um gestor de pacotes e um navegador.
O navegador Tor é um pacote, e as suas proteções vivem sobretudo dentro do navegador: uma impressão digital uniforme, isolamento entre sites e scripts limitados por um nível de segurança em vez das extensões que instalou. Apontar o Chrome para uma porta SOCKS compra o encaminhamento sem nada disso, o que é uma fonte comum de confiança mal colocada.
O resto do ambiente de trabalho fica intacto. Um cliente de sincronização, um atualizador ou um documento descarregado aberto noutro programa liga-se conforme esse programa está configurado, e nada disso passa pelo ouvinte SOCKS a menos que o configure ali. Enumere as aplicações que falam com a rede e depois pergunte quais delas a ferramenta escolhida cobre realmente. A cobertura é uma propriedade da sua configuração, não da sua intenção.
Escolha com três condições
A decisão resolve-se normalmente com três perguntas: o tráfego vem de uma aplicação ou de todo o dispositivo, o destino deve ser incapaz de identificar o seu endereço, e precisa de chegar a uma rede privada? Responda por essa ordem e a ferramenta escolhe-se quase sempre sozinha.
| Requirement | Better fit | Reason |
|---|---|---|
| Every app covered, including non-browser traffic | A device VPN | Routing happens below the application, with a kill switch to stop leaks |
| Destination must not learn your address | Tor | The site sees a shared exit address rather than one tied to your account |
| Browser fingerprint that blends in | Tor Browser | The uniformity ships with the browser, a proxy alone adds none of it |
| Access to a private subnet or office resource | A VPN | Tor exits reach the public internet, not your internal routes |
Quando dois requisitos entram em conflito, pondere qual pode impor. Um túnel de dispositivo com uma lista de exclusões que fura é pior do que uma rota só de navegador que consegue demonstrar.
A verificação é barata para ambos os caminhos, e deve acontecer antes de confiar em qualquer um deles:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Um resultado falso do primeiro comando significa que o pedido saiu fora do circuito, e é essa a falha que vale a pena apanhar cedo. Compare o segundo com o endereço que o seu fornecedor atribuiu, não com o que recorda da semana passada.
O que nenhuma das opções repara
A cifra das aplicações continua a fazer um trabalho que nenhum caminho realiza. O HTTP simples que atravessa uma rede de privacidade continua legível na saída, e o HTTPS continua a ser a única coisa que protege a carga de ponta a ponta. O TLS também nada diz sobre o nome do anfitrião que escreveu, e é por isso que o destino continua visível para quem termina o caminho.
As contas identificam-no, e nenhuma escolha de encaminhamento muda isso: o serviço sabe quem iniciou sessão independentemente do endereço no cabeçalho. A correlação por um observador que vê o suficiente da rede, o comprometimento do seu próprio dispositivo e tudo o que escreve num formulário sobrevivem a ambos os desenhos. Trate as duas ferramentas como formas de mover a confiança, não de a eliminar.
Comece pela configuração predefinida que cada projeto documenta, confirme o caminho com os dois comandos acima e só então considere empilhar uma VPN sob o Tor. Aninhá-las é uma configuração com os seus próprios modos de falha, não uma atualização gratuita.