Comment un seul port proxy peut accepter HTTP et SOCKS
Explique comment un écouteur délibérément mixte peut distinguer HTTP de SOCKS, alors qu'un écouteur normal à protocole unique ne le peut pas.
Un écouteur proxy mixte peut accepter HTTP et SOCKS sur un seul port TCP parce que le serveur inspecte les premiers octets du protocole. Le numéro de port n'effectue pas cette détection.
Une requête proxy HTTP commence par une méthode HTTP, comme GET ou CONNECT. Un salut SOCKS commence par des champs de protocole binaires. Un logiciel conçu pour ces entrées peut acheminer la connexion vers le gestionnaire approprié.
C'est une caractéristique d'implémentation explicite. Un écouteur HTTP normal de Squid ne devient pas mixte parce que son port est changé en 1080, et un écouteur uniquement SOCKS n'apprend pas HTTP à partir d'un réglage du navigateur.
TLS ajoute une autre frontière : une connexion proxy chiffrée commence par TLS, et non par une méthode HTTP visible. La prendre en charge sur le même point de terminaison exige un traitement délibéré supplémentaire ; reconnaître HTTP en clair et SOCKS n'établit pas cette capacité.
Utilisez le protocole client documenté pour le point de terminaison. Si les deux fonctionnent, c'est une preuve concernant l'écouteur mixte de ce serveur, pas une raison de laisser le protocole non spécifié dans chaque client.
L'écouteur mixte de Glider fournit un exemple concret : il jette un œil à un octet sans le consommer, envoie 0x05 à son gestionnaire SOCKS5 et, sinon, appelle son analyseur HTTP. Cet analyseur valide toujours la requête entrante ; le choix d'aiguillage ne rend pas une entrée arbitraire valide en HTTP.
Le partage de l'écouteur TCP ne fournit pas en soi l'association UDP de SOCKS5. Glider démarre son écouteur UDP séparément. La sélection du protocole TCP et le relais ultérieur des datagrammes sont des capacités distinctes.