Une chaîne SOCKS plus longue ne masque pas automatiquement le saut suivant

Une chaîne change qui ouvre chaque connexion. Elle n'ajoute pas de chiffrement du seul fait qu'une adresse SOCKS de plus figure dans une liste.

Prenons un client qui construit lui-même cette chaîne :

application → SOCKS A → SOCKS B → website

Il demande d'abord à A de se connecter à B. À travers ce flux, il peut ensuite négocier avec B une connexion au site. Si le transport du client vers A véhicule les deux négociations sans chiffrement, un observateur suffisamment capable sur ce lien peut lire les octets d'installation envoyés par le client. La destination TCP extérieure n'est pas la seule preuve possible pour l'observateur.

Séparez la chaîne de l'échange applicatif protégé

HTTPS peut protéger le contenu applicatif du site une fois sa session TLS commencée. Il ne chiffre pas rétroactivement les messages d'installation SOCKS précédents. L'authentification SOCKS5 par nom d'utilisateur et mot de passe n'est pas non plus un transport chiffré.

Un dispositif chiffré entre le client et le premier saut modifie la visibilité sur ce lien. Il conserve un opérateur et un autre point d'extrémité qui détient le flux déchiffré. Décrivez cette frontière de confiance plutôt que d'affirmer que la chaîne est intraçable.

Une route parente configurée sur le serveur est une autre topologie. Si A choisit B en interne, le client n'a pas forcément envoyé une liste complète d'intermédiaires sur sa première connexion. N'affirmez pas que toute chaîne expose chaque saut de la même manière.

Pour une évaluation utile de la vie privée, nommez l'observateur, le lien, la négociation avec le proxy et les frontières TLS. Le site qui observe la sortie de B et l'observateur du réseau d'accès qui surveille la première connexion du client répondent à des questions différentes. Compter les sauts ne répond à aucune des deux.