Proxys HTTP et HTTPS

Un proxy HTTP accepte les requêtes web de votre navigateur ou de votre application et se connecte à la destination pour votre compte. Il peut transporter du trafic HTTP ordinaire et, s’il prend en charge la méthode CONNECT, du trafic HTTPS chiffré. Un proxy HTTPS ajoute le chiffrement à la connexion entre votre application et le proxy lui-même.

Ce sont deux choix distincts : la façon dont votre application atteint le proxy et la façon dont elle communique avec le site web à travers ce proxy. Comprendre les deux vous aide à choisir les bons paramètres de connexion. Le choix plus général entre les protocoles proxy est traité dans Proxys SOCKS ou HTTP.

Ce que fait un proxy HTTP avec une requête web

Supposons qu’un script de surveillance demande http://example.com/catalog. Au lieu d’ouvrir une connexion au site web, il se connecte au proxy configuré. Avec HTTP/1.1, il envoie l’URL complète de destination dans sa requête pour que le proxy sache quel serveur et quelle page contacter. Le proxy transmet la requête et renvoie la réponse du site au script.

Dans ce mode, le proxy traite des messages HTTP. Il peut lire la méthode, comme GET ou POST, l’adresse demandée, les en-têtes et les données envoyées. Un logiciel configuré à cet effet peut appliquer des règles d’accès, enregistrer les requêtes ou mettre en cache les réponses admissibles. La mise en cache est une fonction facultative régie par les règles de cache de la réponse ; acheter un accès proxy HTTP ne signifie pas que toutes les pages seront mises en cache.

Le site web reçoit la connexion réseau depuis l’IP de sortie du proxy. Le terme HTTP ne dit rien de l’origine de cette IP ni de la durée de son attribution. Le même protocole de connexion peut être proposé avec des adresses de centre de données, ISP, résidentielles ou mobiles, sous forme d’IP fixes ou de pool rotatif.

Comment un proxy HTTP ouvre un site HTTPS

Un site HTTPS utilise TLS pour protéger l’échange entre l’application et le site web. Pour transporter cet échange, un proxy HTTP crée d’abord un tunnel. Pour une requête vers https://example.com/catalog, la séquence est la suivante :

1. L’application se connecte au proxy et lui demande d’ouvrir un tunnel vers example.com:443 à l’aide de la méthode CONNECT. La requête indique l’hôte et le port de destination, sans le chemin de la page.
2. Le proxy vérifie que l’accès et la destination demandée sont autorisés, y compris l’authentification proxy éventuellement requise. Il ouvre une connexion à la destination et confirme que le tunnel est prêt.
3. L’application effectue une négociation TLS avec le site web à travers le tunnel et vérifie le certificat du site.
4. L’application envoie sa requête web dans cette connexion TLS. Le proxy relaie les octets chiffrés dans les deux sens.

Le proxy n’a pas besoin de lire la page pour la transmettre. L’application et le site web restent les extrémités de la connexion TLS du site. CONNECT fournit le tunnel ; TLS assure le chiffrement et protège l’échange contre les modifications non détectées.

C’est pourquoi un proxy HTTP peut ouvrir un site HTTPS même si l’adresse du proxy commence par http://. La protection HTTPS du site fonctionne à l’intérieur du tunnel. Elle ne dépend pas de l’existence d’une connexion TLS entre l’application et le proxy.

Ce qu’ajoute un proxy HTTPS

Avec un proxy HTTPS, l’application établit d’abord une connexion TLS avec le proxy et vérifie son certificat. Elle envoie ensuite ses requêtes HTTP, ou sa requête de tunnel CONNECT, dans cette connexion protégée. Un observateur du réseau entre l’application et le proxy ne peut pas lire ces requêtes.

Pour une destination HTTPS, l’application maintient deux connexions TLS distinctes : une avec le proxy et une avec le site web à travers le tunnel. Le proxy retire la protection extérieure qui lui est destinée, mais les données du site à l’intérieur restent chiffrées. Il transmet ces octets au site web, qui peut les déchiffrer. Pour une destination HTTP, il n’existe pas de connexion TLS intérieure : seule la connexion au proxy est protégée.

Cette comparaison décrit une transmission proxy ordinaire avec vérification des certificats activée, sans inspection HTTPS ni VPN distinct. Chiffrer la connexion à un proxy ne transforme pas un site HTTP en site HTTPS.

Ce que le proxy et le site web peuvent voir

Pour une destination HTTPS, un proxy de transmission ne peut pas lire le chemin de la page, les paramètres de requête, les cookies, les données de formulaire ou le contenu renvoyé dans la connexion TLS. Il connaît tout de même l’IP du client qui s’est connecté, l’hôte et le port de destination demandés dans CONNECT, ainsi que les horaires et le volume du trafic. TLS jusqu’au proxy masque CONNECT aux observateurs sur cette partie du réseau, mais pas au proxy qui doit traiter la demande.

Les identifiants proxy sont envoyés séparément de ceux du compte web. L’authentification proxy Basic encode le nom d’utilisateur et le mot de passe en Base64, qui peut être décodé sans clé secrète. Sur une connexion proxy HTTP simple, cela ne les protège pas d’un observateur du réseau. La connexion HTTPS du site commence dans le tunnel et ne couvre pas l’authentification proxy antérieure. TLS jusqu’au proxy protège ces identifiants pendant leur transmission.

À l’autre extrémité, le site web reçoit le trafic depuis l’IP de sortie et lit les requêtes qui lui sont destinées. Il peut reconnaître un compte, un cookie de session ou d’autres informations envoyées par l’application. Choisir un proxy HTTPS ne supprime pas ces identifiants et n’améliore pas automatiquement l’acceptation de l’IP de sortie par le site.

L’inspection HTTPS est une autre configuration, utilisée dans certains réseaux administrés et outils de débogage. L’application fait confiance à une autorité de certification contrôlée par le proxy d’inspection, qui peut alors lire le trafic tout en maintenant des connexions TLS distinctes de chaque côté. La transmission normale par CONNECT n’exige pas l’installation d’un tel certificat. Faire confiance au certificat serveur du proxy HTTPS est distinct du fait de l’autoriser à se faire passer pour des sites web.

Comment lire les paramètres de connexion

Un paramètre proxy nécessite une adresse, un port, un protocole de connexion et l’authentification éventuellement requise. Le protocole dans l’URL du proxy s’applique au proxy. Le protocole dans l’URL de destination s’applique au site web.

Ces commandes curl demandent le même site HTTPS par deux connexions proxy différentes. Remplacez le nom d’hôte et le port du proxy par les valeurs fournies pour la méthode de connexion choisie :

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

La première commande se connecte au proxy en HTTP, puis crée CONNECT et la connexion TLS au site web. La seconde établit d’abord TLS jusqu’au proxy HTTPS, puis y fait passer la connexion TLS distincte du site. Dans les deux cas, fournissez aussi l’authentification requise par le service de proxys.

Remplacer simplement http:// par https:// ne transforme pas un port exclusivement HTTP en point de connexion TLS. Si le service fournit un nom d’hôte pour l’accès HTTPS, utilisez-le : le remplacer par une IP peut entraîner une discordance avec le nom du certificat.

Les libellés des applications doivent être lus avec la même attention. Un champ nommé « proxy HTTPS » peut sélectionner le proxy pour les sites HTTPS tout en s’y connectant en HTTP simple. Dans curl, la variable HTTPS_PROXY sélectionne aussi un proxy pour les destinations HTTPS ; sa valeur peut parfaitement commencer par http://. Le libellé indique quelles requêtes utilisent le paramètre, tandis que le schéma de l’URL du proxy indique comment la connexion est établie.

DNS et trafic passant par le proxy

Lorsqu’un client HTTP fournit un nom d’hôte de destination, le proxy recherche normalement son IP et s’y connecte. Le client effectue une résolution distincte s’il a besoin du nom d’hôte du proxy pour l’atteindre. Un navigateur peut aussi émettre des requêtes DNS pour la prédiction ou d’autres fonctions. Ce sont des résolutions distinctes ; configurer un proxy web ne fait pas passer toutes les requêtes DNS par celui-ci.

Le paramètre s’applique au trafic que l’application envoie effectivement au proxy. Un autre programme peut continuer à se connecter directement, et une liste d’exceptions peut contourner le proxy pour certains sites. Par exemple, faire passer un script API par un proxy ne modifie pas le trajet utilisé par un navigateur sans lien avec ce script. Vérifiez l’adresse de sortie depuis l’application et la configuration qui exécuteront la tâche.

HTTP/2 jusqu’au site web et HTTP/2 jusqu’au proxy

HTTP/2 permet à plusieurs échanges de partager une connexion à l’aide de flux distincts. Avec un proxy, il faut savoir quelle connexion le prend en charge. Une application peut négocier HTTP/2 avec un site web dans un tunnel créé au moyen de CONNECT en HTTP/1.1. Le proxy relaie les octets chiffrés et n’a pas besoin de comprendre les messages HTTP/2 du site.

HTTP/2 entre l’application et le proxy est une possibilité distincte. Chaque tunnel CONNECT utilise son propre flux HTTP/2, ce qui permet à plusieurs tunnels de partager une connexion au proxy. Par exemple, les tunnels vers deux sites différents peuvent utiliser cette connexion tout en gardant des connexions de destination et des sessions TLS de site distinctes. Cela réduit le besoin de connexions supplémentaires entre client et proxy ; cela ne permet pas au proxy de lire les requêtes chiffrées destinées aux sites.

Les deux côtés doivent prendre en charge le mode choisi. HTTPS seul n’implique pas HTTP/2 : un proxy HTTPS peut utiliser HTTP/1.1. Les performances dépendent aussi du client, du trajet réseau, de la charge du serveur et de la réutilisation des connexions. Une mention HTTP/2 ne garantit pas un gain de vitesse pour toutes les tâches.

Un tunnel CONNECT ordinaire peut aussi transporter d’autres protocoles fondés sur TCP si l’application et le proxy les autorisent, même si les ports de destination peuvent être restreints. Il ne relaie pas UDP. HTTP/3 utilise QUIC sur UDP et ne peut donc pas emprunter ce tunnel TCP de la même façon. La transmission UDP fondée sur HTTP utilise des mécanismes supplémentaires comme CONNECT-UDP et nécessite des implémentations compatibles. La seule prise en charge de HTTPS ou de HTTP/2 ne suffit pas à l’établir.

Quand l’accès proxy HTTP et HTTPS est utile

Pour la navigation et les tests de sites web, un proxy HTTP avec CONNECT fournit une méthode de connexion unique pour les destinations HTTP et HTTPS. Une équipe peut l’utiliser pour consulter un site depuis le réseau du proxy tout en laissant au navigateur la responsabilité du rendu des pages, des cookies et des connexions aux comptes web.

Pour les robots d’exploration, les clients API et les outils de surveillance planifiée, un client HTTP peut envoyer des requêtes par une IP de sortie choisie tout en conservant les URL de destination. L’application prépare toujours les requêtes et traite les réponses. Dans un tunnel HTTPS, le proxy transporte cet échange sans devoir analyser chaque page ou appel API.

Un proxy HTTPS protégé par TLS est utile lorsque la connexion au proxy doit elle aussi être protégée, y compris les identifiants proxy et les demandes de destination. Cela compte lorsque cette connexion traverse un réseau que vous ne contrôlez pas. Le client doit prendre en charge TLS jusqu’au proxy lui-même ; la seule capacité d’ouvrir des sites HTTPS ne suffit pas.

Comprendre les erreurs de connexion

Un échec peut survenir pendant l’accès au proxy, l’ouverture du tunnel ou la communication avec le site web. L’étape vous renseigne davantage que le seul code d’erreur.

Un tunnel et une négociation TLS menés à terme montrent que le trajet de connexion fonctionne. Ils ne garantissent pas que le site web acceptera un compte, une IP de sortie ou une requête précise. Une demande de connexion, un CAPTCHA ou une limite de requêtes peuvent donc nécessiter une intervention au niveau du site ou de l’application, même lorsque le proxy fonctionne.