Je voudrais avoir quelques precisions sur un point assez precis du
protocole SOCKS. J'espere ne pas trop me tromper d'endroit.
Je voulais connaitre le comortement que doit adopter un client qui se
connecte à un serveur SOCKS et qui desire utiliser SSL pour se connecter
au serveur distant par l'intermediaire du serveur SOCKS.
Typiquement un browser qui veut acceder a une page securisee.
Le client ne peut pas faire directement la negociation entre lui et le
serveur distant. S'il ne fait pas de negociation, je ne vois pas comment
encrypter le flux.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel Arboi
On Fri Jul 01 2005 at 21:10, John wrote:
Je voulais connaitre le comortement que doit adopter un client qui se connecte à un serveur SOCKS et qui desire utiliser SSL pour se connecter au serveur distant par l'intermediaire du serveur SOCKS.
SOCKS est un proxy TCP (et éventuellement UDP pour SOCKS5). Il ne contrôle pas le contenu de la connexion.
Le client ne peut pas faire directement la negociation entre lui et le serveur distant.
Le client envoie au serveur SOCKS une requête de connexion vers "toto:443", et ensuite, il fait la négociation SSL normalement.
En détail : (appelons A le client, B le proxy SOCKS, C le serveur web) A se connecte sur B:1080 A négocie une méthode d'authentification (en SOCKS5) et montre patte blanche. En SOCKS4 cette phase n'existe pas. A envoie sur la socket "connect C:443" B se connecte sur C:443 et renvoie "OK" à A (ou échec, si ça foire). À partir de ce moment, B se contente de recopier les données entre A et C et n'intervient plus. A lance la négociation SSL avec C, B se contentant de transférer les octets.
S'il ne fait pas de negociation, je ne vois pas comment encrypter le flux.
Le flux entre le client et le serveur web (relayé par le proxy SOCKS) est chiffré. Ce qui est en clair, c'est la connexion client -> proxy SOCKS pour l'authentification et l'envoi de la commande. On doit pouvoir faire du SOCKS sur SSL, comme du n'importe quoi sur SSL, mais je ne suis pas sûr que ça présente un intérêt majeur.
On Fri Jul 01 2005 at 21:10, John wrote:
Je voulais connaitre le comortement que doit adopter un client qui se
connecte à un serveur SOCKS et qui desire utiliser SSL pour se
connecter au serveur distant par l'intermediaire du serveur SOCKS.
SOCKS est un proxy TCP (et éventuellement UDP pour SOCKS5). Il ne
contrôle pas le contenu de la connexion.
Le client ne peut pas faire directement la negociation entre lui et le
serveur distant.
Le client envoie au serveur SOCKS une requête de connexion vers
"toto:443", et ensuite, il fait la négociation SSL normalement.
En détail :
(appelons A le client, B le proxy SOCKS, C le serveur web)
A se connecte sur B:1080
A négocie une méthode d'authentification (en SOCKS5) et montre patte
blanche. En SOCKS4 cette phase n'existe pas.
A envoie sur la socket "connect C:443"
B se connecte sur C:443 et renvoie "OK" à A (ou échec, si ça foire). À
partir de ce moment, B se contente de recopier les données entre A et
C et n'intervient plus.
A lance la négociation SSL avec C, B se contentant de transférer les
octets.
S'il ne fait pas de negociation, je ne vois pas comment encrypter le
flux.
Le flux entre le client et le serveur web (relayé par le proxy SOCKS)
est chiffré. Ce qui est en clair, c'est la connexion client -> proxy
SOCKS pour l'authentification et l'envoi de la commande.
On doit pouvoir faire du SOCKS sur SSL, comme du n'importe quoi sur
SSL, mais je ne suis pas sûr que ça présente un intérêt majeur.
Je voulais connaitre le comortement que doit adopter un client qui se connecte à un serveur SOCKS et qui desire utiliser SSL pour se connecter au serveur distant par l'intermediaire du serveur SOCKS.
SOCKS est un proxy TCP (et éventuellement UDP pour SOCKS5). Il ne contrôle pas le contenu de la connexion.
Le client ne peut pas faire directement la negociation entre lui et le serveur distant.
Le client envoie au serveur SOCKS une requête de connexion vers "toto:443", et ensuite, il fait la négociation SSL normalement.
En détail : (appelons A le client, B le proxy SOCKS, C le serveur web) A se connecte sur B:1080 A négocie une méthode d'authentification (en SOCKS5) et montre patte blanche. En SOCKS4 cette phase n'existe pas. A envoie sur la socket "connect C:443" B se connecte sur C:443 et renvoie "OK" à A (ou échec, si ça foire). À partir de ce moment, B se contente de recopier les données entre A et C et n'intervient plus. A lance la négociation SSL avec C, B se contentant de transférer les octets.
S'il ne fait pas de negociation, je ne vois pas comment encrypter le flux.
Le flux entre le client et le serveur web (relayé par le proxy SOCKS) est chiffré. Ce qui est en clair, c'est la connexion client -> proxy SOCKS pour l'authentification et l'envoi de la commande. On doit pouvoir faire du SOCKS sur SSL, comme du n'importe quoi sur SSL, mais je ne suis pas sûr que ça présente un intérêt majeur.
