Kill switch face à l’isolation de Tor Browser : deux tests différents

Les kill switch et les modèles d’identité des navigateurs sont confondus parce que les deux sont décrits comme des fonctions de confidentialité. L’un bloque le trafic au niveau réseau, et l’autre limite ce qu’une session de navigation peut relier entre elles. Réussir un test du premier ne dit rien du second, et une page qui se charge dans Tor Browser ne dit rien du premier. La décision est de savoir quel contrôle répond à quelle question, car ce choix détermine quelles preuves comptent.

Deux contrôles à deux frontières

Un kill switch est une règle sur les routes : lorsque le tunnel n’est pas monté, le trafic qui emprunterait autrement un chemin différent est abandonné. Sa portée est ce que couvre l’implémentation, qui peut être tout le système, une application ou seulement les familles d’adresses gérées par le client. L’isolation du navigateur concerne ce qu’un site peut observer d’un visiteur au fil d’une session : cookies, état en cache, empreintes, identifiants. Aucun des deux mécanismes ne peut remplacer l’autre, car ils agissent sur des objets complètement différents.

C’est pourquoi une machine peut réussir un test parfait de kill switch et tout de même fuiter l’identité par une connexion. L’inverse arrive tout aussi souvent : un navigateur bien isolé sur un hôte dont la télémétrie emprunte un chemin que la politique n’a jamais couvert.

Classer les deux sous une seule étiquette produit de mauvaises preuves, car une réussite d’un côté tient alors lieu de paire. Gardez-les dans des colonnes séparées dès le départ. L’en-tête de colonne vous dit aussi quel artefact le test vous doit : un paquet bloqué ou un enregistrement de session.

Le test de panne répond à une question plus étroite

Une panne contrôlée montre si le client bloque le trafic que vous avez testé, sur la plateforme que vous avez testée, pendant la durée du test. Incluez les familles d’adresses, les applications et les transitions réseau que l’exigence mentionne, car chacune est une affirmation distincte. Un blocage qui vaut pour IPv4 et pas pour IPv6 est une constatation réelle, tout comme un blocage qui vaut sur un réseau filaire mais pas lors d’un transfert mobile. Écrivez la portée à côté du résultat, car une réussite sans réserve est la façon dont un test étroit devient une hypothèse large.

Le contrôle négatif compte autant que le positif. Confirmez que la même requête réussit tant que le tunnel est monté, afin qu’il soit clair que le blocage venait de la politique et non d’une destination qui n’a jamais fonctionné. Un test qui a échoué dans les deux états ne prouve rien, et cela vaut la peine de le dire dans l’enregistrement plutôt que de l’écarter en silence.

L’isolation est une propriété du navigateur, pas une route

La conception déclarée de Tor Browser limite la liaison en gardant ensemble l’état du circuit et du navigateur et en effaçant l’état sur demande, et le projet documente ce que cela signifie en pratique pour la gestion des identités. Cette conception suppose la configuration prise en charge, pas un navigateur générique pointé vers un port proxy. Les extensions ajoutées pour plus de commodité peuvent annuler une partie de l’isolation, et une connexion capturée relie tout ce qui suit quel que soit le circuit. Le comportement documenté est assez court pour être lu directement.

Les observations du navigateur et celles du réseau répondent à des questions différentes, alors gardez-les dans des notes séparées. Une page qui se charge via Tor alors que le VPN est monté vous dit que le proxy fonctionne et rien sur le comportement d’abandon du VPN. Un paquet bloqué pendant une panne ne dit rien sur le fait que deux connexions étaient liables une heure plus tôt.

Deux enregistrements, deux questions

Pour le kill switch, demandez si une application nommée peut sortir par une route indésirable pendant une panne, et apportez une panne contrôlée avec une destination de journalisation que vous possédez. Pour l’isolation du navigateur, demandez quels comptes, états et signaux pourraient relier deux activités, et apportez un flux de travail plutôt qu’une capture de paquets. Si une seconde application compte, testez-la séparément, car la portée est plus souvent par application que ne le suggèrent les fournisseurs. Deux questions différentes produisent deux artefacts différents et un rapport honnête.

Dessinez les deux chemins avant de tester : la route normale et la route après une panne du tunnel, pour chaque application de la portée. Un dessin expose l’écart qu’un seul indicateur vert masque, parce qu’il vous oblige à nommer ce qui est couvert et ce qui ne l’est pas. Faites-le pendant que les systèmes sont sains, quand personne n’est sous pression pour déclarer la vérification terminée.

Aucun des deux contrôles ne certifie l’autre, et une configuration combinée a besoin des deux enregistrements avant de pouvoir revendiquer les deux propriétés. Revendiquer les deux à partir d’un seul indicateur vert est exactement la défaillance que cet appariement doit empêcher.