Plongée approfondie dans ce qu'est un Forward Proxy

Nous utilisons couramment NGINX ou Apache comme équilibreurs de charge et serveurs proxy inversés, même lorsque le trafic réseau externe est acheminé via ce logiciel pour atteindre les services réels au sein du réseau interne. Bien qu'il existe un proxy inversé, il existe également un proxy direct. Explorons leurs fonctionnalités.

Du modèle OSI aux serveurs proxy

Lorsque nous accédons à des services internet, nous utilisons généralement le protocole HTTP, qui opère au niveau 7 du modèle OSI. Les composants familiers de ce protocole, tels que les noms d'hôte, les chemins et les paramètres de requête, font partie de cette couche. Le protocole HTTP est construit sur les protocoles TCP ou UDP, qui fonctionnent au niveau 4 du modèle OSI, et les concepts de ports utilisés lors de l'accès aux services existent dans ces protocoles. Plus loin, TCP et UDP sont basés sur le protocole Internet (IP), qui opère au niveau 3 du modèle OSI, où les adresses IP servent de "numéros de maison" sur internet.

Lorsque nous utilisons un réseau IP pour accéder à internet, le protocole IP est responsable de l'adressage de la cible, de l'encapsulation des paquets de données selon des règles, et de leur acheminement de l'adresse source à l'adresse de destination au sein du réseau IP. Par exemple, le trafic réseau voyage du réseau local d'un visiteur via le dispositif de passerelle fourni par le FAI, se connectant au réseau du FAI avant d'accéder aux services d'un fournisseur de ressources.

À ce stade, nous utilisons une passerelle pour accéder à internet. Lorsque nous parlons de serveurs proxy, nous pouvons établir un parallèle avec le réseau IP. Les serveurs proxy agissent comme des passerelles, comblant le fossé pour aider les clients à accéder aux services. Ils opèrent essentiellement entre les niveaux 4 et 7 du modèle OSI, et en fait, ils relèvent du niveau 5 du modèle OSI.

Objectifs des serveurs proxy

Les serveurs proxy sont généralement utilisés pour les objectifs suivants :

1. Sortie centralisée pour l'accès au réseau interne

Les entreprises ont souvent des exigences en matière de sécurité de l'information, telles que le contrôle d'accès et l'enregistrement du trafic. Avec la prévalence du trafic crypté comme HTTPS, masquer le trafic réseau sous des mots de passe rend difficile l'enregistrement et l'audit à la frontière du réseau, augmentant le risque de fuites. L'existence d'un serveur proxy sert de sortie de trafic unifiée, agissant comme un intermédiaire pour gérer les tâches d'audit du trafic.

Outre les objectifs orientés vers l'humain, les services proxy peuvent également servir de sortie pour les services programmatiques accédant au réseau externe. Par exemple, lorsqu'un fournisseur de services offre une fonctionnalité de webhook, il doit canaliser le trafic via une sortie fixe, utilisant une seule adresse IP fixe ou une plage d'adresses IP fixes. Cela facilite la mise en liste blanche correcte des appels webhook par le destinataire dans le pare-feu. Le fait de ne pas le faire expose les deux parties des appels webhook à des risques de sécurité potentiels.

2. Masquage de l'identité du visiteur

Parfois, les utilisateurs d'internet peuvent souhaiter masquer leur identité, telle que leur adresse IP. Dans ce cas, les serveurs proxy transparents entrent en jeu. Le client se connecte d'abord au serveur proxy, spécifiant l'adresse réelle du service à connecter, puis accède au service cible via le serveur proxy en utilisant le protocole HTTPS. La présence du serveur proxy garantit que l'identité du client reste masquée, tandis que l'utilisation d'un protocole crypté garantit que le serveur proxy ne peut pas voler de données pendant ce processus.

Proxy basé sur HTTP

Sur les serveurs proxy, nous rencontrons généralement des proxies HTTP basés sur HTTP et des protocoles binaires SOCKS 4/5. Ils remplissent des fonctions similaires mais avec des méthodes de mise en œuvre différentes. Concentrons-nous sur les proxies basés sur HTTP.

Dans les premières étapes de la mise en œuvre du protocole, le trafic sur HTTP était principalement en texte clair. Cette transparence permettait aux serveurs proxy situés entre le client et le service de parser facilement les URL et les charges utiles des requêtes. Grâce à la résolution DNS et à des processus similaires, le proxy pouvait se connecter au service en utilisant sa propre adresse réseau, masquant ainsi le client.

Un exemple d'un tel appel est le suivant :

GET http://example.com/resource HTTP/1.1
Proxy-Authorization: Basic encoded-credentials

Le serveur proxy comprend l'adresse que le client tente d'atteindre et envoie une requête au service pour obtenir une réponse, qui est ensuite renvoyée au client.

HTTP/1.1 200 OK
Content-Type: text/html
...
body blahblah
...

Cela représente la forme de mise en œuvre la plus simple d'un serveur proxy HTTP. Cependant, nous observons des inconvénients : le serveur proxy traite le trafic client en texte clair, ce qui pose un risque de sécurité potentiel car il pourrait enregistrer le trafic utilisateur lors du transfert. Par conséquent, la prise en compte de méthodes de cryptage est nécessaire pour garantir la sécurité.

Fonctionnement complexe du trafic HTTPS et des serveurs proxy

Avec l'augmentation de la proportion de trafic HTTPS crypté dans tout le trafic HTTP, les serveurs proxy doivent s'adapter à ce scénario.

Cependant, un défi se pose : le trafic envoyé par le client au fournisseur de services est maintenant crypté. Le serveur proxy ne peut pas comprendre quelle ressource le client essaie d'atteindre par décryptage. En effet, le trafic est protégé par un mécanisme de négociation de clé basé sur des algorithmes de cryptage asymétrique entre le client et le fournisseur de services, et le trafic crypté ultérieur utilise des clés symétriques qui ne peuvent pas être obtenues par un attaquant intermédiaire pendant la communication. L'objectif fondamental de TLS est d'empêcher la possibilité d'attaques de type "man-in-the-middle".

Alors, comment fonctionne le serveur proxy dans ce cas ?

Cela est plus complexe par rapport à la méthode précédente d'analyse de requête en texte clair. Le protocole HTTP a introduit une méthode de requête dédiée CONNECT. Le client utilise cette méthode pour envoyer une requête initiale au serveur proxy :

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: Basic encoded-credentials

Le client envoie une requête CONNECT au serveur proxy, incluant le domaine ou l'adresse IP et le port auxquels le client souhaite se connecter. Lorsqu'il reçoit la requête, le serveur proxy établit une connexion TCP avec le service cible et stocke le mappage de port entre le client et le service. Par la suite, le client peut envoyer la requête correcte au serveur proxy, qui transférera le trafic au service tel quel, sans tenter de parser les données. Par conséquent, la communication cryptée de HTTPS est fiable.

Ce mécanisme, comparé aux proxies HTTP en texte clair, est plus polyvalent. Une fois que la première requête HTTP informe le serveur proxy des informations nécessaires pour établir une connexion, il devient essentiellement un canal proxy transparent. Il peut faciliter la communication pour à la fois le trafic HTTPS et le trafic binaire TCP (comme SSH) via le serveur proxy.