Les applications du réseau protégées derrière le pare-feu qui souhaitent accéder à des serveurs extérieurs doivent se connecter via un serveur proxy utilisant le protocole SOCKS. Un tel serveur décide de l'éligibilité du client à accéder au serveur externe et transmet sa requête au serveur. Le protocole peut également être employé de manière inverse, permettant aux applications à l'extérieur de se connecter aux serveurs derrière le pare-feu.
Le protocole a été à l'origine développé par David Koblas, un des administrateurs système de la société MIPS. L'année du rachat de MIPS par Silicon Graphics, en 1992, Koblas a présenté un papier sur SOCKS à un colloque sur la sécurité Usenix, et SOCKS est devenu de fait un protocole public. Le protocole a été amélioré dans sa version 4 par Ying-Da Lee de la société NEC.
L'actuelle version 5 du protocole, spécifiée dans la RFC 1928, étend la version précédente en ajoutant la possibilité de transmettre de l'UDP, permet l'authentification, la résolution des noms de domaines par le serveur SOCKS lui-même, et IPv6.
L'architecture et l'application cliente de référence sont la propriété de Permeo Technologies.
D'après le modèle OSI, le protocole SOCKS est une couche intermédiaire entre la couche applicative et la couche transport[réf.souhaitée].
La mise en forme de cette section ne suit pas les recommandations de Wikipédia(mars 2023): découvrez comment la «wikifier».
3proxy - Open source - Gratuit - Toutes plateformes
WinGate - Non Open source - Payant - Uniquement sous Windows
OpenSSH - Open source - Gratuit - Plateformes POSIX
DeleGate - Propriétaire[1] - Gratuit - Toutes plateformes
Antinat - Open source - Gratuit - Toutes plateformes
srelay - Open source - Gratuit - Plateformes POSIX
sSocks - Open source - Gratuit - Plateformes POSIX
PuTTY Tunnel de type Dynamic - Open Source - Gratuit - Uniquement sous Windows
Il existe des programmes permettant de socksifier[2] d'autres applications, ce qui permet à n'importe quel logiciel possédant des capacités réseau d'utiliser SOCKS, même s'il n'est pas prévu pour supporter SOCKS.
Les deux derniers champs contiennent des valeurs arbitraires, que le protocole invite a ignorer.
À partir de ce point toutes les données, envoyées dans ce flux TCP seront transférées sur le port 80 à l'adresse 66.102.7.99
La valeur 0x02 ("bind") pour le deuxième champ de la requête permet l'ouverture de connexions entrantes pour les protocoles tels que le FTP en mode actif.
SOCKS v4a
SOCKS 4a est une simple extension au protocole SOCKS 4 qui permet à un client qui ne peut pas résoudre le nom de domaine de l'hôte de destination de l'indiquer dans sa requête.
Le client doit mettre les trois premiers octets de l'adresse IP de destination à NULL et le dernier octet à une valeur différente de NULL (cela correspond à une adresse IP du type 0.0.0.x, avec x une valeur différente de 0, ce qui n'est pas une adresse valide et qui n'aurait donc jamais pu être utilisée si le client avait pu résoudre le nom de domaine). Le client doit ensuite envoyer le nom de domaine de destination après l'octet NULL qui termine le nom d'utilisateur et le terminer par un autre octet NULL. Cela est utilisé de la même manière pour les requêtes "connect" et "bind".
Une connexion SOCKS avec demande de résolution de nom de domaine se présente comme suit:
Du client vers le serveur
champ 1: Version du protocole, 1 octet, 0x04 pour cette version
champ 2: octet de commande, 1 octet:
0x01 = établir un pipe TCP/IP
0x02 = établir une correspondance de port TCP
champ 3: numéro de port, (sur 2 octets, big endian)
champ 4: adresse IPv4 (sur 4 octets) délibérément invalide, les premiers octets doivent être 0x00 et le dernier doit être différent de 0x00
champ 5: chaîne d'authentification de l'utilisateur (ascii, longueur variable, terminée par un NULL)
champ 6: nom de domaine de l'hôte à contacter (ascii, longueur variable, terminé par un NULL)
Puis du serveur vers le client
champ 1: constante 0x0
champ 2: octet de statut:
0x5a = requête acceptée
0x5b = requête rejetée ou erreur
0x5c = requête échouée car le client n'a pas lancé le démon identd (ou identd n'est pas accessible par le serveur)
0x5d = requête échouée car le service identd du client n'a pas authentifié la chaîne envoyée dans la requête.
champ 3: numéro de port, 2 octets
champ 4: adresse IPv4, 4 octets
Un serveur supportant le protocole 4a doit examiner l'adresse IP de destination dans la requête. S'il s'agit d'une adresse 0.0.0.x avec x non nul, le serveur doit lire le nom de domaine indiqué par le client dans le paquet. Il doit ensuite résoudre lui-même le nom de domaine et établir la connexion si possible.
SOCKS v5 est une extension de SOCKS v4 qui offre davantage de possibilités d'authentification ainsi que le support de l'UDP. La poignée de main initiale consiste en la procédure suivante:
Le client se connecte et envoie une annonce qui inclut une liste de méthodes d'authentification qu'il supporte.
Le serveur choisit l'une de ces méthodes ou envoie une erreur si aucune méthode n'est acceptable.
Plusieurs messages sont alors échangés selon la méthode d'authentification choisie.
Une fois authentifié le client envoie une requête de connexion similaire mais différente du protocole SOCKS v4.
Le serveur répond d'une manière similaire à SOCKS v4.
Les méthodes d'authentification supportées sont numérotées comme suit: