Le protocole SOCKSv4 définit un format de message et des conventions pour permettre à des utilisateurs d’applications TCP un accès transparent au travers d’un pare-feu.
Pendant l’établissement de la connexion proxy, le serveur SOCKS accorde l’accès en se basant sur les informations d’entête de TCP, y compris les adresses IP, et les numéros de ports des hôtes source et destination.
Le serveur SOCKS autorise également les utilisateurs sur la base des informations d’identification (rfc1413).
La communauté des utilisateurs SOCKS a proposé et mis en œuvre une extension protocolaire à SOCKSv4 qui permet de se passer de la contrainte qu’ont les clients SOCKSv4 à résoudre les noms de domaine internes et externes.
En ajoutant les noms de domaine non résolus aux requêtes du client SOCKSv4, les serveurs SOCKSv4 peuvent tenter de résoudre les noms de domaine.
Grâce à sa simplicité, SOCKSv4 est très utilisé comme pare-feu réseau.
Cependant deux faiblesses majeures existent dans le protocole SOCKSv4 :
- le manque d’authentification forte, et
- la contrainte de recompilation des applications avec la librairie cliente SOCKSv4.
Un groupe de travail de l’IETF (Internet Engineering Task Force) a produit et approuvé une nouvelle version de SOCKS, SOCKSv5.
Le groupe de travail a complété trois standards liés à SOCKSv5 : les rfc1928, rfc1929 et rfc1961.
Networking Systems Laboratory (NWSL), anciennement C&C Software Technology Center (CSTC) de NEC USA Inc., a développé la mise en oeuvre publique la plus populaire.
Elle inclut le serveur SOCKSv4 et des versions "socksifiées" de finger, whois, ftp et telnet.
RSS 2.0