Une façade SOCKS5 peut utiliser un proxy HTTP comme transport d'acheminement. Elle se comporte en serveur SOCKS vis-à-vis du client et en client HTTP CONNECT vis-à-vis du parent. Les deux échanges de contrôle se terminent avant que le flux applicatif ne commence.

La requête SOCKS CONNECT fournit déjà l'hôte ou l'adresse de destination et le port. Pour un échange HTTP/1.1 illustratif avec le parent :

client → adapter: SOCKS5 CONNECT service.example.net:443
adapter → parent:
    CONNECT service.example.net:443 HTTP/1.1
    Host: service.example.net:443

parent → adapter: HTTP/1.1 200 Connection Established
                 [end of headers]
adapter → client: SOCKS5 success reply

client ↔ adapter ↔ parent ↔ service: application bytes

Traduire le résultat à la frontière

L'adaptateur effectue toute authentification exigée par le parent et attend le résultat du CONNECT. Une réponse 2xx réussie établit le tunnel vers le parent. C'est seulement ensuite qu'il doit renvoyer la réponse de succès SOCKS correspondante au client en aval.

Si le parent refuse l'opération, envoyez une réponse d'échec SOCKS définie, puis mettez fin rapidement à la connexion du client. SOCKS5 impose cette fermeture dans les dix secondes suivant la détection de l'échec. Conservez le statut HTTP du parent comme information de diagnostic pour l'adaptateur. Transmettre cette ligne de statut comme données applicatives placerait un message de contrôle HTTP dans un flux dont le client attend un encadrement SOCKS.

Avant un résultat CONNECT réussi, le parent parle encore HTTP, y compris l'encadrement de toute réponse de défi ou d'erreur. Après le délimiteur d'en-têtes d'un résultat réussi, la connexion devient le tunnel ; il n'y a aucun corps de réponse HTTP à consommer d'abord.

Préserver les octets après les en-têtes

Une lecture peut contenir à la fois la fin des en-têtes du parent et des octets provenant de la destination. Conservez ces octets supplémentaires pour l'application en aval. Les protocoles où le serveur parle en premier peuvent saluer dès l'ouverture de leur connexion.

Une fois la réponse de succès SOCKS envoyée, relayez le flux applicatif dans les deux sens. L'adaptateur n'a pas besoin d'alterner un message client avec un message serveur, et il n'a pas besoin de comprendre les enregistrements TLS pour les transmettre. Son travail de protocole consistait à établir et à traduire les deux négociations de tunnel.

Articles similaires