Journalisation des proxys et confidentialité

Ce qu’un proxy peut voir lors d’une connexion à un site web HTTPS

Prenons une vente aux enchères fictive : votre application soumet une enchère de €180 à https://bid.example/lot/218/bids. Avec un tunnel proxy ordinaire, HTTPS protège l’échange entre votre application et le site web grâce au protocole de sécurité TLS. Le fournisseur peut voir l’IP du client qui se connecte, la destination bid.example:443 et l’heure de connexion ; il peut aussi mesurer le volume de données transférées. L’URL complète, le lot sélectionné, l’action du client, le montant de l’enchère, les cookies et la réponse de la vente restent à l’intérieur de HTTPS. Avec une vérification correcte des certificats et sans interception, le fournisseur ne peut pas les lire.

Le domaine peut être divulgué avant le début de cet échange chiffré. HTTP CONNECT indique normalement l’hôte et le port de destination. SOCKS5 peut recevoir un nom de domaine ou une adresse IP ; si l’application demande au proxy de se connecter par nom de domaine, le proxy apprend ce nom. Une IP de destination seule n’identifie pas nécessairement un site web précis, puisque plusieurs sites peuvent la partager.

Le HTTP simple est différent : ses en-têtes, le chemin de la page et son contenu sont accessibles à un proxy qui transporte la requête. SOCKS5 n’ajoute pas de chiffrement à un échange applicatif qui n’en possède pas. HTTPS par SOCKS5 conserve sa protection HTTPS ; HTTP par SOCKS5 reste lisible.

Le site web lui-même reçoit la requête déchiffrée. Il peut lire l’identifiant, les cookies et les champs de formulaire que vous lui envoyez, et reconnaître un compte existant après un changement d’IP du proxy. HTTPS protège les données en transit ; il ne les masque pas à leur destinataire prévu.

Pourquoi certains fournisseurs de proxys exigent l’installation d’un certificat

Certains fournisseurs demandent aux clients d’accorder leur confiance à leur propre certificat racine pour des services particuliers qui inspectent le trafic HTTPS. Cette exigence vient du fournisseur, et non du site web consulté, et ne s’applique pas à tous les proxys. ProxyCompass ne demande pas aux clients d’installer son certificat racine.

Avec un tunnel HTTPS ordinaire, le proxy ne peut pas lire le contenu des requêtes et des réponses. Si un service doit vérifier les données soumises, leur appliquer des règles ou analyser les réponses des sites web, il a besoin d’accéder à ce contenu. L’inspection HTTPS fournit cet accès : le service déchiffre le trafic qui le traverse.

Un certificat racine est un document numérique qu’une application utilise comme fondement pour faire confiance à d’autres certificats. Ajouter le certificat du fournisseur à l’ensemble des certificats de confiance permet à l’application d’accepter les certificats de sites web émis par ce fournisseur. En mode inspection, le proxy présente l’un de ces certificats à la place du certificat d’origine du site. Sans la confiance correspondante, la vérification normale du certificat échoue.

Le proxy établit deux connexions chiffrées distinctes : l’une avec votre application et l’autre avec le site web. Entre les deux, il peut lire les requêtes et les réponses. Dans l’exemple de la vente aux enchères, cela expose l’adresse complète https://bid.example/lot/218/bids, le numéro du lot, l’enchère soumise de €180, les cookies et la réponse acceptant l’enchère. Le fournisseur peut voir ce que le client fait réellement sur le site web.

Cette exigence dépend du produit, du mode et de la méthode d’accès concernés. Elle peut apparaître dans des services qui automatisent l’accès aux sites web ou lorsque l’analyse du trafic est activée dans un gestionnaire de proxys. Les seules étiquettes « résidentiel » ou « centre de données » n’indiquent pas si elle s’applique. Il suffit parfois de fournir le certificat à un seul script ; l’installer pour tout le système n’est pas nécessaire.

Installer un certificat ne fait pas, à lui seul, passer tout le trafic par le fournisseur. L’accès décrit ici se produit lorsque les requêtes passent par un service dont l’inspection est activée. Un certificat utilisé uniquement pour vérifier la propre adresse HTTPS du proxy ne signifie pas non plus que le contenu de la connexion au site web cible est déchiffré.

Pouvoir lire les données et les enregistrer dans des journaux sont deux choses distinctes. Le certificat aide à comprendre qui peut accéder au contenu de la connexion, mais ne dit rien sur les durées de conservation ni sur l’accès du personnel. Désactiver la vérification des certificats ne masque pas non plus les données à un service qui les déchiffre.

Les API de scraping et les navigateurs distants reçoivent le contenu

Avec une API de scraping, vous confiez une tâche au service : ouvrir cette URL et renvoyer la page ou les données extraites. Le service établit sa propre connexion au site web et reçoit la réponse sous une forme lisible. Il peut le faire sans vous demander d’installer un certificat, car c’est lui le client qui récupère la page.

Un navigateur hébergé par le fournisseur fonctionne sur les machines de ce dernier. Les pages, les cookies et les sessions du navigateur y sont traités, même si la connexion utilisée pour le contrôler est chiffrée. Selon le produit, votre tâche peut comprendre des URL complètes, des en-têtes personnalisés, des cookies, des données de formulaire et des instructions pour interagir avec une page.

Cet accès est nécessaire à l’exécution de la tâche. Il ne prouve pas que chaque page est archivée ou que les employés lisent régulièrement les résultats des clients. Il signifie en revanche que les règles du produit sur le traitement des tâches et des résultats comptent : une promesse couvrant les tunnels proxy ordinaires ne couvre pas forcément son API ou son navigateur hébergé.

Pour une entreprise, les informations sensibles peuvent être une liste de produits suivis, une succession de recherches ou un ensemble de cibles de recherche. Même si toutes les pages sources sont publiques, la collecte et la façon de l’utiliser peuvent révéler un projet commercial.

Ce qui peut figurer dans les journaux de proxys

Un fournisseur peut conserver plusieurs types d’enregistrements. Ils ne sont pas nécessairement stockés ensemble : une connexion peut renvoyer à un numéro de compte, tandis que l’adresse e-mail, la commande et le paiement se trouvent dans d’autres systèmes.

Il s’agit de catégories possibles, pas d’une liste que chaque fournisseur collecte nécessairement. Un service peut traiter une valeur pour ouvrir une connexion sans la conserver. Il peut aussi tenir un compteur de volume total de données sans préserver un enregistrement permanent de chaque destination.

L’IP du client dans un journal est l’adresse de l’appareil ou de l’intermédiaire qui se connecte directement au proxy. Avec une connexion directe, il s’agit généralement de l’IP publique du client ; en présence d’un autre intermédiaire en amont, il peut s’agir de l’adresse de cet intermédiaire.

Ce que couvre réellement une déclaration « sans journaux »

« Nous ne stockons pas le contenu de votre trafic » peut coexister avec des enregistrements des domaines cibles, des heures de connexion et de l’utilisation. « Nous ne conservons que les totaux de consommation » décrit un autre dispositif. Une brève mention « sans journaux » ne vous dit pas laquelle de ces promesses le fournisseur formule.

Lisez la déclaration à la lumière des données et du produit nommés. Exclut-elle le contenu des pages, les enregistrements de connexions individuelles, l’historique des destinations ou les trois ? Couvre-t-elle uniquement le fonctionnement normal, ou aussi les journaux de diagnostic ? Que reste-t-il dans les systèmes de compte, de paiement, de support et de gestion des abus ?

Une déclaration « uniquement en RAM » décrit une méthode de stockage. Elle ne vous dit pas si les informations sont envoyées à un autre système avant l’effacement de la mémoire. De même, le stockage chiffré protège les enregistrements contre certains types d’accès non autorisés ; cela ne signifie pas que le fournisseur ne peut pas les lire.

Des étiquettes comme privé, dédié ou élite ne répondent pas à ces questions. Elles décrivent d’autres propriétés du proxy. Un site de vérification d’IP peut examiner la requête qui lui parvient, mais ne peut pas vérifier les pratiques internes de journalisation du fournisseur.

Comment les journaux aident à traiter les défaillances, la facturation et les signalements d’abus

Les enregistrements de connexion peuvent distinguer un échec d’authentification d’une destination qui n’a pas répondu. Les totaux de consommation aident à expliquer l’épuisement d’un quota de trafic. Un changement soudain des habitudes de connexion peut aussi révéler un script défectueux ou une utilisation inattendue du compte.

Une distinction utile sépare une connexion proxy réussie d’une requête web réussie. Une réponse CONNECT réussie confirme qu’un tunnel s’est ouvert. À l’intérieur, le site peut encore renvoyer un CAPTCHA ou une réponse HTTP 403. Un tunnel ordinaire ne lit pas cette réponse chiffrée ; son résultat de connexion et le résultat web constaté par l’application peuvent donc différer.

Le site web cible a un autre point de vue. S’il reçoit des tentatives de mots de passe, il peut signaler les requêtes, l’IP du proxy, l’heure et d’autres détails de connexion. Si le fournisseur dispose d’assez d’enregistrements correspondants, il peut relier le signalement au compte client utilisé pour ces connexions. Apprendre un chemin de requête par la réclamation du site web ne signifie pas que le fournisseur a déchiffré le trafic HTTPS initial.

Une IP de proxy partagée n’empêche pas ce rapprochement. Des enregistrements détaillés peuvent relier une connexion client authentifiée à la connexion établie vers le site web. Les horodatages précis, y compris les millisecondes lorsqu’elles sont enregistrées, les ports et la destination aident à distinguer les connexions simultanées. Les IP rotatives peuvent aussi rester liées au même compte. Changer d’adresse ou la partager n’efface pas les enregistrements du fournisseur.

Combien de temps les enregistrements sont conservés

Les journaux de connexion, les factures, les tickets de support et les résultats de scraping peuvent avoir des durées de conservation différentes. Une politique utile explique ces durées par catégorie ou indique les conditions utilisées pour déterminer combien de temps chaque catégorie est nécessaire.

L’historique visible dans un tableau de bord ne correspond pas nécessairement à la durée totale de stockage. Si l’interface n’affiche que l’activité récente, cela indique ce que vous pouvez y consulter. Cela n’établit pas quand les enregistrements internes, les dossiers d’incident ou les sauvegardes sont supprimés.

Fermer un compte n’efface pas nécessairement tous les enregistrements associés. Les données de facturation ou d’incident peuvent subsister lorsqu’un motif légitime justifie leur conservation. La suppression des systèmes actifs et l’expiration des copies de sauvegarde peuvent aussi suivre des calendriers différents.

Remplacer le nom d’un client par un identifiant de compte ne rend pas les enregistrements anonymes si l’entreprise conserve le lien entre cet identifiant et le client. La question pertinente est de savoir si les informations restantes peuvent toujours être reliées à un compte ou à une personne.

Qui peut accéder aux informations

L’existence de journaux et l’autorisation de les lire sont deux questions différentes. Le support peut avoir besoin des erreurs de connexion, le service financier des données de paiement et une équipe de sécurité d’informations sur un incident. La politique de confidentialité doit expliquer l’accès et le partage ; les contrôles de sécurité doivent limiter l’accès aux personnes qui en ont besoin.

Un revendeur et l’entreprise qui exploite le réseau de proxys peuvent détenir différentes parties des enregistrements. Les prestataires de paiement, les hébergeurs et les plateformes de support peuvent aussi traiter certaines données. Vérifiez quelles entreprises interviennent et quelles informations elles reçoivent.

Le pays d’une IP de proxy ne détermine pas, à lui seul, où les enregistrements des clients sont conservés ni quelles règles juridiques s’appliquent au fournisseur. L’entreprise contractante, ses modalités de traitement et le droit applicable comptent aussi. Un fournisseur peut devoir divulguer les informations conservées aux autorités en vertu d’une obligation légale contraignante. Les conditions applicables doivent être lues dans sa politique ; il n’existe pas de règle mondiale unique pour tous les services de proxys.

Choisir des conditions de confidentialité adaptées à votre charge de travail

Pour un projet qui doit garder le contenu des pages dans votre propre application, la distinction entre un tunnel HTTPS normal et un service géré de récupération est déterminante. Un tunnel peut rendre le contenu illisible pour l’intermédiaire tout en exposant les métadonnées de connexion. Une API gérée peut réduire votre travail de développement, mais elle reçoit la tâche et le résultat.

Les métadonnées de destination peuvent aussi compter. Une liste de domaines, les horaires des visites et leur volume peuvent révéler les entreprises ou les marchés étudiés par une équipe. Déterminez si ces informations sont sensibles avant de considérer le chiffrement du contenu comme une protection suffisante pour le projet.

Enfin, réfléchissez à ce que vous envoyez vous-même au support. Un fichier de configuration ou une capture réseau peut contenir des mots de passe proxy, des jetons d’accès, des cookies et des corps de requêtes qui ne sont jamais apparus dans les journaux de trafic du fournisseur. Retirez les secrets sans rapport avec le diagnostic avant de partager ces éléments.

Avant de commencer, établissez ce que le produit choisi peut lire, ce qu’il conserve, quand ces enregistrements sont supprimés et qui peut les recevoir. Ces détails rendent une politique de confidentialité utile à une tâche réelle.