Trafic de couverture sur un VPN : de quel observateur vous cachez-vous
Le remplissage modifie un motif de trafic, mais pour l'observateur pour lequel vous l'avez conçu. Parcourez où le remplissage s'arrête, ce qu'il coûte et ce qu'il ne peut pas cacher.
Imaginez que vous partagiez un réseau de café avec quelqu'un qui utilise un VPN, et que tout ce que vous voyez soit des tailles de paquets et du timing. Le trafic de couverture est censé brouiller cette image. Suivez le remplissage de l'ordinateur portable à la passerelle, et le brouillage se révèle local : il s'arrête là où la passerelle s'arrête. Tout ce qui suit ce point est un nouveau problème d'observation sur le même trafic réel.
La première question n'est donc jamais combien de remplissage envoyer. C'est de quel observateur vous vous cachez, et où cet observateur se trouve.
Commencez par l'ordinateur portable
Sur le lien local, un observateur voit des paquets chiffrés partir et arriver. Sans remplissage, un gros envoi est une suite de paquets de taille pleine, un appel est un flux régulier de paquets de taille moyenne, et un client inactif émet des keepalives. Ces formes sont corrélées à ce que fait l'utilisateur même lorsque le contenu est illisible. Le remplissage peut lisser la forme, au prix d'octets que personne n'a demandés.
Notez ce que cet observateur remarquerait sinon : une rafale au début d'un transfert, un trou quand un appel se termine, un rythme de périodes d'inactivité. Si vous ne pouvez pas nommer le trait, vous ne pouvez pas affirmer que le remplissage le cache.
Suivez le remplissage jusqu'à la passerelle
L'ordinateur portable envoie du remplissage à une passerelle coopérante, qui le jette et transmet le trafic réel. Cette coopération est le mécanisme : sans un point d'extrémité qui retire le remplissage, vous avez ajouté de la charge au chemin de quelqu'un d'autre au lieu de créer une couverture. La spécification de remplissage de Tor rend explicite cette même séparation : remplissage de lien entre relais adjacents et remplissage de circuit lié à l'état du protocole.
Considérez maintenant ce que voit la passerelle. Elle voit le trafic réel plus le remplissage, ce qui signifie qu'elle en apprend plus, et non moins, sauf si c'est la partie en laquelle vous avez confiance. Le trafic de couverture déplace la confiance ; il n'en supprime pas le besoin.
Regardez ensuite le second segment
Au-delà de la passerelle, les connexions vers les destinations réelles sont du trafic ordinaire avec des formes ordinaires. Un observateur là-bas, qu'il s'agisse d'un hébergeur ou du réseau de destination, voit les mêmes rafales que le remplissage était censé cacher. Si cet observateur était celui qui vous importait, le remplissage n'a rien fait pour vous. Cette frontière est tout l'intérêt de parcourir le chemin.
Le trafic de couverture est limité à un segment, et étendre la portée signifie étendre la coopération.
Direction et forme
Le remplissage envoyé uniquement vers l'extérieur cache le moment de ce que vous envoyez. Il ne dit rien du moment de ce qui revient, car les réponses arrivent selon leur propre calendrier. Le masquage asymétrique est normal et mérite d'être dit à voix haute : une session à forte descente montre encore sa forme du côté entrant.
La longueur des paquets, la structure des rafales, les heures de début et de fin et les intervalles entre arrivées portent tous de l'information. Un compteur d'octets qui reste plat peut coexister avec une distribution de tailles de paquets très reconnaissable. Des totaux plats ne sont pas un comportement plat.
Ce que le budget achète
Le remplissage consomme de la capacité que quelqu'un paie : données mesurées, concurrence sur l'uplink, délai de file d'attente pour les autres utilisateurs de la même connexion. Suivre le débit maximal disponible est aussi contre-productif, car ce maximum se déplace avec le lien et le remplissage se déplace alors avec lui. Un budget annoncé, avec un comportement annoncé quand il est épuisé, fait la différence entre un mécanisme et un accident.
Évaluez le résultat par rapport à l'observation que vous avez nommée au début. Un test montrant une reconnaissance réduite sous un observateur défini est un résultat ; une promesse que plus de trafic signifie moins d'information n'en est pas un.
Décider s'il faut le faire
Pour la plupart des gens, la réponse est non, et la raison honnête est qu'un flux d'arrière-plan à pleine vitesse est un mauvais substitut à un logiciel qui documente ce qu'il protège. Le remplissage est de l'ingénierie légitime, et il a sa place dans des conceptions qui nomment leur observateur, leurs points d'extrémité coopérants, leur coût et leurs limites. Ce n'est pas une case à cocher qui transforme un VPN en système d'anonymat.
Si vous l'implémentez, écrivez d'abord le modèle d'observateur. Chaque décision ultérieure, des tailles de paquets au comportement à l'arrêt, découle de ce seul paragraphe.