Je me sors 5 min de mon weekend en amoureux les amis, pour avertir ceux parmi vous qui sont des utilisateurs de Mullvad, peu importe que vous soyez sur macOS, Windows ou un Linux Ubuntu/Debian... Si vous jonglez entre les serveurs en pensant brouiller votre piste, j'ai une mauvaise nouvelle pour vous.

Tmctmt vient de publier une analyse qui montre que vos IPs de sortie sont beaucoup moins aléatoires qu'on ne l'imagine. En fait, votre clé WireGuard agit comme une empreinte qui survit aux changements de pays.

Le mécanisme est un peu tordu, mais vous allez vite capter. En fait votre IP de sortie n'est pas tirée au hasard à chaque connexion, mais est calculée de façon déterministe à partir de votre clé WireGuard. Ou plutôt, à partir d'un float dérivé de cette clé, qui sert ensuite à vous positionner dans les plages d'IPs de Mullvad. Cette clé change tous les 1 à 30 jours, sauf si vous utilisez un client tiers (genre le driver WireGuard intégré au kernel Linux), et dans ce cas là, y'a pas de rotation.

Le chercheur a testé 3650 clés publiques, et il n'a obtenu que 284 combinaisons d'IPs distinctes alors que théoriquement, ça devrait donner des milliards. Bref, c'est moins varié qu'une plaque d'immat de votre département.

Imaginez maintenant un modérateur de forum qui voit débarquer un nouveau compte le lendemain d'un ban. Il croise les IPs Mullvad des deux comptes et tombe sur des plages flottantes qui se chevauchent, genre 0.4334 à 0.4428 d'un côté, 0.4358 à 0.4423 de l'autre. Hé bien ça veut dire qu'il y a plus de 99% de chances que ce soit la même personne. Et cela même si les deux IPs viennent de pays différents... argh !

Mais bonne nouvelle, pour fixer ce bug, c'est l'affaire de 5 secondes. Il suffit d'éviter de jongler entre 12 serveurs avec la même clé et voilà ! Et n'oubliez pas non plus de vous déconnecter de l'app Mullvad de temps en temps pour forcer la rotation de votre pubkey. Enfin, si vous êtes du genre puriste à utiliser WireGuard en direct via le client kernel, là c'est à vous de re-générer la clé manuellement, sinon vous gardez la même empreinte ad vitam.

Voili voilou...

Mullvad reste quand même un des rares VPN à avoir prouvé en justice, après le raid de la police suédoise en avril 2023, qu'il n'avait aucun log à fournir. Mais ce genre de problème mérite, je trouve, un petit patch côté Mullvad. Un petit seed aléatoire à chaque renouvellement de clé suffirait par exemple...

Et si le sujet VPN vous intéresse plus globalement, j'avais fait un guide complet qui peut compléter.

Source : tmctmt.com

Vous utilisez un VPN ou Tor pour protéger votre vie privée en ligne et vous pensez être tranquille derrière votre petit tunnel chiffré ?

Que nenni les amis ! Car un chercheur vient de montrer qu'il existe une technique pour démasquer les proxies TCP... et ça concerne potentiellement votre VPN aussi. Du coup, même si vous faites tout bien, y'a quand même moyen de vous griller.

Le projet s'appelle Aroma et son principe est redoutable car au lieu de chercher à identifier votre IP ou analyser votre trafic, il se contente de mesurer le temps de réponse de vos paquets TCP. C'est un peu comme si on pouvait deviner que vous portez un déguisement de dinosaure gonflable juste en chronométrant le temps que vous mettez à venir répondre à la porte (vous avez l'image ?).

Car oui, le ratio entre le RTT minimum et le RTT lissé donne un score. Connexion directe ? Ratio entre 0.7 et 1. Proxy TCP ? Ça chute en dessous de 0.3. Et sous 0.1, c'est quasi certain que vous passez par un intermédiaire.

Bref, ça s'appuie sur un principe physique qu'on ne peut pas contourner qui est la vitesse de propagation dans la fibre. Un RTT de 4 millisecondes correspond à environ 400 km max en ligne droite. Ça permet de poser comme une borne théorique sur la distance réelle entre le serveur et son interlocuteur direct.

Et pour les utilisateurs de Tor, la nuance est importante car le site distant voit la connexion avec l'exit node, donc le RTT mesuré côté serveur reflète surtout le chemin serveur ↔ exit node, pas l'ensemble du circuit. Donc c'est OK mais si l'exit node lui-même passe par un proxy TCP, là ça peut poser problème.

Maintenant côté contre-mesures, j'avoue c'est pas simple car cette technique ne repose pas sur des listes d'IP connues ou du fingerprinting de navigateur, donc les méthodes habituelles ne servent à rien. Toutefois en théorie, un proxy physiquement très proche (moins de 1ms de latence ajoutée) pourrait passer sous le radar...

J'ai trouvé cet outil intéressant car ça montre que même avec les meilleures protections logicielles, y'a des contraintes physiques fondamentales qu'on ne peut pas contourner. La bonne nouvelle c'est que pour l'instant, Aroma reste un proof of concept que vous pouvez tester ici , mais bon, rien n'empêche un gouvernement autoritaire (ou pas) de pousser le curseur un peu plus loin...