Aller au contenu
TortueTech
RubriquesGlossaire

Proxy : Serveur mandataire

Réseau

Intermédiaire qui relaie les requêtes pour le compte d'un tiers : côté clients (proxy direct) pour sortir vers Internet, ou devant une application (proxy inverse) pour recevoir le trafic à sa place. Dans les deux cas, chaque partie parle à l'intermédiaire et jamais directement à l'autre.

Schéma de séquence entre trois acteurs : le poste, le proxy direct et le serveur. Étape 1 : le poste envoie au proxy CONNECT exemple.fr:443. Étape 2 : le proxy ouvre la connexion TCP vers le serveur. Étape 3 : le proxy répond au poste 200 Connection Established. Ensuite, deux cas. Sans interception, le TLS chiffré passe dans un tunnel du poste au serveur et le proxy ne relaie que des octets. Avec l'interception active, le TLS s'arrête au proxy, qui présente un certificat signé par l'autorité interne, puis le proxy ouvre une nouvelle session TLS vers le serveur et peut lire le contenu.

Proxy direct (sortant) : Placé du côté des postes, il relaie leur trafic vers l'extérieur, applique le filtrage et journalise les accès. On le déclare par les variables HTTP_PROXY et HTTPS_PROXY (NO_PROXY liste les destinations qui le contournent) ou par un fichier PAC (Proxy Auto-Config), une fonction JavaScript FindProxyForURL qui choisit le proxy URL par URL ; pour HTTPS, le client ouvre un tunnel avec la méthode CONNECT.

Proxy inverse : Placé devant une ou plusieurs applications, il termine TLS, route selon le nom d'hôte ou le chemin et transmet l'adresse d'origine dans X-Forwarded-For. Rien n'oblige cet en-tête à dire la vérité, puisque n'importe quel client peut l'écrire lui-même : une application qui le croit sans vérifier qu'il vient de son propre proxy accorde sa confiance au premier client capable de taper une ligne de plus.

Ce que l'intermédiaire voit : En HTTP non chiffré, il voit tout. Derrière un tunnel CONNECT, il voit la destination (hôte et port demandés dans le CONNECT, ou le nom annoncé dans le SNI quand il intercepte sans être déclaré), les volumes et les horaires, mais pas le contenu, sauf interception TLS avec une autorité de certification installée sur les postes ; un proxy inverse qui termine TLS voit, lui, toutes les requêtes en clair.

Voir aussi :SquidNginxWAFSWGTLS

Ce qui arrive si on s'en passe

Sans proxy direct, chaque poste sort vers Internet par ses propres connexions. Le pare-feu doit alors autoriser le trafic sortant de toutes les machines, aucun point unique ne filtre les destinations et aucun journal central ne relie une requête sortante à son émetteur. Un logiciel malveillant peut ainsi joindre son serveur de commande ou faire sortir des fichiers sans passer par aucun contrôle. Sans proxy inverse, l'application reçoit le trafic en direct : son adresse réelle, son logiciel serveur et ses en-têtes sont visibles, et toute requête malformée atteint son code sans tri préalable. Le chiffrement TLS, la limitation de débit et la journalisation doivent alors être gérés application par application, au risque d'en oublier une. Enfin, remplacer ou redémarrer un serveur devient visible pour les clients, puisqu'aucun intermédiaire ne peut rediriger le trafic.

Explication de la marmotte

Imaginons le gardien d'un grand immeuble. Les habitants ne postent pas leurs lettres eux-mêmes : ils les lui confient, et c'est lui qui les envoie. Il peut refuser certaines adresses et noter qui écrit à qui. Si la lettre est dans une enveloppe fermée, il lit l'adresse, mais pas ce qu'il y a dedans. Il existe aussi le cas inverse : l'accueil d'une entreprise, où tous les visiteurs se présentent d'abord à la même hôtesse, qui les oriente vers le bon bureau. Le visiteur ne sait pas où se trouvent vraiment les bureaux, et l'entreprise n'a qu'une seule porte d'entrée à surveiller.

Où ce terme est utilisé

← Tout le glossaire