L’étiquette proxy HTTPS ne décrit que le transport entre votre client et le proxy, rien de plus. Elle ne dit pas que le site web derrière est chiffré par cette même connexion, et elle ne dit pas que le proxy peut lire la page. Une fois les deux connexions séparées, les erreurs de certificat cessent d’être mystérieuses et la comparaison avec un VPN devient concrète.

Deux paires de points de terminaison, deux vérifications

En mode tunnel ordinaire, il existe deux relations TLS. La première va de votre client au proxy et authentifie le proxy. La seconde va de votre client au site web à l’intérieur du tunnel et authentifie le site web. Elles échouent indépendamment et se configurent indépendamment.

Elles ont des décisions de confiance distinctes, des chaînes de certificats distinctes et des messages d’échec distincts. Un proxy utilisant une CA d’organisation et un site web public utilisant une chaîne publique peuvent légitimement avoir besoin d’une configuration de vérification différente, et ce n’est pas une mauvaise configuration.

Traitez-les comme deux connexions qui partagent un socket, parce que c’est ce qu’elles sont.

Ce que CONNECT tunnelise réellement

Le client envoie une requête CONNECT nommant l’hôte et le port, et le proxy ouvre une connexion TCP vers cette cible. Une fois que le proxy a répondu, les octets suivants sont relayés sans interprétation, c’est pourquoi la poignée de main TLS du site web traverse le proxy intacte. Le proxy apprend donc le nom de destination et les métadonnées de connexion, et il ne reçoit pas de pages déchiffrées de cet arrangement.

Cette distinction est tout l’argument de sécurité du mode tunnel, et c’est aussi sa limite.

Un proxy HTTP sans TLS sur le saut proxy transporte quand même un site HTTPS via CONNECT. L’échange client-proxy est en clair alors que la connexion au site web ne l’est pas, et appeler l’ensemble un proxy HTTPS masque cette différence.

Quel certificat a échoué

Quand la vérification échoue, lisez le point de terminaison nommé dans l’erreur avant de modifier un réglage de confiance. Les deux échecs se ressemblent dans un terminal et pointent vers des corrections complètement différentes, c’est pourquoi la première question est toujours quelle connexion a refusé.

curl sépare les options exactement pour cette raison. Le fichier CA du proxy configure la vérification du proxy, tandis que le fichier CA configure la vérification du serveur, et le comportement du magasin de confiance applicable dépend aussi de la façon dont curl a été compilé.

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

Supprimer un contrôle n’est pas une réparation. Cela n’établit rien sur l’un ou l’autre point de terminaison.

L’inspection est un arrangement différent

L’inspection TLS n’est pas du tunnelage. Un intermédiaire inspecteur termine la relation de confiance vers le site web et présente son propre certificat au client, si bien que le client vérifie l’intermédiaire plutôt que le site. Cela peut être légitime dans le cadre d’une conception approuvée, et c’est une affirmation matériellement différente d’un relais octet par octet. Ne supposez pas que chaque proxy inspecte, et ne supposez pas qu’un saut proxy chiffré l’exclut.

Une CA d’organisation dans votre magasin de confiance est un indice sur l’arrangement dans lequel vous êtes, pas une preuve. Demandez la conception plutôt que de l’inférer d’une chaîne de certificats.

Ces deux arrangements donnent des réponses différentes à la question de savoir qui peut lire la page.

Comparez proxy et VPN sur les mêmes quatre lignes

La comparaison ne devient utile que lorsque les deux déploiements sont décrits de la même manière.

LineWhat to state
Protected segmentsWhich hops are encrypted, and between which endpoints
Verified identitiesWhat each end proves, and against which trust anchor
Trusted intermediariesWho can read or alter traffic by design
Traffic includedWhich processes and destinations the policy actually covers

Un proxy configuré pour une requête couvre cette requête. Il ne fait pas passer chaque processus de l’appareil par lui, et la commande d’exemple est exactement aussi étroite. La couverture d’un VPN dépend de son routage et de sa politique d’applications, qu’il faut aussi inspecter plutôt que supposer. Aucune des deux options ne couvre tout simplement parce qu’elle a été installée.

Écrivez les quatre lignes pour chaque option et l’argument se résout généralement de lui-même. La comparaison utile n’est pas quelle étiquette semble plus chiffrée. C’est quels segments sont protégés, qui est vérifié à leurs extrémités, quels intermédiaires vous faites confiance, et quel trafic la politique inclut réellement.

Articles similaires