Le proxy HTTP

Le principe de base consiste à dire :

Lorsque je désire obtenir un document, je ne vais pas le demander à la source. Je vais le demander à mon serveur proxy. Celui-ci ira chercher le document à ma place et me le transmettra à sa réception. Au passage, il le gardera en mémoire « un certain temps », si bien que si un autre client redemande dans cette période le même document, le proxy n'aura pas besoin de retourner le chercher à la source. Ceci ne fonctionne correctement que pour les documents statiques, bien entendu. Pour les documents de type ASP, JSP ou PHP, la mise en tampon est beaucoup plus problématique.

Ce type de fonctionnement, où le client s'adresse systématiquement au proxy pour obtenir une page quelconque sur le web a fait traduire « proxy server » par « serveur mandataire ».

Notez que dans cette démarche, le client est au courant de l'existence du proxy, il va donc envoyer une requête adaptée à la situation, qui n'est pas tout à fait la même que dans le cas où il s'adresserait directement à la cible. Nous le verrons en détail un peu plus loin.

Imaginons un cas simple :

• nous sommes dans un lycée technique, les étudiants qui sont dans un laboratoire, disposent chacun d'un poste informatique. Tous ces postes sont en réseau local, avec un accès à l'Internet partagé par un routeur NAT ;
• tous les étudiants doivent consulter un document, disons, chez Texas Instrument ;
• il y a 14 postes, il y aura 14 requêtes identiques vers le serveur de TI et 14 envois de documents identiques vers les clients.
  

Nous remplaçons le routeur NAT par un serveur Proxy. Dans ce cas :

• la première requête sera transmise par le proxy vers le serveur de TI ;
• les 13 autres seront servies directement par le cache du proxy.

Un seul transfert de page depuis le serveur Texas Instruments vers le réseau local en remplace 14.

Parmi nos 14 élèves, il y en aura bien un qui aura l'idée, en passant, d'aller faire un petit tour sur par exemple http://www.canalcharme.com ou pire. N'y voyez pas de puritanisme de ma part, juste un souci d'efficacité dans le travail et une obligation légale de protection des mineurs…

• Avec un routeur NAT, le filtrage va être difficile, parce que le seul moyen « simple » serait de filtrer au niveau de l'IP du serveur.
• Avec un proxy comme SQUID, qui travaille au niveau HTTP et qui voit donc passer les URI, il existera une foule de solutions qui permettront un filtrage :
  • par mot clé sur les URL ;
  • par bannissement de domaines ou d'URI référencés dans une base de données.

Parce qu'il y en a tout de même…

• La durée de vie du cache et les mauvais paramétrages entraînent que les documents reçus peuvent ne plus être à jour.
• A multiplier les proxy en chaîne, on amplifie ce problème et on court aussi le risque de recevoir des documents falsifiés. En effet, s'il est intéressant de monter un proxy en tête d'un réseau local, il faut savoir que les FAI peuvent en utiliser aussi, de façon plus ou moins transparente (nous verrons ça plus loin). Un serveur proxy, ça peut être piraté et « bricolé »…

Il faut commencer par paramétrer son navigateur Internet pour qu'il fasse appel à un proxy. Nous comprendrons mieux pourquoi en analysant le réseau.

Pour Firefox, c'est assez simple :

Menu « Edition » sous GNU/Linux ou « Outils » sous Windows, commande « Préférences… », Option « Avancé », onglet « Réseau » : Utilisez le bouton « Paramètres » de la connexion.

Ne faites pas confiance aux systèmes automatisés dans la mesure du possible et indiquez plutôt explicitement les paramètres du proxy :

• Son adresse IP (ou son URL) ;
• Le port sur lequel il travaille (3128 est le port par défaut pour SQUID).

Vous pouvez éventuellement spécifier des proxy différents suivant les protocoles et dans quelles conditions vous voulez éviter le proxy.

Voilà. Si le proxy est bien configuré, ça devrait fonctionner…

Un proxy est placé entre un réseau local privé et un accès Internet. La configuration est alors la suivante :

Le proxy dispose de deux adresses :

• l'une dans le réseau privé (192.168.0.253 dans l'exemple) ;
• l'autre sur le réseau du FAI (80.8.128.5 dans l'exemple).

Le proxy isole complètement le réseau privé de l'internet. Il ne servira que de serveur mandataire pour les requêtes HTTP (éventuellement aussi FTP). Avec la floraison de services webmail proposée par les fournisseurs de services, cette configuration peut permettre l'accès aux trois services les plus utilisés sur le Net :

• le surf (HTTP) ;
• le téléchargement de fichiers (FTP) ;
• le courrier, pris en charge par l'interface webmail du FAI.

Si l'on se contente de ces trois services, il n'est alors pas nécessaire d'installer de routeur NAT, le proxy suffit. Mais comprenons nous bien : Seuls les protocoles HTTP et FTP passeront, sauf cas de proxy plus particuliers, ce qui n'est pas l'objet de cette présentation.

Le montage adopté n'est pas obligatoirement le plus utile. Il n'y a d'ailleurs pas de connexion Internet mise en œuvre ici. Ce montage est juste fait pour illustrer le travail du proxy, lorsqu'il est utilisé.

Notez bien que 192.168.0.251 (qui est en fait ma passerelle NAT vers le Net, bien que cette fonction ne serve pas ici), est également mon DNS, ça va se voir dans l'exemple.

Le client va demander la page d'accueil du site hébergé sur le serveur HTTP. Il va le faire directement :

No. Source           Destination     Protocol Info
  4 192.168.0.10     192.168.0.251   HTTP     GET / HTTP/1.1
  6 192.168.0.251    192.168.0.10    HTTP     HTTP/1.1 200 OK
  7 192.168.0.10     192.168.0.251   HTTP     GET /tbm.htm HTTP/1.1
  8 192.168.0.251    192.168.0.10    HTTP     HTTP/1.1 200 OK
  9 192.168.0.251    192.168.0.10    HTTP     Continuation
 11 192.168.0.251    192.168.0.10    HTTP     Continuation
 16 192.168.0.10     192.168.0.251   HTTP     GET /home.htm HTTP/1.1
 18 192.168.0.251    192.168.0.10    HTTP     HTTP/1.1 200 OK
 19 192.168.0.251    192.168.0.10    HTTP     Continuation
 23 192.168.0.10     192.168.0.251   HTTP     GET /banniere.htm HTTP/1.1
 24 192.168.0.251    192.168.0.10    HTTP     HTTP/1.1 200 OK
 25 192.168.0.251    192.168.0.10    HTTP     Continuation
 etc...

J'ai volontairement fait disparaître les trames SYN, ACK de TCP, qui ne nous apportent rien dans la compréhension de l'échange. Nous voyons clairement que l'échange se fait entre le client et le serveur HTTP.

Nous paramétrons maintenant notre client pour qu'il utilise le proxy 192.168.0.253. Nous vidons le cache du navigateur et refaisons notre requête. Le proxy est également “tout neuf” son cache est parfaitement vide.

No. Source           Destination     Protocol Info
  4 192.168.0.10     192.168.0.253   HTTP     GET http://gw2.maison.mrs/ HTTP/1.0
    La requête a été faite au proxy et non pas à la cible qui est 192.168.0.251...
    Le proxy, cherche alors l'IP de la cible : (192.168.0.251 est aussi DNS dans l'exemple).
    Notez que le client envoie ici dans sa requête l'URI complet de la cible convoitée
  6 192.168.0.253    192.168.0.251   DNS      Standard query A gw2.maison.mrs
  7 192.168.0.251    192.168.0.253   DNS      Standard query response A 192.168.0.251
    Puis transmet la requête à la cible...
 11 192.168.0.253    192.168.0.251   HTTP     GET / HTTP/1.0
    La cible répond au proxy :
 13 192.168.0.251    192.168.0.253   HTTP     HTTP/1.1 200 OK
    qui retransmet au client:
 15 192.168.0.253    192.168.0.10    HTTP     HTTP/1.0 200 OK
    et ainsi de suite...
 16 192.168.0.10     192.168.0.253   HTTP     GET http://gw2.maison.mrs/tbm.htm HTTP/1.0
 18 192.168.0.253    192.168.0.251   HTTP     GET /tbm.htm HTTP/1.0
 20 192.168.0.251    192.168.0.253   HTTP     HTTP/1.1 200 OK
 22 192.168.0.253    192.168.0.10    HTTP     HTTP/1.0 200 OK
 23 192.168.0.251    192.168.0.253   HTTP     Continuation
 25 192.168.0.253    192.168.0.10    HTTP     Continuation
 26 192.168.0.251    192.168.0.253   HTTP     Continuation
 28 192.168.0.251    192.168.0.253   HTTP     Continuation
 31 192.168.0.253    192.168.0.10    HTTP     Continuation
 35 192.168.0.10     192.168.0.253   HTTP     GET http://gw2.maison.mrs/banniere.htm HTTP/1.0
 37 192.168.0.253    192.168.0.251   HTTP     GET /banniere.htm HTTP/1.0
 41 192.168.0.10     192.168.0.253   HTTP     GET http://gw2.maison.mrs/home.htm HTTP/1.0
 46 192.168.0.253    192.168.0.251   HTTP     GET /home.htm HTTP/1.0
 48 192.168.0.251    192.168.0.253   HTTP     HTTP/1.1 200 OK
 49 192.168.0.251    192.168.0.253   HTTP     Continuation
 51 192.168.0.253    192.168.0.10    HTTP     HTTP/1.0 200 OK
 52 192.168.0.253    192.168.0.10    HTTP     Continuation
 54 192.168.0.251    192.168.0.253   HTTP     HTTP/1.1 200 OK
 56 192.168.0.253    192.168.0.10    HTTP     HTTP/1.0 200 OK
 57 192.168.0.251    192.168.0.253   HTTP     Continuation
 etc...

Bien. Pour l'instant, c'est plutôt nettement plus compliqué et plus lourd qu'une requête directe. Notez au passage que le proxy (Squid dans ce cas), cause HTTP 1.0 et non HTTP 1.1.

Nous pouvons suivre les évènements à travers les logs du serveur SQUID :

192.168.0.10 TCP_MISS/200 1421 GET http://gw2.maison.mrs/ - DIRECT/192.168.0.251 text/html
192.168.0.10 TCP_MISS/200 4365 GET http://gw2.maison.mrs/tbm.htm - DIRECT/192.168.0.251 text/html
192.168.0.10 TCP_MISS/200 1513 GET http://gw2.maison.mrs/banniere.htm - DIRECT/192.168.0.251 text/html
192.168.0.10 TCP_MISS/200 4228 GET http://gw2.maison.mrs/home.htm - DIRECT/192.168.0.251 text/html
etc...

Mais maintenant, le cache du proxy n'est pas vide, il contient désormais ces documents. Nous allons le vérifier immédiatement en :

• vidant le cache local du navigateur ;
• effectuant à nouveau la même requête.

No. Source           Destination     Protocol Info
  4 192.168.0.10     192.168.0.253   HTTP     GET http://gw2.maison.mrs/ HTTP/1.0
  6 192.168.0.253    192.168.0.10    HTTP     HTTP/1.0 200 OK
  7 192.168.0.10     192.168.0.253   HTTP     GET http://gw2.maison.mrs/tbm.htm HTTP/1.0
  8 192.168.0.253    192.168.0.10    HTTP     HTTP/1.0 200 OK
  9 192.168.0.253    192.168.0.10    HTTP     Continuation
 11 192.168.0.253    192.168.0.10    HTTP     Continuation
 16 192.168.0.10     192.168.0.253   HTTP     GET http://gw2.maison.mrs/banniere.htm HTTP/1.0
 18 192.168.0.253    192.168.0.10    HTTP     HTTP/1.0 200 OK
 19 192.168.0.253    192.168.0.10    HTTP     Continuation
 24 192.168.0.10     192.168.0.253   HTTP     GET http://gw2.maison.mrs/home.htm HTTP/1.0
 26 192.168.0.253    192.168.0.10    HTTP     HTTP/1.0 200 OK
 27 192.168.0.253    192.168.0.10    HTTP     Continuation
 etc...

Et là, nous constatons que le dialogue s'effectue uniquement entre le client et le proxy. Autrement dit, le proxy sert au client la totalité des requêtes, il n'y a plus aucun échange entre le proxy et le serveur HTTP.

Vérifions les logs :

192.168.0.10 TCP_MEM_HIT/200 1430 GET http://gw2.maison.mrs/ - NONE/- text/html
192.168.0.10 TCP_MEM_HIT/200 4374 GET http://gw2.maison.mrs/tbm.htm - NONE/- text/html
192.168.0.10 TCP_MEM_HIT/200 1522 GET http://gw2.maison.mrs/banniere.htm - **NONE/- text/html
192.168.0.10 TCP_MEM_HIT/200 4237 GET http://gw2.maison.mrs/home.htm - NONE/- text/html
etc...

TCP_MEM_HIT veut dire que non seulement la réponse est en cache (HIT) mais qu'elle est en mémoire (MEM). Il n'y a donc pas d'interrogation en amont (NONE).

Notez qu'il aurait pu se passer autre chose. Ici, la requête initiale et la seconde requête du client étaient séparées par un intervalle de temps très court. Si cet intervalle avait augmenté, le document ne se serait peut-être plus trouvé dans le cache mémoire, mais dans le cache disque, et il aurait pu se faire que le proxy aille s'assurer auprès du serveur source que son contenu local était encore valide. La stratégie est assez logique :

• un document qui vient d'être téléchargé par le proxy a toutes les chances d'être toujours valide. Il est donc possible de le resservir directement, sans précautions particulières ;
• un document qui a été téléchargé il y a déjà quelques temps, risque d'avoir été modifié. Il convient donc de s'assurer d'abord auprès du serveur source que le document n'a pas été modifié depuis ;
• un document qui a été téléchargé il y a trop longtemps est détruit du cache du proxy. au prochain appel, il faudra le télécharger à nouveau.

Les notions de « vient d'être », « il y a déjà quelques temps » et « il y a trop longtemps » sont bien entendu subjectives et c'est à l'administrateur du proxy de les évaluer efficacement.

Il y a tout de même quelques exceptions à ces règles :

• les documents « actifs » , nous l'avons déjà dit, tels que les pages PHP, ASP, JSP… ou qui viennent de scripts CGI ;
• les documents « passifs », mais qui contiennent un champ « expire » dans leur en-tête. Ce champ, assez peu utilisé, permet au concepteur d'une page de forcer l'attitude d'un proxy à son égard.

Lorsque la connexion entre le réseau local et le Net se fait par un lien  facturé à la durée ou au volume transmis, le gain financier peut être appréciable.

Lorsque la connexion au Net se fait par un lien à faible débit, le gain en temps peut également être très appréciable.

Nous ne le verrons pas ici dans le détail, mais les possibilités de contrôle d'accès au Net sont plus grandes et plus simples à mettre en œuvre avec un proxy qu'avec un routeur. De même, la sécurité du réseau local est plus facilement assurée, si le serveur proxy n'est vraiment qu'un proxy. La solution du proxy n'est cependant pas la panacée et il convient de bien analyser toutes les solutions possibles à un problème donné avant d'en choisir une.

Dans ce que nous avons vu, la présence du proxy est connue des utilisateurs du réseau, ils doivent configurer leur navigateur pour pouvoir l'utiliser.

Il est possible de forcer les utilisateurs à passer par le proxy en bloquant le port 80 sur la passerelle par défaut. L'expérience montre qu'il n'est pas toujours simple de l'expliquer aux utilisateurs, surtout lorsqu'ils sont visiteurs occasionnels.

Techniquement, nous l'avons vu dans les analyses des trames, le client HTTP s'adresse explicitement au proxy et place dans sa requête GET l'URI complet de la cible visée. C'est pour forcer ce type de comportement qu'il faut paramétrer correctement le client HTTP.

L'autre méthode, c'est de laisser le client HTTP dans l'ignorance de l'existence du proxy. Il va alors exécuter un GET « normal » sur l'adresse IP de la cible visée. Pour forcer le passage par le proxy, la passerelle devra alors rediriger cette requête sur le serveur proxy et ce dernier devra savoir retrouver l'adresse de la cible, ailleurs que dans la commande GET, surtout si le client parle HTTP 1.0. La configuration du proxy doit donc tenir compte de ce mode de fonctionnement.

Squid sait fonctionner en mode « transparent », il suffit de le lui demander poliment.

Plus de configuration du client HTTP, donc plus rien de technique à expliquer aux utilisateurs.

L'utilisateur occasionnel (visiteur par exemple), n'aura pas à « bricoler » son client HTTP en entrant et en sortant de votre réseau. Même si pour lui, cette opération est triviale, elle reste tout de même contraignante.

La tentation est grande alors d'oublier de prévenir les utilisateurs qu'ils passent par un proxy et que donc, outre les éventuels décalages entre les pages servies et les pages à jour, toute leur activité se trouve enregistrée dans les logs.

Un proxy transparent ne peut fonctionner que sur un seul port et uniquement pour HTTP :

• les clients qui visent des serveurs sur le port 81 par exemple, passeront directement (ou ne pourront pas passer du tout si votre firewall le leur interdit) ;
• pas de proxy transparent pour FTP ;
• pas de proxy HTTPS (encore que l'on peut s'interroger sur son utilité dans ce cas).

Le serveur proxy peut être une très bonne solution pour partager un accès internet au niveau application, ce qui permet d'effectuer un filtrage au niveau du protocole lui-même. Indispensable lorsque l'on doit donner l'accès à des mineurs, dans le cadre scolaire par exemple.

Une mise en pratique est analysée dans le chapitre « Squid et SquidGuard » dans ce but.