L'une des premières utilisations des proxies HTTP était la mise en cache des proxies afin de mieux utiliser la bande passante coûteuse et d'accélérer la navigation en mettant en cache le contenu très utilisé près de l'utilisateur. Je me souviens d'une époque où les FAI utilisaient des procurations obligatoires explicites pour les utilisateurs. C'était à une époque où la plupart du contenu sur Internet était statique et non spécifique à l'utilisateur et la mise en cache était donc très efficace. Mais même de nombreuses années plus tard, des proxys transparents (c'est-à-dire aucune configuration explicite nécessaire) étaient encore utilisés dans les réseaux mobiles.

Un autre cas d'utilisation majeur et précoce concerne les proxys dans les entreprises. Ceux-ci sont utilisés pour restreindre l'accès et également toujours utilisés pour la mise en cache du contenu. Alors que de nombreux pare-feu de périmètre utilisent des proxys transparents lorsqu'aucune configuration n'est nécessaire, les passerelles Web sécurisées classiques ont généralement au moins la capacité d'exiger un accès proxy explicite (non transparent). Habituellement, tout le trafic n'est pas envoyé via le proxy, c'est-à-dire que le trafic interne est généralement exclu avec une configuration explicite ou en utilisant un fichier PAC qui définit le proxy en fonction de l'URL cible. Un proxy couramment utilisé dans ce domaine est le proxy Squid gratuit qui fournit des ACL étendues, une mise en cache distribuée, une authentification, une inspection de contenu, une interception SSL, etc.

L'utilisation d'un proxy explicite pour le filtrage présente l'avantage qu'une authentification intrabande contre le proxy peut être requise, c'est-à-dire identifier l'utilisateur par son nom d'utilisateur au lieu de l'adresse IP source. Un autre avantage est que la connexion du client se termine au niveau du proxy, et le proxy ne transmet alors la demande au serveur donné dans la demande de proxy HTTP que si la vérification de l'ACL est correcte et peut-être après avoir réécrit des parties de la demande (comme s'assurer que l'en-tête Host correspond en fait à l'hôte cible). Contrairement à cela dans inline-IDS / IPS (qui est la technologie de base dans de nombreux NGFW), la configuration de la connexion du client est déjà transmise au serveur final et les contrôles ACL sont effectués sur la base de l'en-tête Host , qui peut ou non correspondre à l'adresse IP à laquelle le client se connecte. Ceci est en fait utilisé par certaines communications C2 de malware pour contourner le blocage ou la détection en revendiquant un hôte en liste blanche dans l'en-tête Host mais ayant en fait une cible différente comme adresse IP.

Quelques exemples comme suit:

• Pour activer une règle de pare-feu comme "serveur proxy vers n'importe quelle destination sur 80, 443" au lieu de "n'importe quel interne vers n'importe quel externe"
• Surveiller tous les sites Web visités via les journaux
• Pour contrôler, limiter, filtrer les sites Web visités en appliquant des règles - il peut s'agir de listes de sites approuvés, de sites sur liste noire, de catégories de contenu, etc.
• À appliquer l'authentification de l'utilisateur pour utiliser Internet - par exemple limitation aux utilisateurs de domaine, aux détenteurs de certificats
• Vous pouvez avoir des points de sortie séparés pour différents contextes si vous êtes sur VPN, dans un bureau local, sur un poste de travail, sur un serveur

Pour la raison "originale", pensez à 1993, lorsque Netscape 0.9 est sorti. Il avait une boîte de dialogue Options "Mail et Proxies" (d'après une copie du manuel). À cette époque, la plupart des liaisons Internet étaient des lignes T1 à 56 kbit ou fractionnaires entre les campus universitaires et le gouvernement. Un proxy HTTP pouvait aider ou même être requis de plusieurs manières:

• Le navigateur Web pouvait être sur un LAN TCP / IP sans routage (au niveau IP) vers Internet, mais avec un hôte à double domicile sur ce LAN et sur Internet. L'hôte à double hébergement pourrait exécuter un service de proxy HTTP et un service de proxy DNS, permettant aux clients du réseau local d'accéder au Web. (Notez que les RFC décrivant les plages d'adresses privées standard et NAT, RFC 1597 et RFC 1631, n'ont été publiées qu'en mars et mai 1994.)
• Même si le LAN avait des adresses routables, ou même après le déploiement de NAT, la bande passante hors site était probablement bien inférieure à la bande passante locale entre les clients et un emplacement proxy potentiel. Tant que les clients parcouraient une quantité significative du même contenu, statique ou changeant lentement, le proxy améliorait les choses pour les clients (en renvoyant rapidement le contenu mis en cache) ainsi que pour l'opérateur réseau (en libérant de la bande passante pour d'autres des fonctions réseau, ou la réduction des frais d'utilisation des données lorsque la facturation était par paquet ou par octet).
• Si suffisamment d'utilisateurs finaux étaient derrière les proxys, cela prenait l'avantage sur ce que 10 ans plus tard on appellera le " Effet slashdot ": les serveurs d'origine du contenu populaire dans le monde entier n'auraient qu'à le diffuser à chaque proxy, pas à chaque utilisateur final.

Bien sûr, envoyer tout le trafic HTTP via un processus désigné également fait de ce processus un bon point de contrôle pour l'application de la politique de sécurité: filtrage par mots-clés dans le corps de la demande ou de la réponse (décodée); autoriser l'accès uniquement aux utilisateurs qui s'authentifient auprès du proxy; enregistrement.

Oui, certaines organisations "poussent" une politique de proxy vers les appareils des utilisateurs finaux qu'elles contrôlent et l'appliquent par une politique restrictive aux routeurs frontaliers.

Notez également que même si vous pensez que vous vous naviguez sur un réseau "propre", votre trafic peut passer par un proxy; voir par exemple le Transparent Proxy avec Linux et Squid mini-HOWTO.

Mais il est vrai qu'un proxy explicitement configuré peut donner peu d'avantages ou même aggraver la navigation aujourd'hui L'Internet. Lorsque les sites Web populaires utilisent des CDN et que la plupart du contenu est dynamique, même le contenu qui semble pouvoir être mis en cache (comme les tuiles Google Maps et les données vidéo Youtube) varie en fonction de la version du navigateur, du système d'exploitation, de la taille de l'écran ou même d'un cookie aléatoire destiné à le rendre inaccessible, la mise en cache économise peu de bande passante pour un cache près de l'utilisateur final (bien que les serveurs d'origine aient souvent des caches devant eux). Pour le contenu inaccessible, un autre cache ajoute RTT à chaque requête, ce qui ralentit la navigation.

Oui, ils sont fréquemment utilisés dans le monde de l'entreprise. Peut-être moins maintenant que par le passé, mais il y a des années, ils étaient généralement la seule passerelle entre un réseau local et Internet. Dans de nombreux cas, seuls certains utilisateurs de domaine étaient même autorisés à accéder à Internet, et un serveur proxy comme ISA serait configuré à la périphérie du réseau et les utilisateurs devraient s'authentifier pour pouvoir le traverser.

Au-delà de la simple restriction des personnes pouvant accéder à Internet, cela a en effet été utilisé pour le filtrage de contenu, l'inspection du contenu et les rapports sur ceux qui passaient tout leur temps de travail à chercher de nouveaux emplois sur Monster.com. Il y avait également d'autres fonctions non liées à la sécurité, telles que la mise en cache. Il y a 20 ans, il n'était pas rare d'avoir des centaines, voire plusieurs milliers de personnes dans une installation connectée à Internet en utilisant un tuyau relativement petit comme un T-3 fractionnaire, ou même un T-1. Il était très utile de pouvoir mettre en cache du contenu à la périphérie du réseau local afin que la bande passante très limitée du monde extérieur ne soit pas saturée de demandes répétées pour les mêmes ressources.

L'accès aux revues académiques est souvent restreint, et parfois une partie de la restriction est l'adresse IP. En utilisant le serveur proxy de mon université (qui nécessitait une connexion valide), je pouvais accéder aux journaux tout en travaillant à domicile (passé uniquement car je ne l'ai pas essayé depuis quelques années). Je pourrais le configurer uniquement pour les sites Web des éditeurs de revues ou utiliser une extension de commutation de proxy dans Firefox.

Dans ce cas, j'aurais pu utiliser le VPN universitaire, mais celui-ci nécessite un programme client qui ne fonctionne pas sur Linux (et encore moins sur mon Chromebook). Un VPN précédent nécessitait beaucoup de règles de configuration dans une interface utilisateur stupide pour que les choses de base fonctionnent (comme tout courrier électronique non géré par eux).

De plus, il existe des cas d'utilisation pour contrôler le trafic HTTP non-navigateur :

Les fonctionnalités de mise à jour automatique et de "téléphoner à domicile" dans les applications de bureau peuvent être dans une certaine mesure contrôlé en permettant aux navigateurs Web réels, axés sur la viande, d'utiliser un proxy moins restrictif que ce que l'infrastructure réseau permet par défaut.

De la même manière, les serveurs peuvent être contrôlées - alors que certains processus sur un serveur créent un trafic de sortie http légitime, autoriser toutes les sorties http est probablement plus utile pour quelqu'un qui tente de pirater / saboter le serveur. De plus, il est souvent judicieux de documenter tout le trafic de sortie du serveur (ce qu’un proxy peut faire).

De même, les réseaux à faible bande passante (par exemple, satphone ou umts) qui doivent conserver La bande passante utilise souvent des proxys pour réencoder de grandes images et d'autres contenus multimédias qui ne seront pas utiles dans le format haute résolution et à fort trafic donné, en particulier sur les appareils mobiles.