Privoxy : relier un client proxy HTTP à un tunnel SOCKS

Un tunnel SSH dynamique, y compris le transfert dynamique de PuTTY, fournit une interface SOCKS. Une application qui n'accepte qu'un proxy HTTP ne peut pas utiliser ce port simplement en le nommant HTTP.

Un pont de protocole local peut s'intercaler. L'application envoie les requêtes proxy HTTP au pont, et le pont ouvre les connexions de destination via le service SOCKS.

Privoxy documente cette disposition dans ses règles de transfert. Pour un tunnel SOCKS5 local existant, un fragment de configuration est :

forward-socks5 / 127.0.0.1:1080 .

L'application se connecte à l'écouteur HTTP de Privoxy, pas au port 1080. Gardez cet écouteur local selon la politique d'accès prévue. Le point final de la règle a une signification documentée ; ce n'est pas un emplacement réservé pour un nom d'hôte internet manquant.

Il s'agit d'une traduction de protocole

La documentation de transfert de Privoxy explique la syntaxe du transfert SOCKS et la gestion des noms d'hôtes. Un simple transfert de port TCP ne réalise pas la même traduction : il transporte les octets HTTP du client sans modification vers un écouteur SOCKS, qui attend toujours une négociation SOCKS.

Le pont devient aussi une partie de la configuration qu'il faut comprendre. Privoxy peut avoir ses propres réglages de filtrage de contenu et d'accès. L'ajouter n'équivaut pas à faire en sorte que l'application d'origine prenne en charge SOCKS nativement.

Pour les sites HTTPS, l'application demande généralement CONNECT au pont HTTP, et le pont obtient la connexion de destination via SOCKS. Le TLS normal du site reste une relation entre l'application et le site ; le pont n'a pas besoin d'usurper l'identité du site pour fournir ce chemin.

Si l'application peut utiliser SOCKS directement, le composant supplémentaire peut être inutile. Utilisez le pont pour résoudre une véritable inadéquation de protocole, en distinguant clairement l'écouteur et l'amont.