client → local TCP relay → existing forward proxy → destination

Dans cette disposition, le relais possède un seul amont fixe. Il transmet la requête du client sans changement au proxy direct existant. Ce proxy lit l’URL absolue ou la cible CONNECT, applique la stratégie et ouvre la connexion de destination.

Pointer le relais directement vers un site web change le contrat. Un proxy direct doit sélectionner les destinations et gérer le cadrage HTTP ainsi que le comportement des connexions ; extraire un nom d’hôte de la première ligne ne suffit pas.

Le Ncat de Nmap fournit séparément un mode d’écoute conscient d’HTTP :

ncat --listen 127.0.0.1 3128 --proxy-type http

Cet exemple en boucle locale utilise l’implémentation de proxy de Ncat, pas une fonction commune à tous les nc. Son proxy côté écoute gère les méthodes HTTP et CONNECT. Ses options SOCKS côté client n’établissent pas de serveur SOCKS en mode écoute. Un service partagé permanent demande aussi une gestion réfléchie des connexions, un contrôle d’accès et une journalisation.

Pour l’observation, repérez la frontière du chiffrement. Un relais sur une connexion proxy HTTP en clair voit les requêtes et réponses du proxy. Après CONNECT, le HTTPS de destination est constitué d’octets TLS, non de contenu de page lisible. Le TLS vers le proxy masque même l’échange initial du proxy sur ce lien. Utilisez les diagnostics client et proxy pour les transactions interprétées, et protégez les journaux susceptibles de contenir des identifiants ou des URL sensibles.

Articles similaires