Un VPN devant Tor rend-il la surveillance plus difficile ?

Ajouter un segment chiffré de plus à un chemin ne supprime pas les observateurs ; cela les déplace, et parfois en ajoute un. L’exercice utile consiste à dessiner la route et à étiqueter qui voit quoi à chaque étape, car un VPN devant Tor et un VPN atteint via Tor donnent des réponses opposées à presque toutes les questions qui valent la peine d’être posées. Aucune des deux dispositions ne bat un point de terminaison compromis, et aucune ne répare un compte qui nomme l’utilisateur. Parcourir le chemin dans l’ordre, puis demander ce qui casse quand une couche disparaît, transforme un slogan en décision.

Parcourez le chemin et nommez chaque observateur

Commencez par le cas ordinaire de Tor et étiquetez chaque saut. Le réseau local et le fournisseur d’accès voient une connexion vers un point d’entrée Tor, avec sa taille et son minutage. Le garde d’entrée voit l’adresse du client, et c’est pourquoi le garde est une relation de longue durée plutôt qu’un choix aléatoire. Le nœud de sortie voit la destination et le texte en clair de tout ce qui n’est pas chiffré de bout en bout, tandis que la destination voit une adresse de sortie sans aucune adresse client attachée.

Notez ces étiquettes avant d’ajouter quoi que ce soit. Le schéma est l’argument, et il est facile à vérifier.

Deux ordres produisent des observations différentes

Un VPN placé devant Tor signifie que le trafic quitte l’appareil vers le fournisseur de VPN, sort de ce fournisseur et n’atteint qu’ensuite une entrée Tor. Le réseau local ne voit plus du tout Tor, et c’est tout l’intérêt quand un réseau le bloque ou le surveille. Le garde d’entrée voit désormais l’adresse du VPN au lieu de celle de l’utilisateur, et le fournisseur de VPN voit qu’un client précis se connecte à Tor avec un schéma temporel particulier. Ce fournisseur devient une nouvelle partie dotée d’une observation précieuse, et sa politique de journalisation fait désormais partie du modèle de menace au lieu d’en être exclue.

Atteindre un VPN via Tor inverse l’ordre et inverse aussi ce qui est exposé : la destination voit l’adresse du VPN, la sortie Tor ne voit plus la destination, et le fournisseur de VPN voit arriver du trafic Tor plutôt que l’adresse personnelle d’un client. Cela taxe aussi la connexion de deux couches de latence et exige un support client que beaucoup d’applications commerciales n’offrent pas.

Choisir entre les deux est une question de savoir quel observateur compte le plus, non de savoir lequel sonne le plus sûr. Un utilisateur qui cache l’usage de Tor à un réseau local veut le premier ordre ; un utilisateur qui cherche à empêcher une destination d’apprendre quoi que ce soit qui lui soit attribuable a besoin d’une autre analyse, et aucun des deux ordres ne cache un nom de compte.

Ce qui identifie encore la session

Les observateurs au niveau de l’adresse ne sont qu’une partie du tableau, et souvent pas la partie décisive. Un compte connecté lie l’activité à une identité quelle que soit l’adresse de sortie qui a porté le paquet, et un enregistrement de paiement que le service peut relier à une personne fait de même. L’état du navigateur y contribue aussi : un cookie persistant, une connexion enregistrée ou une extension identifiante peuvent suivre un utilisateur à travers des circuits conçus pour ne pas être corrélables.

Le contenu soumis à un site est le troisième signal. Un document avec des métadonnées, un nom saisi dans un formulaire ou un style d’écriture unique survivent à n’importe quel nombre de couches de chiffrement, et aucun des outils qui les précèdent n’est conçu pour y toucher. Tenir une liste honnête de ces identifiants protège davantage que d’ajouter un saut de plus.

Prévoyez une couche qui disparaît

Le comportement en cas de panne est là où les dispositions diffèrent réellement, et c’est une propriété de configuration plutôt qu’une fonction de l’un ou l’autre outil. Si le VPN tombe alors que Tor est configuré pour passer par lui, Tor s’arrête-t-il, ou se reconnecte-t-il discrètement par le chemin ordinaire ? La seconde issue n’est pas une fuite vers la destination, mais elle révèle au réseau local que Tor est utilisé, ce qui était peut-être exactement ce que la disposition devait empêcher.

Un coupe-circuit au niveau de l’appareil peut imposer une partie de la réponse en refusant le trafic hors du tunnel, et il ne couvre que le trafic que l’appareil route. Une application exclue du tunnel contourne cette protection, et un résolveur utilisé lors de l’établissement de la connexion peut révéler des noms même quand la charge utile reste dans le tunnel. Lisez les exclusions et la configuration du résolveur au lieu de supposer que l’interrupteur couvre tout.

Laissez tranquille le paquet du navigateur

Les protections de Tor Browser dépendent du fait que tout le paquet se comporte comme prévu : sa propre configuration de proxy, son isolation entre sites et ses défenses contre les empreintes. Pointer un navigateur ordinaire vers un port Tor local, ou ajouter une extension de proxy à Tor Browser, change des hypothèses sur lesquelles le design repose. Le propre guide du Tor Project sur la combinaison d’un VPN avec Tor traite la combinaison comme une configuration avancée, et cette prudence concerne ces interactions plutôt que le fournisseur de VPN.

Avant de combiner des outils, sachez énoncer en phrases simples le chemin normal, le chemin de panne et le rôle de chaque opérateur. Si la seule justification est que deux couches sonnent plus sûres, il n’y a aucune exigence contre laquelle concevoir, et le mode de panne ajouté est la principale chose qui a été ajoutée.