Proxy SOCKS v4a

Les applications du réseau protégé derrière le pare-feu qui souhaitent accéder à des serveurs extérieurs doivent se connecter via un serveur proxy de type SOCKS. Un tel serveur décide de l'éligibilité du client à accéder au serveur externe et transmet sa requête au serveur. SOCKS 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 SOCKS est devenu de fait un protocole public. Le protocole a été amélioré dans sa version 4. La version 4a, « officieuse », ajoute le support des serveurs de résolution de noms à SOCKS.

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.