Quelqu’un peut-il voir votre IP dans une application de messagerie ? Ce que chaque observateur sait
Dans une messagerie relayée, l’expéditeur et votre homologue réseau sont des entités distinctes. Séparez ce que voit le service, ce que vous voyez et ce qu’implique le nom de l’application.
« À qui je parle ? » est deux questions dans une seule phrase. L’une porte sur le compte qui a rédigé le message, l’autre sur la machine à l’autre bout de la connexion réseau que votre client tient réellement. Dans une messagerie relayée, ce n’est presque jamais la même entité, et cette différence explique l’essentiel de la confusion sur ce qu’un VPN cache ou ne cache pas à la personne à qui vous écrivez. Posez correctement la topologie et la question de la confidentialité devient susceptible d’une réponse au lieu d’être émotionnelle.
Votre client parle au service, pas à l’autre personne
Prenez une application de messagerie textuelle où chaque participant se connecte au service et le service achemine les messages entre comptes. Votre client tient une connexion au service ; l’autre participant tient une connexion distincte au même service. Le message voyage de son client vers le service, puis du service vers le vôtre, ce qui signifie que votre homologue de transport est un point de terminaison du service et non son appareil.
Alex's client -> chat service -> your clientTout ce qui suit découle de ce seul schéma. Regarder votre propre connexion identifie le service, pas Alex. Regarder la connexion d’Alex identifie le service depuis l’autre côté. Aucune des deux observations n’est, à elle seule, un relevé au niveau du paquet de l’appareil de l’autre personne, et aucune quantité d’inspection de votre propre trafic ne la transforme en tel relevé.
Des observateurs différents recueillent des preuves différentes
Le service est mieux placé que l’un ou l’autre participant, car il termine les deux connexions tout en sachant quel compte possède chacune. Ce qu’il conserve, combien de temps, quels enregistrements il joint et à qui il les divulgue sont des questions distinctes aux réponses distinctes, et aucune ne trouve sa réponse dans « l’application est chiffrée de bout en bout ».
Vous, destinataire, êtes en position faible pour les faits de réseau mais en position forte pour les faits de contenu : le texte du message, le nom affiché, tout ce que l’expéditeur a tapé ou joint. Un expéditeur qui tape sa propre adresse l’a divulguée, et cette divulgation n’est pas une observation réseau même si elle se lit comme telle.
| Observer | Sees | Cannot conclude |
|---|---|---|
| You | Your connection to the service, message contents, sender-supplied details | The other client's source address |
| The other participant | Their connection, message contents, what the service attaches | Your source address |
| The service | Both connections, account mapping, delivery metadata | What it does not retain, or what leaves its boundary |
Si Alex se connecte via un VPN, le service peut voir l’adresse de sortie de cette connexion plutôt que l’adresse personnelle d’Alex. C’est une affirmation sur ce que voit le service. Cela ne signifie pas que l’adresse de sortie vous est transmise, et cela ne signifie certainement pas que votre propre connexion est anonymisée par le choix de transport d’Alex.
Quand l’application est réellement pair à pair
Le modèle relayé est un modèle, pas une loi. Certaines fonctions de messagerie établissent des chemins directs entre clients, par exemple un canal de données dans le navigateur négocié via un serveur de signalisation, ou un mode de transfert de fichiers qui relie les deux appareils pour éviter de relayer des données volumineuses. Dans ces cas, l’homologue de transport est bien l’appareil de l’autre participant, et l’analyse des observateurs change complètement.
L’étiquette conviviale d’une application ne suffit pas à vous dire dans lequel des deux cas vous êtes. « Message direct » décrit qui le lit, pas comment il est transporté, et une fonction d’appel ou de partage d’écran dans la même application peut utiliser une topologie différente de celle du fil de texte à côté. Lisez la documentation de l’éditeur pour la fonction concernée, ou observez les connexions que votre client ouvre pendant que vous l’utilisez.
L’affirmation de chiffrement de bout en bout couvre qui peut lire les contenus protégés. Elle ne dit rien sur les serveurs qui acceptent les connexions, sur les métadonnées qu’ils voient ni sur l’existence d’un chemin direct, et la discussion des capacités de l’observateur dans le RFC 6973 est une discipline utile : nommez l’observateur, puis énumérez ce qu’il peut réellement recueillir.
Ce que cela signifie pour un VPN
Un VPN change ce que le service voit de votre connexion. Il ne change pas qui est votre homologue de transport et il ne donne pas à l’autre participant une nouvelle vue de votre adresse. Attendre d’un VPN qu’il vous cache à la personne à qui vous écrivez est une erreur de catégorie : son client n’a jamais eu de connexion avec le vôtre.
Ce qu’un VPN peut changer, c’est une fonction de chemin direct. Si l’application négociait sinon une connexion pair à pair, faire passer votre trafic par un tunnel peut au contraire imposer un relais, et certaines fonctions se comporteront autrement ou retomberont en arrière ; c’est un effet réel, mais il relève de la topologie, pas d’une disparition de la conversation.
Ensuite, gardez les deux questions séparées dans tout ce que vous notez. Quel compte a envoyé ceci, et quel point de terminaison l’a porté. Répondez explicitement aux deux, notez qui peut observer chaque réponse, et cessez de les combiner en un seul verdict sur la traçabilité d’un message.