Privoxy: ligar um cliente de proxy HTTP a um túnel SOCKS

Um túnel SSH dinâmico, incluindo o encaminhamento dinâmico do PuTTY, fornece uma interface SOCKS. Uma aplicação que só aceita um proxy HTTP não pode usar essa porta apenas por lhe chamar HTTP.

Uma ponte de protocolo local pode ficar entre os dois. A aplicação envia os pedidos de proxy HTTP para a ponte, e a ponte abre as ligações de destino através do serviço SOCKS.

O Privoxy documenta esta disposição nas suas regras de encaminhamento. Para um túnel SOCKS5 local existente, um fragmento de configuração é:

forward-socks5 / 127.0.0.1:1080 .

A aplicação liga-se ao ouvinte HTTP do Privoxy, não à porta 1080. Mantém esse ouvinte local segundo a política de acesso pretendida. O ponto final na regra tem um significado documentado; não é um marcador para um nome de anfitrião de internet em falta.

Isto é tradução de protocolo

A documentação de encaminhamento do Privoxy explica a sintaxe do encaminhamento SOCKS e o tratamento de nomes de anfitrião. Um encaminhamento de porta TCP simples não faz a mesma tradução: transporta os bytes HTTP do cliente sem alteração para um ouvinte SOCKS, que continua à espera de uma negociação SOCKS.

A ponte também passa a fazer parte da configuração que é preciso compreender. O Privoxy pode ter as suas próprias definições de filtragem de conteúdo e de acesso. Acrescentá-lo não é o mesmo que fazer com que a aplicação original suporte SOCKS nativamente.

Para sites HTTPS, a aplicação pede normalmente CONNECT à ponte HTTP, e a ponte obtém a ligação de destino através do SOCKS. O TLS normal do site continua a ser uma relação entre aplicação e site; a ponte não precisa de se fazer passar pelo site para oferecer este caminho.

Se a aplicação consegue usar SOCKS diretamente, o componente extra pode ser desnecessário. Usa a ponte para resolver uma incompatibilidade real de protocolo, com o ouvinte e a origem claramente distintos.