HTTP vs HTTPS Proxiestout se joue sur ce que le proxy peut voir

La plupart des guides sur les « proxies HTTP vs HTTPS » supposent silencieusement que HTTPS est la mise à niveau : même produit, cadenas en plus. Choisissez HTTPS, dit-on, et votre trafic est chiffré, votre scraper est plus sûr, votre compte est plus difficile à identifier. Ce cadre est faux, et agir sur cette base pousse les gens à acheter la mauvaise chose pour la mauvaise raison.

Un proxy HTTP et un proxy HTTPS ne sont pas deux niveaux de qualité d'un même produit. Ils décrivent à quel point le proxy peut lire votre trafic. Un proxy HTTP voit vos requêtes en clair : il peut les inspecter, les mettre en cache, réécrire les en-têtes et router par URL. Pour un site HTTPS, ce même proxy ouvre un tunnel opaque et transmet des octets qu'il ne peut pas décoder. Le chiffrement qui vous importe ne provient pas du proxy du tout.

La vraie question n'est donc pas « quel proxy est le plus sécurisé ». C'est : avez-vous besoin que le proxy inspecte et agisse sur le trafic web, ou seulement qu'il relaie le trafic chiffré aveuglément ? Une fois que vous le formulez ainsi, le choix cesse d'être une question d'étiquette et devient une question de visibilité. La suite de ce texte démystifie le mythe et vous donne la seule question décisive.

HTTP vs HTTPS proxies : la version courte

C'est toute l'histoire en trois lignes. HTTPS n'est pas un proxy plus sûr ; c'est le même proxy qui ne peut plus voir votre trafic.

Le mythe : le proxy HTTPS est juste la version sécurisée du proxy HTTP

Le cadenas dans votre navigateur est un chiffrement de bout en bout entre vous et le site web, négocié avec TLS (Transport Layer Security, le successeur de SSL). HTTPS n'est que du HTTP transporté à l'intérieur de cette session TLS. Surtout, ce chiffrement est une propriété de la connexion entre votre client et l'origine, pas une fonctionnalité qu'un proxy intermédiaire vous accorde.

Voici la partie que le récit de la « mise à niveau » rate. Lorsque vous récupérez une page HTTPS via un proxy HTTP ordinaire, votre trafic est toujours chiffré de bout en bout. Le proxy ne le déchiffre pas, ne l'affaiblit pas et n'y ajoute rien. Il transmet simplement les octets chiffrés. Vous n'avez pas besoin d'un « proxy HTTPS » spécial pour maintenir HTTPS sécurisé, car la sécurité n'était jamais la responsabilité du proxy.

Ce que les gens appellent un « proxy HTTPS » signifie généralement l'une de deux choses sans rapport : un proxy que vous atteignez via une connexion chiffrée (le saut entre vous et le proxy est protégé par TLS), ou un proxy intercepteur qui termine TLS pour lire votre trafic et le re-chiffre vers la destination. Ce sont des objectifs opposés. L'un ajoute de la confidentialité sur le premier saut ; l'autre la supprime délibérément pour que le proxy puisse inspecter ce que vous envoyez. Confondre les deux dans « la version sécurisée du proxy HTTP » est ainsi que le mythe survit.

Le vrai axe : le proxy peut-il voir votre trafic ?

Faites abstraction du marketing et une seule variable décide de tout : si le proxy peut lire les octets qu'il transporte. Un proxy est une couche d'indirection entre vous et l'origine, et la seule question intéressante sur cette couche est à quel point elle comprend votre conversation.

Un proxy HTTP comprend HTTP. Il lit la ligne de requête et les en-têtes, il peut donc mettre en cache une réponse, supprimer ou injecter un en-tête, filtrer par URL, journaliser ce que vous avez récupéré et appliquer des politiques. Cette visibilité est tout l'intérêt d'un proxy HTTP : c'est un spécialiste capable d'être intelligent concernant le web précisément parce qu'il peut lire le web.

Pour une destination HTTPS, cette visibilité disparaît par conception. Le proxy ne peut pas lire à l'intérieur d'une session TLS qu'il n'a pas terminée. Donc pour transporter du HTTPS, un proxy HTTP change de rôle : il cesse d'être un lecteur et devient un relais aveugle. Le mécanisme qui le bascule est la méthode CONNECT, et la comprendre dissout toute la confusion HTTP versus HTTPS.

Comment CONNECT transforme un proxy HTTP en tunnel aveugle

C'est la partie que presque tous les guides d'explication sautent, et c'est celle qui fait cliquer le sujet. Un proxy HTTP standard transporte votre trafic HTTPS sans jamais le déchiffrer, en utilisant une requête spéciale appelée CONNECT. La séquence est courte :

1. Votre client ouvre une connexion normale vers le proxy et envoie CONNECT example.com:443. C'est la seule partie que le proxy lit : l'hôte et le port de destination, rien de plus.
2. Le proxy ouvre une connexion TCP vers example.com sur le port 443 et, si elle réussit, répond 200 Connection Established.
3. À partir de ce moment, le proxy cesse d'analyser. Il devient un tuyau, relayant des octets bruts dans les deux sens sans les interpréter.
4. Votre client effectue la poignée de main TLS avec example.com directement, à travers ce tuyau. La session chiffrée est entre vous et l'origine.
5. Toutes vos requêtes HTTP et les réponses du site circulent à l'intérieur de ce tunnel TLS. Le proxy ne voit que du texte chiffré qu'il ne peut pas lire.

C'est tout le tour de passe-passe. Un proxy HTTP ordinaire transporte déjà HTTPS, et il le transporte aveuglément. Le proxy sait que vous vous êtes connecté à example.com:443 et sait combien d'octets ont bougé, mais il ne peut pas lire une seule requête, en-tête ou cookie à l'intérieur du tunnel. Le TLS de bout en bout entre vous et le site est exactement ce qui le maintient à l'écart.

Deux conséquences s'ensuivent directement. D'abord, pour HTTPS, le proxy ne peut rien mettre en cache ni réécrire, car la mise en cache et la réécriture nécessitent de lire le contenu, ce qu'il ne peut pas faire. Ensuite, votre trafic HTTPS reste aussi privé du proxy qu'il l'est de n'importe qui d'autre sur le chemin. Le proxy est réduit à un relais TCP, ce qui est le même rôle qu'un proxy SOCKS5 joue pour n'importe quel protocole.

Qu'est-ce qu'un « proxy HTTPS », vraiment ?

Étant donné qu'un proxy HTTP tunnelise déjà HTTPS, le terme « proxy HTTPS » fait un travail flou. Réduisez-le à l'une de ces trois significations précises :

1. Un proxy que vous atteignez via TLS

Ici, le chiffrement est sur le premier saut : la connexion de votre client vers le proxy est elle-même encapsulée dans TLS, donc quiconque surveille votre réseau local ne voit qu'un lien chiffré vers le proxy. Le proxy utilise toujours CONNECT pour atteindre les sites HTTPS au-delà de lui. Cela est réellement utile sur les réseaux hostiles car cela cache les sites vers lesquels vous tunnelisez à un observateur local, mais c'est de la confidentialité sur le tronçon client-vers-proxy, pas une classe différente de proxy.

2. Un proxy intercepteur (terminant TLS)

C'est l'intention opposée. Le proxy termine votre TLS, déchiffre le trafic, le lit ou le modifie, puis le re-chiffre vers l'origine. Pour faire cela sans que le client ne crie, il doit présenter un certificat que le client fait confiance, c'est pourquoi les réseaux d'entreprise installent un certificat racine personnalisé sur les appareils gérés. C'est exactement la position man-in-the-middle que TLS existe pour empêcher. C'est légitime pour une entreprise inspectant son propre trafic sortant sur ses propres machines, et c'est un signal d'alarme partout ailleurs.

3. Raccourci vague pour « un proxy qui gère les sites HTTPS »

Le plus souvent, « proxy HTTPS » signifie simplement un proxy HTTP normal qui supporte CONNECT, ce qu'est aujourd'hui essentiellement n'importe lequel. Il n'y a pas de produit séparé à acheter. Si un fournisseur liste des « proxies HTTP » et des « proxies HTTPS » comme deux niveaux, demandez si la différence est le protocole sur le premier saut ou du pur marketing. C'est généralement ce dernier.

Proxy HTTP vs gestion HTTPS en un coup d'œil

Lisez le tableau comme une seule affirmation, pas douze cellules : dès que le trafic est HTTPS, chaque colonne « intelligente » se réduit à « non », car le proxy ne peut plus voir. Ce n'est pas une limitation d'un produit inférieur. C'est le chiffrement qui fonctionne comme prévu.

Ce que cela signifie pour le web scraping

Si vous scrappez, presque toutes les cibles sont HTTPS, donc presque chaque requête que vous envoyez via un proxy est un tunnel CONNECT. Cela a une implication clarificatrice : la capacité du proxy à lire votre trafic vous est indifférente, car il ne peut de toute façon pas le lire. Ce qui compte réellement, c'est la partie que le proxy contrôle encore : l'IP de sortie et la façon dont la requête atteint l'origine.

C'est pourquoi s'obséder sur « proxy HTTP versus HTTPS » est une distraction pour le scraping. Le protocole indiqué sur l'étiquette ne vous dit rien sur la probabilité d'être bloqué. Ce qui décide, c'est la réputation de l'IP, sa rotation et si la requête ressemble à un vrai navigateur, ce qui est la question datacenter versus résidentiel, pas la question HTTP versus HTTPS. Un proxy qui ne peut pas voir votre trafic chiffré peut toujours faire la différence entre un 200 et un 403, uniquement grâce à l'IP par laquelle il sort.

Il est également utile de garder la direction séparée de la visibilité. Le fait qu'un proxy lise votre trafic est un axe différent de celui où il se situe devant vous ou devant l'origine, ce qui est la distinction proxy direct versus proxy inverse. Un proxy de scraping est un proxy direct, et le comportement CONNECT ci-dessus s'applique à lui de la même façon quel que soit l'étiquette de protocole du niveau que vous avez acheté.

Il y a une vraie mise en garde de sécurité. Parce qu'un proxy intercepteur peut se placer dans le chemin CONNECT et présenter son propre certificat, ne routez jamais de scraping ou de trafic sensible via un « proxy HTTPS » gratuit ou inconnu qui vous demande de faire confiance à une autorité de certification personnalisée. TLS de bout en bout ne vous protège que si personne au milieu ne l'a terminé. Un fournisseur digne de confiance tunnelise votre HTTPS avec CONNECT et ne vous demande jamais d'installer un certificat racine.

Voir CONNECT en pratique

La façon la plus claire d'assimiler tout cela est d'observer une requête traverser les deux chemins. Pointez un client en ligne de commande sur un proxy HTTP et demandez une page HTTPS : le client émet CONNECT, le proxy relaie le tunnel, et votre poignée de main TLS se produit avec l'origine, pas le proxy.

# Plain HTTP: the proxy reads the full request
# and could cache, log, or rewrite it.
curl -x "http://user:[email protected]:8080" \
     "http://example.com/page"

# HTTPS: same proxy, but -v shows it send
# CONNECT first, then a blind TLS tunnel.
curl -v -x "http://user:[email protected]:8080" \
     "https://example.com/page"

Dans la sortie verbose de la deuxième commande, vous verrez une ligne comme CONNECT example.com:443 suivie de 200 Connection Established, et seulement ensuite la poignée de main TLS. Le fait que cette poignée de main aille vers l'origine et non vers le proxy est la preuve visuelle que votre HTTPS est de bout en bout. Le proxy a déplacé vos octets sans jamais les lire.

Si vous voulez que le proxy contrôle son IP sortante plutôt que de simplement relayer, le même mécanisme CONNECT s'applique, sauf qu'un point d'accès géré gère la rotation et les retentatives pour vous. C'est la différence entre un seul saut statique et un point d'accès poolé, la même idée derrière un proxy API qui frontalise de nombreuses sorties sous une seule adresse.

Foire aux questions

Un proxy HTTPS est-il plus sécurisé qu'un proxy HTTP ?

Pas forcément. Le chiffrement qui protège un site HTTPS est TLS de bout en bout entre vous et l'origine, et un proxy HTTP ordinaire le préserve en tunnelisant le trafic avec CONNECT. « Proxy HTTPS » signifie généralement soit que le saut vers le proxy est chiffré, soit que le proxy intercepte votre TLS, ce qui est le contraire d'une plus grande sécurité.

Un proxy HTTP peut-il gérer le trafic HTTPS ?

Oui, et presque tous le font. Lorsque vous demandez une URL HTTPS, votre client envoie au proxy une commande CONNECT avec l'hôte et le port de destination. Le proxy ouvre une connexion TCP et relaie ensuite les octets chiffrés aveuglément. Il ne déchiffre jamais le trafic ; votre session TLS est avec le site web, pas le proxy.

Qu'est-ce que la méthode CONNECT ?

CONNECT est une requête HTTP qui demande à un proxy d'ouvrir un tunnel TCP brut vers une destination au lieu de récupérer une ressource. Le client envoie CONNECT hôte:port, le proxy établit la connexion et répond 200, et dès lors il transmet les octets sans les analyser. C'est ainsi que les proxies HTTP transportent HTTPS, SSH et d'autres protocoles tunnelisés.

Un proxy déchiffre-t-il mon trafic HTTPS ?

Un proxy normal ne le fait pas. Avec CONNECT, il ne voit que l'hôte de destination et le flux d'octets chiffré. L'exception est un proxy intercepteur qui termine TLS et présente son propre certificat, qui peut lire votre trafic mais nécessite que votre appareil fasse confiance à son autorité de certification. Si un proxy vous demande d'installer un certificat racine, il peut lire tout ce que vous envoyez.

Quel proxy dois-je utiliser pour le web scraping ?

Pour le scraping, l'étiquette HTTP versus HTTPS importe à peine, car presque toutes les cibles sont HTTPS et sont tunnelisées via CONNECT de toute façon. Ce qui compte, c'est la réputation de l'IP de sortie et sa rotation. Choisissez en fonction du compromis datacenter versus résidentiel et si le proxy effectue des rotations et des retentatives, pas selon le nom du protocole.

Quelle est la différence entre un proxy HTTP et un proxy SOCKS5 ?

Un proxy HTTP comprend le trafic web et peut mettre en cache, réécrire et filtrer le HTTP en clair, tout en tunnelisant HTTPS aveuglément avec CONNECT. Un proxy SOCKS5 ne comprend rien sur le protocole qu'il transporte ; il relaie du TCP ou UDP brut pour n'importe quelle application. Pour HTTPS spécifiquement, les deux finissent par transmettre un flux chiffré opaque.

BA

Bilal Ahmed

Ingénieur logiciel · Crawlbase

Ingénieur logiciel auteur de certains des articles les plus lus du blog Crawlbase, sur le web scraping, les proxys et l'outillage de données.