Asio exige un échange SOCKS5 après la connexion au proxy

Connecter un socket TCP Asio à un écouteur SOCKS5 ne franchit qu'une étape : la connexion TCP vers cet écouteur. Cela ne demande pas au proxy de se connecter au serveur final. Pour un test autorisé sur une cible publique, la liste de proxys SOCKS5 propose des candidats pour ce premier point de terminaison TCP ; le connecteur doit néanmoins exécuter l'échange ci-dessous.

Un connecteur SOCKS5 doit ensuite dérouler l'échange du protocole :

1. Envoyer un salut de version 5 énumérant les méthodes d'authentification prises en charge par le client.
2. Lire la méthode retenue et exécuter son échange d'authentification lorsqu'il est requis.
3. Envoyer CONNECT avec le type d'adresse de la destination, l'adresse et le port dans l'ordre des octets réseau.
4. Lire la réponse, vérifier sa version et le code de résultat, puis consommer l'adresse liée et le port complets, de longueur variable.
5. Remettre le flux établi au protocole de l'application.

Un auxiliaire nommé socks5::async_proxy_connect appartient à l'implémentation SOCKS qui fournit cet auxiliaire. Le citer à côté de boost::asio n'en fait pas une partie de l'interface de socket TCP d'Asio.

Les lectures TCP peuvent ne renvoyer qu'une partie d'une réponse. Composez des lectures pour les nombres d'octets requis, puis choisissez la longueur restante dans le champ de type d'adresse. Ne supposez pas que chaque réponse de serveur possède la disposition IPv4 fixe.

Pour HTTPS, effectuez la poignée de main TLS vers la destination après la réussite de SOCKS CONNECT, en conservant le SNI et la vérification du nom d'hôte de la destination. Une réponse de proxy réussie ne suffit pas à authentifier le site web.

Conservez l'annulation et les échéances sur toute la séquence d'établissement. Si le délai d'établissement de la connexion TCP expire, les échanges ultérieurs de salut, d'authentification et de CONNECT restent sans limite.