Tor ou VPN : décidez selon qui chaque chemin vous force à croire
Un VPN empile votre confiance sur un seul opérateur ; Tor la répartit entre des relais. Décidez selon la couverture, selon qui peut vous relier à un site et selon ce que vous pouvez vérifier.
Choisir entre Tor et un VPN revient à savoir quelle partie vous pouvez tolérer voir les deux extrémités d’une connexion. Un VPN concentre cette vision sur un opérateur que vous avez choisi. Tor la répartit entre des relais, si bien qu’aucun relais isolé n’est censé apprendre qui vous êtes et ce que vous avez récupéré.
Aucune des deux dispositions ne vous rend anonyme à elle seule. Choisissez celle dont la confiance restante vous pouvez nommer à voix haute, puis corrigez les parties qu’elle laisse à découvert.
Comptez qui peut vous relier à une destination
Avec un VPN, chaque flux couvert atteint la sortie de l’opérateur avant d’atteindre la destination. Cet opérateur voit nécessairement votre adresse source et, pour tout ce qui n’est pas chiffré à travers lui, la destination que vous avez demandée. TLS garde le contenu de la page hors de cette vue mais laisse généralement le nom d’hôte visible pendant l’établissement de la connexion. Une partie peut donc vous relier à un site, et ce lien est précisément la confiance que vous accordez.
Tor sépare ces moitiés entre trois relais : un garde qui connaît votre adresse mais pas votre destination, un relais intermédiaire qui ne connaît aucune des deux extrémités, et une sortie qui connaît la destination mais pas vous. La conception suppose qu’aucun relais isolé ne combine les deux faits, ce qui est une hypothèse plus faible et plus utile que de faire confiance à une entreprise. Elle ne suppose pas que les relais soient honnêtes et ne défait pas un observateur qui surveille les deux extrémités du chemin.
Les deux conceptions partagent un point faible, et il se situe à la destination. Si vous vous connectez, le service relie cette session à votre compte quel que soit l’itinéraire emprunté par les paquets. Le routage change d’où une requête semble venir, pas ce que la page vous demande de fournir.
La couverture compte plus que le schéma de routage
Un VPN route au niveau de la couche réseau, donc chaque application de l’appareil hérite du tunnel sauf si vous l’excluez délibérément. Cette ampleur est la raison pour laquelle il fonctionne à la fois pour un client de messagerie, un gestionnaire de paquets et un navigateur.
Le navigateur Tor est un ensemble, et ses protections vivent surtout à l’intérieur du navigateur : une empreinte uniforme, un isolement entre les sites et des scripts limités par un niveau de sécurité plutôt que par les extensions que vous avez installées. Diriger Chrome vers un port SOCKS achète le routage sans rien de tout cela, ce qui est une source courante de confiance mal placée.
Le reste du bureau reste intact. Un client de synchronisation, un outil de mise à jour ou un document téléchargé ouvert dans un autre programme se connecte comme ce programme est configuré, et rien de tout cela ne passe par l’écouteur SOCKS sauf si vous le configurez là. Énumérez les applications qui parlent au réseau, puis demandez lesquelles l’outil choisi couvre réellement. La couverture est une propriété de votre configuration, pas de votre intention.
Choisissez avec trois conditions
La décision se règle généralement sur trois questions : le trafic vient-il d’une application ou de tout l’appareil, la destination doit-elle être incapable d’identifier votre adresse, et devez-vous atteindre un réseau privé ? Répondez-y dans cet ordre et l’outil se choisit le plus souvent lui-même.
| Requirement | Better fit | Reason |
|---|---|---|
| Every app covered, including non-browser traffic | A device VPN | Routing happens below the application, with a kill switch to stop leaks |
| Destination must not learn your address | Tor | The site sees a shared exit address rather than one tied to your account |
| Browser fingerprint that blends in | Tor Browser | The uniformity ships with the browser, a proxy alone adds none of it |
| Access to a private subnet or office resource | A VPN | Tor exits reach the public internet, not your internal routes |
Lorsque deux exigences entrent en conflit, pesez laquelle vous pouvez faire respecter. Un tunnel d’appareil avec une liste d’exclusions qui fuit est pire qu’une route réservée au navigateur que vous pouvez démontrer.
La vérification est bon marché pour les deux chemins, et elle devrait avoir lieu avant que vous vous appuyiez sur l’un ou l’autre :
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Un faux résultat de la première commande signifie que la requête est sortie du circuit, et c’est la défaillance qui vaut la peine d’être attrapée tôt. Comparez la seconde à l’adresse que votre fournisseur vous a attribuée, pas à celle dont vous vous souvenez de la semaine dernière.
Ce qu’aucune des deux options ne répare
Le chiffrement des applications fait toujours un travail qu’aucune route n’effectue. Le HTTP en clair qui traverse un réseau de confidentialité reste lisible à la sortie, et HTTPS reste la seule chose qui protège la charge utile de bout en bout. TLS ne dit rien non plus sur le nom d’hôte que vous avez saisi, ce qui explique pourquoi la destination reste visible pour quiconque termine le chemin.
Les comptes vous identifient, et aucun choix de routage ne change cela : le service sait qui s’est connecté, quelle que soit l’adresse dans l’en-tête. La corrélation par un observateur qui voit assez du réseau, la compromission de votre propre appareil et tout ce que vous tapez dans un formulaire survivent aux deux conceptions. Traitez les deux outils comme des façons de déplacer la confiance, non de la supprimer.
Partez de la configuration par défaut que chaque projet documente, confirmez la route avec les deux commandes ci-dessus, et seulement ensuite envisagez d’empiler un VPN sous Tor. Les imbriquer est une configuration avec ses propres modes de défaillance, pas une mise à niveau gratuite.