Ponts SOCKS avec socat : préserver le nom d'hôte TLS du site

Utilisez un écouteur TCP de loopback pour une destination SOCKS tout en préservant l'identité HTTP et TLS dans l'application.

Une application n'a pas d'option SOCKS, mais peut se connecter à une adresse TCP choisie. Un adaptateur à cible fixe peut fournir la conversation SOCKS pour une seule destination. Il n'a pas besoin de devenir un autre proxy direct générique.

Pour les compilations de socat offrant SOCKS4A, un montage illustratif est le suivant :

socat TCP4-LISTEN:9443,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4A:127.0.0.1:service.example.net:443,socksport=1080

Le point de terminaison SOCKS est le port local 1080. L'adaptateur écoute sur le port local 9443 et demande à ce point de terminaison service.example.net:443. Ce sont des valeurs d'exemple, pas un déploiement complet de service.

L'adaptateur a une cible fixe

Chaque connexion TCP acceptée demande le même service. Une application qui se connecte à 9443 fournit ses octets de protocole habituels ; socat fournit la négociation SOCKS4A. Envoyer une nouvelle requête HTTP CONNECT vers 9443 ne sélectionnerait pas une autre destination : elle enverrait ces octets vers le service fixe.

SOCKS4A fournit un nom d'hôte au point de terminaison SOCKS pour une résolution distante. Cela diffère de la forme SOCKS4 qui utilise une adresse choisie par le client. L'amont choisi—y compris un candidat public de la liste de proxys SOCKS4—doit prendre en charge le traitement des noms d'hôtes SOCKS4A et l'authentification requise ; cet exemple n'est pas une recette de connexion par mot de passe SOCKS5.

Se connecter localement, identifier le vrai service

Changer une URL HTTPS en https://127.0.0.1:9443/ change le nom d'hôte que le client peut utiliser pour TLS et HTTP. Un certificat pour service.example.net ne deviendra pas un certificat valide pour le loopback.

Lorsque le client prend en charge un routage de connexion distinct, conservez l'identité de l'URL d'origine. Curl peut illustrer cette distinction :

curl --noproxy '*' \
  --connect-to service.example.net:443:127.0.0.1:9443 \
  https://service.example.net/

La socket va vers l'adaptateur local tandis que la vérification TLS et la destination HTTP restent service.example.net. D'autres applications ont besoin de leur propre contrôle équivalent pris en charge ; tous les clients n'en fournissent pas.

La liaison loopback limite l'exposition réseau, mais d'autres processus locaux éligibles peuvent encore l'atteindre. Gardez la durée de vie du service et les utilisateurs appropriés. Conservez la vérification TLS plutôt que de supprimer l'erreur d'identité causée par une URL de loopback.

Articles similaires