Quatre frontières à vérifier avant de payer via un VPN

Parcourez les quatre frontières dans l'ordre et la plupart des questions de paiement se répondent d'elles-mêmes. La première est l'environnement dans lequel la transaction s'exécute, la deuxième le chemin que suit son trafic, la troisième si le site est bien celui que vous vouliez atteindre, et la quatrième ce que le destinataire apprend de la transaction quel que soit le chemin. Une suite de sécurité qui associe un navigateur protégé à un tunnel vous invite à traiter un bouton comme une garantie, et c'est exactement là que les contrôles sont sautés. Chaque contrôle a sa propre condition d'arrêt, et l'ordre compte car un contrôle ultérieur ne peut pas réparer un échec antérieur.

D'abord : ce que l'environnement protégé limite réellement

Le texte commercial d'un mode de paiement énumère généralement des restrictions : quelles autres applications peuvent interagir avec la session, si le presse-papiers et la capture d'écran sont limités, si la session s'exécute sur un bureau séparé. Ce qu'il n'établit pas, c'est qu'un composant hôte privilégié, un pilote ou un mécanisme d'entrée hors du bac à sable ne puisse pas atteindre la session. Être dans un bac à sable décrit une frontière, ce n'est pas une promesse sur chaque attaquant.

Lisez la liste des fonctions de l'édition que vous avez réellement installée, car les modes groupés diffèrent souvent selon les niveaux grand public et sont parfois absents sur les appareils gérés. Comparez cette liste à la panne que vous observez avant de supposer que la frontière a tenu.

Ensuite, arrêtez-vous et demandez si la panne que vous poursuivez est locale. Si la page de paiement s'affiche mal uniquement dans le mode protégé, l'environnement est le suspect et le tunnel n'y est pour rien. Si elle s'affiche correctement partout mais que la transaction échoue encore, vous regardez la frontière suivante, et affaiblir le mode protégé n'aidera pas.

Ensuite : quel trafic le tunnel transporte

Un tunnel protège le trafic qu'il couvre, et la couverture est un fait de configuration, non une propriété du produit. Demandez si le trafic propre au navigateur protégé est inclus, si le mode contourne le tunnel pour des raisons de performance ou de portail captif, et si une règle de tunnel divisé exclut la destination. Un navigateur ordinaire qui affiche l'adresse de sortie du fournisseur ne prouve rien sur un environnement de navigation distinct lancé par un autre processus.

Testez la couverture depuis l'intérieur de l'environnement plutôt que depuis le bureau. Chargez une page qui reflète votre adresse publique dans la session protégée et comparez-la à l'adresse que vous voyez à l'extérieur, puis répétez après avoir reconnecté le tunnel. Si les deux concordent alors que le tunnel annonce une autre sortie, le mode n'utilise pas le tunnel et cet écart mérite d'être résolu avant de saisir les données de carte. Changer l'adresse de sortie se surinterprète aussi facilement : elle vous dit quel réseau le marchand voit, pas qui est le marchand.

Troisièmement : vérifiez le service plutôt que l'insigne

La validation du certificat est ce qui authentifie la destination, et elle continue de fonctionner après la sortie du tunnel car il s'agit d'un mécanisme distinct. Une fenêtre protégée de marque et un indicateur Connected ne disent rien de la chaîne de certificats présentée par le site que vous avez atteint.

Quand quelque chose semble anormal, lisez le certificat avant d'écarter l'avertissement. La commande ci-dessous demande la chaîne que le site présente réellement et indique à l'outil d'échouer en cas d'erreur de vérification.

openssl s_client -connect shop.example:443 -servername shop.example -verify_return_error

Comparez le sujet et l'émetteur de cette sortie à l'adresse que vous avez saisie, et confirmez le résultat de la vérification plutôt que la présence d'un cadenas. Un avertissement dans un navigateur protégé reste un avertissement, et la cause habituelle est une inadéquation de nom d'hôte, une réponse DNS détournée ou un appareil d'interception sur le chemin. Aucun de ces cas n'est réparé par le tunnel, et un mode qui supprime discrètement l'avertissement a retiré une information dont vous aviez besoin.

Quatrièmement : ce que le destinataire apprend quand même

Le site de paiement reçoit tout ce que vous lui soumettez : le compte auquel vous vous connectez, l'adresse de livraison, l'instrument de carte et le montant. Une autre sortie réseau change l'adresse source dans les journaux du marchand et laisse ces champs exactement tels qu'ils étaient. Si le compte est déjà lié à vous, le tunnel a changé une petite partie de l'image et rien de la partie identifiante. Ce n'est pas une raison de sauter le tunnel, seulement une raison de cesser d'attendre qu'il fasse ce travail.

La documentation de Bitdefender sur Safepay décrit un navigateur protégé avec une intégration de tunnel associée, ce qui est un bon exemple d'un produit couvrant deux frontières sans les fusionner. L'environnement et le chemin sont tous deux utiles, et aucun des deux ne se porte garant du marchand.

Pour un paiement qui vous importe, partez de l'adresse publiée de l'organisation ou de son application officielle, conservez les contrôles d'identité que le site demande, et refusez tout assistant proposé par une invite inattendue sur la page de paiement. Si le mode protégé ou le tunnel provoque une panne, nommez d'abord la frontière : lancer l'environnement, atteindre le réseau, valider le certificat ou authentifier le compte. Utilisez ensuite le chemin de rétablissement pris en charge par le fournisseur pour cette couche au lieu de désactiver des protections pour voir si la page se charge.