Bonjour,
 
J'ai un probleme avec un fournisseur    
Pour avoir des billes a presenter, je cherche a comprendre comment sont modifiés les messages reseaux quand un proxy est défini.
 
Edit : Message modifié pour etre plus clair.

Mais ou sont les cadors ??

aucun rapport
un proxy n'est pas intégré à un protocole
un proxy EST un protocole (ex: SOCKS)

y'a pas des proxy HTTP ?
Pourquoi dans IE y'a-t'il une ligne pour HTTP et une pour SOCKS ?
Excuse moi de mettre en doute ton info mais bon ...
 
Autre point, dans IE, y'a une option pour activer HTTP1.1 over proxy ?

un proxy HTTP est un logiciel, pas un protocole.
Socks est un protocole dans lequel on peut encapsuler n'importe quel protocole.
Un proxy HTTP n'encapsule rien du tout, il se contente de jouer son role de proxy, à savoir filtrage, cache, etc...
En gros, un proxy HTTP écoute les requêtes sur le port 80, c'est une sorte de passerelle pour le web, et effectue des traitements sur ces requêtes.
Un proxy SOCKS encapsule les données dans son protocole (v4, v5). C'est différent dans le sens où il faut que les données soient encapsulées en SOCKS si on veut les envoyer sur le réseau.
Avec un proxy HTTP, les données sont envoyées comme si elles partaient vers le serveur web de destination, bien qu'elles passent par le proxy.
Avec Socks, le navigateur doit envoyer les requêtes à un client Socks qui va les encapsuler, les envoyer lui même sur le réseau vers un serveur socks qui se chargera de jouer son rôle de proxy.
IE intègre un client Socks, lui permettant de "parler" le protocole Socks et de pouvoir utiliser les proxy Socks.
 
sinon, Outils->Options Internet->Avancé->Paramètres HTTP1.1->Utiliser HTTP1.1 avec une connection par proxy.
 
HTTP1.1 n'est qu'une extension du protocole qui ajoute des types de requêtes (GET, POST et PUT c'était pas assez).
Maintenant meme si je trouve normal que les logiciels comprennent ces requêtes (qu'ils soient compatibles avec la norme), il faut pas non plus être con : un navigateur n'émet jamais rien d'autre que des GET, POST et PUT.
Après, HTTP1.1 introduit quelques rafinements bien utiles, mais ça c'est plus valable pour les serveurs que pour les navigateurs.
Néanmoins pour répondre à ta question, la prise en compte de l'existence des proxy a été intégrée dans la version 1.1 du protocole.
Ceci ne signifie pas que la gestion des proxy est intégrée, ça dit simplement au proxy ce qu'il doit faire et ne pas faire, à condition que le client (le navigateur donc) connaisse et applique ces règles, idem pour le proxy, tout en sachant que MS n'est pas un champion du respect strict des standards.

Merci pour ta réponse mais elle ne répond pas vraiment a la question que je me pose.
Quand tu configures une adresse de proxy dans IE (c'est un exemple, mon probleme n'est pas sur un ordinateur), comment le navigateur emet-il sa requete ?
Il l'envoit au proxy ? si oui, comment est spécifiée l'adresse que l'on demande ? Faut-il passer obligatoirement par une encapsulation socks ou bien y'en a-t'il d'autres ?

ta question change à chaque post
quand tu utilises un proxy socks, ta requête est encapsulée en socks puis passée au proxy socks.
quand tu utilises un proxy http, ta demande est faite telle quelle au proxy; le paquet n'est pas différent de ce que recevrait le serveur web. il est seulement intercepté par le proxy http.
J'avais déjà répondu à ça : "Avec un proxy HTTP, les données sont envoyées comme si elles partaient vers le serveur web de destination, bien qu'elles passent par le proxy."
Si le paquet arrive au proxy, soit c'est parce que c'est précisé dans la conf du navigateur, soit c'est parce que l'architecture du réseau fait en sorte que tout le trafic sortant du réseau passe par une machine qui sert de proxy...
Au niveau des encapsulations, Socks est un protocole dédié à la fonction proxy et il peut encapsuler tout et n'importe quoi. Néanmoins, tout protocole peut servir à encapsuler un autre protocole, il n'y a pas de limite à ce qu'on peut faire, seulement à ce qui existe.
Le truc à la mode c'est l'encapsulation dans HTTP (tunneling) pour passer des protocoles interdits à travers un protocole autorisé.
Bref, pour finir, la fonction de proxy n'a pas de rapport avec l'encapsulation des données, on peut très bien faire un proxy HTTP, il n'y a pas d'encapsulation, néanmoins c'est un proxy quand meme.
Le proxy HTTP agit comme une carte réseau qui sniffe le réseau, il s'occupe de toutes les requêtes HTTP qu'il reçoit, même si évidemment, ce n'est pas son adresse qui est écrite dans le champ Referer.

ALors je vais reposer la question parce que c'est toujours pas bon :

 
Si c'est dans la conf, comment c'est indiqué dans le message reseau ? Si ton proxy est pas transparent, il n'intercepte pas les trames qui ne lui sont pas destinée !!

mais pourquoi tu te prends la tete !
c'est pas indiqué un point c'est tout !
Quand t'as un routeur, tes requêtes HTTP lui sont pas destinées, elles transitent par lui !
bah là c'est pareil, le proxy reçoit la requête, il la lit, ne la transmet pas au serveur car il l'effectue lui-même et te renvoie les résultats.
Toi je sais ce que tu comprends pas, y'a 2 données distinctes dans le paquet qui sort :
- d'une part y'a le champ ip de destination du paquet, qui est l'adresse de ton proxy
- d'autre part, dans la requête HTTP (donc dans le champ data), y'a une ligne Referer qui indique le site web sur lequel la page doit être cherchée.
 
Ces 2 données sont distinctes et non liées.
Quand ton proxy reçoit le paquet, il lit la requête HTTP et l'effectue, puis renvoie le résultat.
Le navigateur a fait une requête HTTP à un serveur mais en passant par le proxy, donc il attend une réponse du proxy.
Toi tu dois penser que quand je fais une requête sur Google, non seulement le Referer c'est http://www.google.fr mais qu'en plus l'ip de destination du datagramme c'est la meme chose.
Ce n'est qu'au moment d'aller chercher vraiment la page web que le champ Referer est évalué par le proxy.
Mais je sens que tout ça n'est pas encore très clair pour toi.
Alors imagine un environnement réseau sans proxy mais avec routeur, je fais une requête depuis mon navigateur pour aller sur Google :
1- ma requête est construite en utilisant le protocole HTTP
2- un segment TCP est construit, avec la requête HTTP dans le champ Data et les port source/destination sont spécifiés
3- un datagramme IP est construit, avec le segment TCP comme Data et les adresses IP source/destination sont spécifiées, à ce moment là, l'ip de destination est www.google.fr
4- une trame Ethernet est construite, avec le datagramme IP dans le champ Data, les adresses MAC source/destination sont spécifiées.
 
Dans notre exemple, la trame Ethernet aura pour MAC source l'adresse MAC de la carte réseau du PC et pour MAC destination l'adresse MAC du routeur.
Le datagramme IP aura pour IP source l'adresse IP privée (192.168.1.0/8) du PC, et pour IP destination l'IP de Google.
Par contre, comme il est impossible d'utiliser une IP privée sur le net, le routeur fera du NAPT et l'IP source du datagramme sur le net prendra la valeur de l'IP attribuée par le FAI.
Au niveau du segment TCP, les ports sont traduits eux aussi par le routeur, la seule certitude étant que le port destination est le port 80 (et ça ne changera pas, meme après la NAPT).
La requête HTTP n'est pas modifiée.
 
Avec un proxy c'est quasiment la meme chose, sauf qu'il y a 2 cas, soit le proxy est placé au niveau du routeur, dans ce cas le proxy est "authoritaire" et on ne peut pas choisir de passer ou pas par lui, c'est obligatoire.
Soit on précise un proxy dans les paramètres du navigateur et tout se passe de la meme façon, excepté que l'ip destination est celle du proxy.
Ensuite le proxy fait la requête lui même et ça se passe comme expliqué plus haut.

Donc si j'ai bien compris, la seule différence entre utiliser un proxy ou non, c'est que l'IP destination est celle du proxy (si on en utilise un) ou celle du site cible (si on va en direct) !
That's it ?

en gros, oui
pour moi la différence c'est que c'est le proxy qui fait la requête au lieu que ce soit moi qui la fasse, mais bon...
en gros, le serveur au final il voit l'ip du proxy ou la tienne, ça a donc l'avantage de l'anonymat.
un proxy c'est avant tout un mécanisme IP, pas un mécanisme protocole (bien qu'un proxy ne comprenne pas n'importe quel protocole au hasard, mais ça c'est du fonctionnement interne).

Merci pour ces explications ...

referers ...

pardon ?

il y a des en-têtes http ki sont modifiés par les proxies (certains sont faits pour d'ailleurs)
 
concrètement, tu peux voir ce que reçoit un site sur :
http://www.samair.ru/proxy/proxychecker/results.htm
ou la totale
http://inet-police.com/cgi-bin/env.cgi

quand on utilise un proxy du genre wingate comment fait t'on pour ouvrir les ports correspndant au jeu online c'est une histoire de mapping ?

je suis d'accord avec toi, à une nuance près :
tu dis que certains proxy sont fait pour modifier les en-tête, c'est inexact, pour fonctionner un proxy DOIT modifier certains en-têtes. Ce n'est pas une fantaisie qu'on peut changer selon l'implémentation.
On peut penser qu'un proxy qui ne modifie aucun en-tête essaie de se faire passer pour le client initial, ce qui serait de mon point de vue une tentative de spoofing (usurpation d'identité).
Quoi qu'il arrive, l'IP du proxy le trahit puisque il n'est pas sensé disposer de la meme IP que le client.
Si le proxy usurpe l'IP du client, ce n'est plus un proxy, c'est un outil de piratage ou de test réseau, cela dépasse largement la notion de proxy.
Pour être tout à fait complet, je dois mentionner l'utilisation de ce genre de technique dans un protocole très connu : FTP.
Lors d'un transfert "Site-to-site" aussi appelé FXP, le client envoie simultanément des commandes à 2 serveurs FTP dans le but d'en mettre un dans l'attente d'une connection et de connecter l'autre au premier pour récupérer un fichier.
Cela est possible car :
- les serveurs acceptent indifféremment des commandes PORT et PASV dans la même session
- les serveurs acceptent une adresse IP différente de celle du client en paramètre de la commande PORT
 
Sur le serveur source, une commande PASV est envoyée, demandant au serveur d'ouvrir lui meme un port sur lequel le client pourra venir se connecter pour récupérer le fichier qu'il a demandé.
Le serveur répond par un message 227 précisant l'ip et le port sur lesquels le client peut se connecter sous la forme (A,B,C,D,X,Y)
A.B.C.D étant l'adresse IP et (256*X + Y) étant le port.
 
Sur le serveur destination, le client envoie une commande PORT ayant comme argument l'ip et le port fournis par le serveur source.
A ce moment, le serveur destination va se connecter sur le serveur source pour recevoir un fichier, comme le laissent penser les instructions envoyées par le client.
Ou alors on peut le dire autrement mais cela revient au meme : le serveur source reçoit une connection du serveur destination sur le port qu'il a ouvert à cet effet, pensant qu'il s'agit du client qui vient prendre son fichier.
Au milieu le client sert d'intermédiaire et il fait croire à chaque partie qu'il s'agit de lui qui est à l'autre bout alors qu'en fait il ne joue qu'un role d'entremetteur.
Meme si cette explication peut sembler un peu hors-sujet, elle illustre bien à mon sens le processus d'usurpation qui sous-tend le fonctionnement des proxy, et elle peut aussi être utile à quelqu'un qui cherche à comprendre le fonctionnement du FXP.

donc pour etre bien sur, au niveau du client (je m'en tape un peu du serveur ), il n'y a que sur l'ip destination qu'il y a un changement entre un connexion directe et une connection par un proxy. Les messages HTTP ne sont pas modifiés ?

Des modifications sur les en-têtes DOIVENT être faites par le proxy, c'est nécessaire au fonctionnement.
Néanmoins, je vois pas en quoi ça peut te poser problème.
Et si tu veux une explication sur les changements, il faut commencer par me dire où tu te places pour observer les changements.
Sur le client, le proxy ou le serveur web ?
Néanmoins, vu la nature de tes questions on voit bien que tu ne maitrises pas du tout la nature du protocole HTTP donc je te conseille d'installer un petit logiciel de type "HTTP Sniffer", de surfer un peu et de regarder ce que ça donne.

Tu me demandes ou je me place : regarde ma question : "AU NIVEAU DU CLIENT" ... difficile d'etre plus clair non ?
De plus ce n'est pas sur un PC que le probleme se pose, mais sur de l'embarqué, et HTTP sniffer ne me servira pas a grand chose.
C'est pour ca que, avant de demander des modifs au fournisseur de la stack, je prefere etre convaincu que les changements sont bien localisés au niveau de la pile IP et non au niveau de l'HTTP (pas le même fournisseur).
D'autre part, pour ce que j'en sais, ce n'est pas du tout le referrer de l'entete http qui indique vers quel site tu veux aller mais plutot d'ou tu viens (ceci etant bien entendu anecdotique )

si, HTTP Sniffer peut t'aider à voir comment est constitué une requête HTTP (en-tête et données) et sa réponse.
Le champ est Host pas Referer, ça m'apprendra à lire mes notes à l'arrache et à poster sans avoir dormi.
Et au fait, au niveau du client, il n'y a aucune modif de faite.
Ton problème c'est de savoir quel type de proxy est utilisé, ça change tout.

faudrait savoir, ca change tout ou bien y'a aucune modif du coté client ?
Malheureusement, je ne peux pas savoir quel type de proxy est utilisé (plusieurs raisons mais c'est un fait qu'il faut accepter tel quel).

tu sais au moins un truc, est-ce que dans ton matériel embarqué on peut préciser l'ip d'un proxy ?

pas pour l'instant. c'est justement dans le cadre de l'ajout de cette possibilité que je veux etre conscient des risques et de la quantité de modifs induites par ce changement.

OOOOOOOOOOOOOOOOOOOOK
bah fallait le dire tout de suite !!!!!
dans ce cas, faut juste changer l'ip de la machine à qui est destinée la requête.
pour le client c'est pareil, en tout cas, une fois que t'as fixé le fonctionnement de ton client HTTP, tu peux le laisser tranquille et travailler sur le proxy jusqu'à ce que tu obtiennes ce que tu veux.

exactement, c'est la recommandation que j'ai faite !