Encadeamento de proxies: como funciona e quando é útil

A nossa declaração: somos a Geonode e comercializamos proxies, o que faz com que este artigo seja um em que argumentamos contra a utilização do nosso próprio produto. Encadeamento dos nossos proxies atrás dos de terceiros, ou através de vários dos nossos em sequência, tornará os seus pedidos mais lentos e menos fiáveis e não melhorará significativamente a sua posição. A razão é de natureza estrutural, e não uma limitação de qualquer fornecedor em particular, sendo explicada abaixo. Existem duas ou três razões genuinamente válidas para encadear proxies, e estas dizem respeito ao encaminhamento e ao acesso, e não ao anonimato. Se o seu objetivo é o anonimato, a resposta honesta é que um sistema concebido especificamente para esse fim o faz corretamente, ao passo que uma pilha de proxies comerciais não o faz.

O que é, na verdade, o encadeamento

Normalmente: ligas-te a um proxy, e o proxy liga-se ao destino. Duas ligações, um intermediário.

Em cadeia: liga-se ao proxy A, que se liga ao proxy B, que se liga ao destino. Cada salto encerra a ligação anterior e inicia uma nova, pelo que o destino vê apenas o endereço do proxy B e o proxy B vê apenas o proxy A.

As vantagens alegadas são que nenhum intermediário isolado conhece ambas as extremidades e que rastrear o percurso requer a cooperação de todos os operadores da cadeia.

Ambas as afirmações são verdadeiras num sentido restrito, mas, na prática, são muito mais fracas do que o resumo sugere. O resto deste artigo explica porquê.

As duas formas de criar uma cadeia

O encadeamento do lado do cliente é o caso mais comum: o seu computador está configurado para encaminhar o tráfego através de A, e A está configurado — ou instruído — para encaminhar o tráfego para B. Ferramentas como o proxychains fazem isto ao interceptar as ligações e encaminhá-las através de uma lista que o utilizador controla.

A característica que importa: é você quem escolhe a cadeia. Conhece cada salto, pode alterá-los e nenhum operador precisa de cooperar. É por isso que quase todo o encadeamento prático é do lado do cliente.

O encadeamento do lado do servidor ocorre quando um fornecedor encaminha o seu tráfego através de uma infraestrutura que não controla. Alguns serviços fazem isto internamente — um gateway que termina a sua ligação e sai através de um dos muitos pontos finais é, tecnicamente, uma cadeia, embora normalmente não seja descrito como tal.

A característica que importa aqui é o oposto: não controlas a cadeia e não a podes verificar. A alegação de um fornecedor de que o tráfego passa por vários países é impossível de verificar do teu lado. Trata-se de uma declaração de confiança, não de uma arquitetura.

proxychains: O que faz e quais são os seus limites

A ferramenta mais conhecida, cuja própria descrição é precisa quanto ao seu mecanismo. O proxychains é «um programa UNIX que intercepta funções da libc relacionadas com a rede em programas ligados dinamicamente através de uma DLL pré-carregada e redireciona as ligações através de proxies SOCKS4a/5 ou HTTP».

Essa frase contém tanto a genialidade como a limitação.

A genialidade: funciona com programas que não têm suporte próprio para proxies. Como intercepta ao nível da libc, uma aplicação que efetue chamadas de socket normais é redirecionada de forma transparente, sem que se aperceba disso.

A limitação, expressa de forma direta: «funciona apenas em programas ligados dinamicamente» e requer que o proxychains e a aplicação de destino «utilizem o mesmo ligador dinâmico». Os binários ligados estaticamente — o que inclui grande parte do software Go moderno — simplesmente não são afetados. O programa executa-se, liga-se diretamente e nada o avisa.

São suportados três modos de cadeia:

Ordem exata — os proxies são utilizados exatamente como configurados. É previsível, e um único proxy inativo interrompe a cadeia. Ordem dinâmica — os proxies inativos são excluídos de forma inteligente, pelo que a cadeia sobrevive a falhas, ao custo de não ser a cadeia que especificou. Ordem aleatória — um subconjunto aleatório de um comprimento configurado, útil quando se pretende variação entre execuções.

O suporte a protocolos abrange SOCKS4, SOCKS4a, SOCKS5 e HTTP(S), com autenticação por nome de utilizador/palavra-passe para SOCKS e autenticação básica para HTTP.

E há um modo de falha documentado que vale a pena conhecer, porque é verdadeiramente obscuro: «quando um processo se bifurca, efetua uma pesquisa de DNS no processo filho e, em seguida, utiliza o IP no processo pai, o mapeamento de IP correspondente não será encontrado.» As aplicações estruturadas desta forma apresentam comportamentos anormais que parecem problemas de rede, mas não o são.

A latência acumula-se e a fiabilidade diminui exponencialmente

A matemática é o argumento mais forte contra o encadeamento casual.

A latência acumula-se. Cada salto contribui com o seu próprio tempo de ida e volta, além do tempo de processamento. Um pedido direto de 50 ms pode passar a demorar talvez 200 ms ao passar por um proxy e 400 ms ao passar por dois. Para uma utilização interativa, esta é a diferença entre algo utilizável e algo irritante. Para uma tarefa de scraping que faz cem mil pedidos, é a diferença entre quatro horas e oito.

A fiabilidade multiplica-se, e a multiplicação de números inferiores a um só pode ir num sentido. Se cada salto estiver disponível de forma independente 95% do tempo:

Uma cadeia de três saltos de proxies individualmente fiáveis é um sistema que falha uma de cada sete solicitações. E as falhas numa cadeia são piores do que as falhas num único salto, porque o diagnóstico é mais difícil — um tempo limite indica que a cadeia se rompeu, mas não qual o elo.

A largura de banda é cobrada por salto. Se pagar por dois proxies medidos, cada byte é cobrado duas vezes. Encadeando dois serviços residenciais a 0,79 $/GB, o custo passa a ser de 1,58 $/GB para os mesmos dados.

A taxa de transferência é limitada pelo salto mais lento, e adicionar saltos aumenta as possibilidades de lentidão.

Face a esses custos, o benefício tem de ser substancial. Normalmente, não é.

O encadeamento torna-o mais anónimo?

A resposta sincera é: menos do que se diz, e depende inteiramente de quem são os operadores.

O que o encadeamento realmente consegue. Nenhum salto individual vê tanto o seu endereço como o do destino. O salto A sabe quem você é e que comunicou com o B. O salto B sabe que comunicou com o destino, mas não sabe quem foi o remetente. Essa é uma propriedade genuína.

Por que razão consegue menos do que parece.

A correlação entre os saltos é fácil para quem estiver a observar ambos. Um observador com visibilidade de ambas as extremidades — temporização, volume, padrões — pode associá-las sem descodificar nada. Trata-se de análise de tráfego e é o problema central dos sistemas de anonimato. Dois proxies comerciais não resolvem esta questão.

A propriedade comum desmantela a cadeia. Se ambos os saltos pertencerem ao mesmo fornecedor, ou revenderem a mesma rede subjacente, a separação é imaginária. As relações de revenda no mercado de proxies são comuns e nem sempre são divulgadas, e uma cadeia que passa por duas marcas que partilham um fornecedor tem um único operador, não dois.

A camada de aplicação anula-a por completo. Cookies, inícios de sessão, impressões digitais do navegador e tudo o que digitar identificam-no, independentemente do encaminhamento. Uma cadeia de cinco proxies a transportar uma sessão em que está com a sessão iniciada é uma forma muito lenta de ser identificado.

Os registos de pagamentos e de contas remetem de volta. Comprou estes serviços. Existe um registo.

A encriptação não é em camadas. Numa cadeia de proxies simples, cada salto pode ler tudo o que não estiver protegido por TLS. O encadeamento não adiciona encriptação; adiciona intermediários que podem ler o seu tráfego. Isso é o oposto do objetivo pretendido e é precisamente o que a próxima secção aborda.

O Tor está a encadear corretamente?

Vale a pena compreender isto como modelo de referência, pois mostra o que falta numa pilha de proxies comerciais.

O Projeto Tor explica claramente a diferença: «Ao contrário dos servidores proxy normais, que criam um único ponto de confiança e de falha, o Tor encaminha o tráfego através de vários relés com encriptação em camadas.»

O tráfego passa por, pelo menos, três relés, e a informação é deliberadamente fragmentada. O primeiro relé pode observar que um endereço está a utilizar o Tor, mas não consegue determinar o destino. O relé intermédio vê o tráfego encriptado e não consegue identificar nem o remetente nem o destino final. O relé de saída vê o tráfego de saída, mas não a sua origem — e, com HTTPS, apenas o site de destino, em vez do conteúdo.

Três características de conceção tornam isso possível, e uma cadeia de proxies manual não possui nenhuma delas:

Encriptação em camadas. Cada salto descasca uma camada. Um relé não consegue ler o que o salto seguinte irá receber. Numa cadeia de proxies simples, cada salto vê o seu tráfego tal como o seu cliente o enviou.

Os circuitos são selecionados pelo cliente a partir de um diretório publicado, com restrições de percurso concebidas para evitar relés correlacionados. Numa cadeia manual, escolhe-se entre o que se comprou e não é possível saber se dois fornecedores partilham infraestrutura.

Os relés são operados de forma independente por voluntários. Os fornecedores de proxy comerciais são empresas com registos, faturação e obrigações legais.

Nada disto faz do Tor uma solução universal — é lento, muitos sites bloqueiam-no e não é adequado para a recolha de grandes volumes de dados. A questão é comparativa: se o anonimato é o seu objetivo, um sistema concebido para isso cumpre a sua função, e empilhar proxies comerciais aproxima-se da forma sem ter a substância.

As fugas que comprometem toda a cadeia

Uma cadeia é tão boa quanto o seu elo mais fraco, e vários caminhos contornam-na por completo.

DNS. O mais comum. Se o seu resolvedor for consultado diretamente, o seu ISP vê todos os nomes de anfitrião, enquanto o seu tráfego passa por três saltos. Com o SOCKS5, utilize o esquema socks5h para que os nomes de anfitrião sejam resolvidos pelo proxy em vez de localmente — a diferença entre socks5:// e socks5h:// no curl é exatamente esta, e é o detalhe mais frequentemente esquecido na configuração do proxy.

WebRTC. Nos navegadores, pode expor endereços locais e públicos fora do caminho do proxy.

IPv6. Uma cadeia apenas para IPv4 com conectividade IPv6 disponível significa que parte do tráfego passa diretamente. De forma silenciosa e invisível, a menos que seja testado.

Binários ligados estaticamente sob o proxychains. Já abordado acima: a interceção simplesmente não se aplica, e o programa liga-se diretamente sem qualquer aviso.

Tudo o que estiver fora do processo interceptado. Programas de atualização do sistema, telemetria, serviços em segundo plano. Estes nunca estiveram na cadeia.

A regra geral: verificar em vez de presumir. Verificar se um site indica um endereço IP estrangeiro apenas confirma o que, obviamente, iria mudar. O nosso guia sobre teste de proxies aborda a verificação adequada de DNS, WebRTC e IPv6 e, no caso de uma cadeia, essa verificação é ainda mais importante, pois há mais pontos em que pode falhar.

Razões legítimas para encadeamento

Casos reais, nenhum dos quais tem a ver com anonimato.

Aceder a uma rede à qual não se consegue aceder diretamente. Um proxy corporativo é a sua única via de saída e precisa de um segundo proxy para além deste, para um destino específico. Trata-se de encadeamento como «canalização», e é, de longe, a utilização legítima mais comum.

Ponte de protocolos. A sua aplicação suporta apenas SOCKS, mas o proxy disponível é HTTP, ou vice-versa. Um proxy local converte e reencaminha. Mais uma vez, «canalização».

Adicionar funcionalidades num salto local. Executar um proxy local para armazenamento em cache, registo, reescrita de pedidos ou inspeção TLS, que depois reencaminha para um proxy a montante. Esta é uma cadeia cujo primeiro salto existe para realizar uma tarefa, em vez de ocultar algo, e é uma prática padrão no desenvolvimento e nos testes.

Roteamento geográfico que não se pode adquirir diretamente. Ocasionalmente, a localização de saída de que necessita só é acessível através de um intermediário. É raro, e vale a pena verificar se um fornecedor simplesmente oferece essa localização antes de construir uma cadeia.

Testar o comportamento em múltiplos saltos. Se estiver a criar algo que irá funcionar por trás de vários proxies, testar esse percurso é legítimo.

Repare no que estes casos têm em comum: a cadeia existe devido a uma restrição de encaminhamento, não porque se partiu do princípio de que mais saltos seriam melhores. Essa é a distinção que vale a pena aplicar ao seu próprio caso.

Perguntas frequentes

Encadeamento de proxies aumenta o anonimato?

Ligeiramente, e menos do que se esperaria. Significa que nenhum ponto de passagem vê simultaneamente o seu endereço e o destino. No entanto, não protege contra a correlação de tráfego, a propriedade comum entre fornecedores ou a identificação na camada de aplicação através de cookies, inícios de sessão e impressões digitais. O encadeamento simples também não adiciona encriptação — cada salto vê tudo o que o TLS não protege.

Quantos proxies devo encadear?

Por razões legítimas de encaminhamento, o mínimo que a restrição exigir — normalmente dois. Para fins de anonimato, encadear proxies comerciais é a abordagem errada, independentemente do número, e um sistema concebido para esse fim faz isso melhor. Cada salto adicional aumenta a latência, multiplica a probabilidade de falha e duplica a sua fatura de largura de banda.

O que é o proxychains e como funciona?

Uma ferramenta Unix que se integra às funções libc relacionadas com a rede em programas ligados dinamicamente e redireciona as ligações através de proxies SOCKS4a/5 ou HTTP. Oferece uma ordenação da cadeia exata, dinâmica e aleatória. A sua principal limitação é que funciona apenas em programas ligados dinamicamente — os binários ligados estaticamente ligam-se diretamente sem qualquer aviso.

O encadeamento de proxies é lento?

Sim, necessariamente. Cada salto acrescenta um tempo de ida e volta e de processamento, pelo que uma cadeia de dois saltos praticamente duplica o custo de um único proxy. O débito é limitado pelo salto mais lento e, se cada salto tiver 95% de fiabilidade, uma cadeia de três saltos tem sucesso em cerca de 86% das vezes.

Posso encadeá-la uma VPN e um proxy?

Tecnicamente sim, e é comum. O efeito prático é, normalmente, uma maior latência para uma alteração modesta naquilo que cada parte observa. O seu fornecedor de VPN continua a ver que se está a ligar, o operador do proxy continua a ver os seus pedidos e nenhuma destas configurações resolve a identificação na camada de aplicação.

O encadeamento impede que os sites me rastreiem?

Não. O rastreio funciona através de cookies, impressões digitais do navegador, inícios de sessão em contas e padrões comportamentais — nenhum dos quais é afetado pelo número de saltos de rede que o seu tráfego percorre. O encaminhamento altera o endereço que um site regista, e os sites deixaram de depender apenas do endereço há muito tempo.

O Tor é uma cadeia de proxies?

Trata-se de um encadeamento realizado com três propriedades de que uma cadeia manual carece: encriptação em camadas, para que nenhum relé possa ler o que o seguinte recebe; percursos selecionados pelo cliente a partir de um diretório publicado com restrições para evitar relés correlacionados; e relés voluntários operados de forma independente. O Projeto Tor contrasta isto com os proxies normais, que «criam um único ponto de confiança e de falha».

Tenho de pagar duas vezes pela largura de banda numa cadeia?

Se ambos os saltos forem cobrados por tráfego, sim — cada byte passa por ambos e é cobrado por ambos. Dois serviços residenciais a 0,79 $/GB custam 1,58 $/GB pelos mesmos dados. Esta é uma razão óbvia para verificar se uma cadeia está realmente a resolver um problema antes de a construir.

Conclusão

O encadeamento de proxies é uma técnica de encaminhamento que é promovida como uma técnica de privacidade, mas as duas coisas não são a mesma coisa.

Enquanto técnica de encaminhamento, por vezes é exatamente o que se pretende: sair através de um proxy corporativo para um destino que necessita de outro, estabelecer uma ponte entre SOCKS e HTTP, ou colocar um proxy local à frente para armazenamento em cache e registo. Nesses casos, a cadeia existe devido a uma restrição, e a latência adicional é o preço a pagar pela rota.

No que diz respeito à privacidade, é uma versão fraca de algo que existe numa versão forte. Uma cadeia manual não acrescenta qualquer encriptação, pelo que cada salto pode ler tudo o que o TLS não protege. Não permite saber se dois fornecedores partilham infraestrutura. Não faz nada em relação à correlação de tráfego e absolutamente nada em relação a cookies, inícios de sessão e impressões digitais — que é onde a identificação realmente ocorre.

Os custos, entretanto, são certos. A latência aumenta, a fiabilidade diminui exponencialmente e a largura de banda medida é cobrada duas vezes. Se estiver a considerar uma cadeia, a questão relevante é saber que restrição de encaminhamento específica ela resolve. Se a resposta for «mais saltos parecem mais seguros», a matemática está contra si.