SOCKS5 est un protocole de proxy qui relaye le trafic TCP et UDP entre un client et un serveur sans lire les données de l'application, il fonctionne donc avec toute application qui prend en charge SOCKS, pas seulement les navigateurs web. Il est défini dans la RFC 1928, prend en charge l'authentification par nom d'utilisateur/mot de passe et ne chiffre pas le trafic par lui-même.

Parce que SOCKS5 fonctionne entre les couches d'application et de transport au lieu d'analyser HTTP, il n'est pas limité au trafic web. Si votre cas d'utilisation nécessite SOCKS5, il vaut la peine de confirmer qu'un fournisseur le prend en charge avant de s'engager.

Comment fonctionne une connexion SOCKS5

  1. Le client se connecte au proxy, conventionnellement sur le port TCP 1080, et liste les méthodes d'authentification qu'il prend en charge.
  2. Le proxy en choisit une, comme aucune authentification ou nom d'utilisateur/mot de passe, et le client s'authentifie.
  3. Le client envoie la destination sous forme d'adresse IPv4, d'adresse IPv6 ou de nom de domaine. Il utilise CONNECT pour TCP ou UDP ASSOCIATE pour UDP.
  4. Le proxy ouvre la connexion et relaye les données dans les deux sens.

Pour UDP, le proxy répond avec l'adresse d'un relais UDP. Le client envoie ses datagrammes là-bas, et l'association dure seulement aussi longtemps que la connexion TCP qui l'a établie.

SOCKS5 vs. SOCKS4

SOCKS5 étend l'ancien protocole SOCKS4 :

  • Authentification : SOCKS4 n'a qu'un champ d'identifiant utilisateur. SOCKS5 ajoute des méthodes telles que nom d'utilisateur/mot de passe et GSSAPI.
  • UDP : SOCKS4 gère uniquement TCP. SOCKS5 peut également relayer UDP.
  • IPv6 : SOCKS4 n'accepte que les destinations IPv4. SOCKS5 ajoute IPv6.
  • Noms d'hôtes : SOCKS5 permet au client d'envoyer un nom de domaine que le proxy doit résoudre. SOCKS4 a besoin de l'extension SOCKS4a pour le faire.

SOCKS5 vs. Proxy HTTP

Un proxy HTTP lit chaque requête HTTP et peut ajouter des en-têtes tels que Via. Un proxy SOCKS5 relaye des octets sans les lire, il peut donc également transporter du trafic non web. L'entrée du Proxy HTTP a un tableau côte à côte.

Authentification et chiffrement

  • Méthodes requises : La RFC 1928 stipule que les implémentations conformes doivent prendre en charge GSSAPI et devraient prendre en charge nom d'utilisateur/mot de passe.
  • Mots de passe en clair : la méthode nom d'utilisateur/mot de passe, définie dans la RFC 1929, envoie le mot de passe non chiffré. La RFC ne le recommande pas là où le trafic peut être intercepté.
  • Pas de chiffrement propre : SOCKS5 ne chiffre pas les données qu'il relaye. Le trafic HTTPS reste chiffré car TLS fonctionne entre votre application et le site web.

Où se produisent les recherches DNS

  • curl : une URL de proxy socks5:// résout les noms d'hôtes sur votre machine. socks5h:// fait résoudre les noms d'hôtes par le proxy.
  • Chrome : Les noms d'hôtes SOCKS5 sont toujours résolus au niveau du proxy. Pour SOCKS4, Chrome les résout sur le client.

Une recherche effectuée sur votre propre machine peut révéler les sites que vous visitez à votre résolveur DNS local, ce qui constitue une fuite DNS.

Ce que cela signifie pour le scraping web

  • Chrome ne peut pas se connecter à SOCKS5 : La documentation de Chrome indique qu'il ne prend en charge aucune méthode d'authentification SOCKS5 et utilise SOCKS5 uniquement pour les requêtes TCP. Pour Chrome sans tête, utilisez l'authentification basée sur l'IP ou un proxy HTTP avec des identifiants.
  • Conservez les recherches sur le proxy : utilisez socks5h:// dans curl afin que les requêtes DNS passent par le proxy au lieu de votre réseau.
  • Testez avec SSH : ssh -D <port> fait agir OpenSSH comme un serveur SOCKS4 et SOCKS5 local, ce qui est un moyen rapide d'essayer une configuration SOCKS.

Termes associés