VPN et Tor ne remplacent pas HTTPS : où s’arrête chaque couche

Un VPN et un circuit Tor chiffrent tous deux votre trafic pendant une partie du trajet. Tous deux cessent de le chiffrer chez un pair qu’ils choisissent eux-mêmes. HTTPS est la couche qui atteint le site lui-même, et aucune quantité de tunnellisation devant elle ne transforme l’envoi d’un formulaire en clair en un envoi protégé. Suivre chaque couche jusqu’au point où elle se termine rend cela évident.

Trois couches, trois points de terminaison différents

Un VPN classique termine son tunnel au serveur VPN. Tout ce qui se trouve entre votre appareil et ce serveur est dans le tunnel, et tout ce qui vient après ne l’est pas. Un circuit Tor se comporte de la même façon avec un autre pair, quittant le réseau à un relais de sortie qui transmet votre requête à la destination.

TLS se termine au site. Le certificat que vous avez validé lie un nom d’hôte à une clé que le site contrôle, et les clés de session existent entre votre navigateur et ce serveur. Ce point de terminaison se situe au-delà du serveur VPN et de la sortie Tor.

Les trois couches ont donc trois frontières de confiance différentes, et une requête les traverse toutes dans l’ordre. Renforcer l’une ne dit rien des autres, et la dernière est la seule à laquelle la destination participe.

Ce que le dernier saut expose

Si l’application utilise du HTTP simple, le contenu au-delà de la sortie est lisible par quiconque exploite ce saut. Le tunnel précédent a parfaitement fait son travail et n’est tout simplement plus là. Les identifiants saisis dans un formulaire HTTP sont exposés exactement au point où la protection s’est arrêtée.

Avec un HTTPS correctement validé, un intermédiaire sur le chemin ne peut ni lire ni modifier silencieusement le contenu de l’application. Il voit toujours que vous vous êtes connecté, quand et vers quelle adresse, car les en-têtes des paquets doivent être routables. La confidentialité du contenu et les métadonnées sur la connexion sont des propriétés différentes, et seule la première est ce que TLS fournit.

L’identité du compte est encore une troisième chose. Se connecter à un compte vous identifie auprès de ce service quelle que soit l’adresse de sortie utilisée, donc la sortie protège le chemin réseau et non le compte. Cette distinction survit à n’importe quel nombre de couches devant elle. Changer de sortie ne change jamais ce que révèle une session connectée. Le service savait qui vous étiez avant que le premier paquet ne parte.

Rien dans cet arrangement ne se casse en ajoutant un second tunnel. Ce qui change, c’est quel observateur voit le premier saut, pas si le dernier saut est chiffré.

L’ordre change les observateurs, pas le point de terminaison

Enchaîner un VPN et Tor est un moyen légitime de changer qui voit quoi au niveau réseau. Faire tourner Tor sur un VPN cache à votre réseau d’accès le fait que vous utilisez Tor, tandis que faire tourner un VPN sur Tor cache votre adresse au fournisseur VPN. Les deux ordres sont décrits dans la documentation publique et les deux ont des compromis de performance et de comportement en cas de défaillance.

Aucun des deux ordres ne déplace le point de terminaison TLS. Dans les deux cas, le navigateur valide toujours un certificat pour le nom d’hôte demandé, et dans les deux cas une URL HTTP envoie toujours son contenu en clair au-delà du dernier relais. La composition change la liste des observateurs ; elle ne change pas le nombre de couches à la destination.

C’est pourquoi les conseils sur l’enchaînement portent généralement sur les modèles de menace et non sur la sécurité en général. Une chaîne plus longue n’est pas une version plus forte de la même chose, et elle ne remplace pas le protocole que l’application a choisi.

curl -sSI https://example.net | head -3
openssl s_client -connect example.net:443 -servername example.net -brief

Les deux commandes montrent la couche qui compte à la destination. La seconde affiche le protocole négocié sans impliquer aucun tunnel. Ni l’une ni l’autre ne vous dit quoi que ce soit sur la sortie utilisée.

Gardez la validation active pendant le diagnostic

Un avertissement de certificat est une information sur la connexion que vous êtes sur le point d’établir. Il peut signifier un nom d’hôte qui ne correspond pas, un problème d’horloge, une chaîne non fiable ou une tentative d’interception. Ajouter une exception permanente parce qu’un VPN est connecté supprime le seul signal qui aurait distingué ces cas.

Les fonctions de connexion sécurisée de Tor Browser et ses avertissements existent pour la même raison, et les désactiver pour qu’une page se charge échange un échec visible contre un échec invisible. Si un site n’est pas accessible sans exception, la conclusion honnête est que la connexion n’est pas vérifiable, et non que le tunnel l’a rendue sûre.

Le chiffrement ne dit rien non plus de l’intention. Une connexion HTTPS valide vers un site trompeur livre vos données à ce site avec une confidentialité parfaite. Vérifiez l’adresse et ce que vous envoyez, pas seulement la présence du cadenas.

Les services Onion sont un modèle véritablement différent. On y accède via le réseau Tor sans sortie publique ordinaire, ce qui n’est pas la même chose qu’accéder à un site public via Tor. Traitez cela comme un cas distinct avec ses propres attentes, et non comme une version plus forte de la même visite.

La règle qui survit à toutes les configurations est courte. Gardez la validation du navigateur intacte. Jugez chaque couche à l’endroit où elle se termine réellement.