Changer de serveur VPN suffit-il toujours à brouiller les pistes ? Pas forcément chez Mullvad, selon une analyse indépendante qui affirme que certaines IP de sortie WireGuard conserveraient un lien statistique d’un serveur à l’autre. Le fournisseur reconnaît un comportement à corriger et teste déjà des ajustements sur son infrastructure.
Mullvad se retrouve confronté à un problème plutôt embarrassant pour un VPN ayant bâti sa réputation sur la confidentialité renforcée. Dans une analyse récemment publiée, un chercheur répondant au pseudonyme de tmctmt affirme avoir identifié un défaut de corrélation dans la manière dont le service attribue ses adresses IP de sortie aux connexions WireGuard. Le problème ne révèle pas l’adresse IP réelle des abonnés et ne permet pas de lire leur trafic, mais il pourrait fournir assez d’indices pour relier plusieurs sessions au même internaute.
Offre partenaire
Votre petite entreprise a de grandes ambitions. Protégez-là contre les pirates. Et développez sereinement votre activité !
Offre partenaire
Des IP différentes, mais pas forcément indépendantes
Avant d’entrer dans le vif du sujet, il faut rappeler que, chez de nombreux VPN, plusieurs internautes connectés à un même serveur partagent la même adresse IP publique. Mullvad fonctionne autrement, puisqu’un même serveur peut distribuer plusieurs adresses IP de sortie. Ce choix d’implémentation permet de mieux répartir les connexions et d’éviter qu’une seule adresse soit trop vite repérée, bloquée ou ralentie par des sites capables de filtrer les IP de VPN.
Sur le papier, cette manière de faire n’a donc rien d’aberrant. Le problème relevé par tmctmt se situe plutôt dans la façon dont Mullvad choisit quelle IP de sortie associer à chaque utilisateur. D’après ses tests, cette adresse ne serait pas tirée au hasard à chaque nouvelle connexion au VPN, ni sélectionnée de manière totalement indépendante d’un serveur à l’autre. Elle serait au contraire dérivée d’un élément relativement stable de la connexion WireGuard, comme la clé publique associée à l’internaute ou l’adresse IP interne qui lui est attribuée dans le tunnel VPN.
Or cet identifiant ne change pas forcément lorsque l’utilisateur coupe sa connexion au VPN, puis lance une nouvelle session. La clé WireGuard tourne bien automatiquement selon un intervalle configurable dans l’application Mullvad, mais pas à chaque reconnexion. Tant qu’elle conserve la même valeur, plusieurs IP de sortie attribuées à une même personne sur différents serveurs peuvent donc suivre une logique commune.
C’est ce que montrent les tests publiés par tmctmt. Les adresses obtenues ne sont pas identiques, puisqu’elles appartiennent à des serveurs différents et à des plages d’IP distinctes. Mais les combinaisons observées étaient beaucoup moins nombreuses que prévu, et les IP attribuées sur différents serveurs semblaient suivre une même position relative dans leurs plages respectives. En clair, un utilisateur placé vers le début, le milieu ou la fin de la plage d’IP d’un serveur avait davantage de chances de se retrouver dans une zone équivalente sur un autre serveur Mullvad.
Pour bien comprendre le risque, il faut rappeler que ni la clé WireGuard ni l’adresse IP interne du tunnel VPN ne sont visibles depuis l’extérieur. Un site, une plateforme ou un autre acteur disposant de journaux de connexion ne voit que les IP publiques de Mullvad. Mais si plusieurs de ces adresses portent la trace du même calcul d’attribution, elles peuvent fournir assez d’indices pour rapprocher plusieurs sessions. Autrement dit, changer de serveur permet bien de changer d’IP publique, mais pas forcément d’effacer le lien statistique entre ces connexions.
Mullvad teste un correctif sur une partie de son infrastructure
La réponse n’a pas tardé. Sur Hacker News, le forum tech de Y Combinator, Fredrik Strömberg, cofondateur et co-CEO de Mullvad, a confirmé que tout ne relevait pas d’une simple erreur d’interprétation. Une partie de ce qu’a observé tmctmt correspond bien au fonctionnement prévu du service, tandis qu’une autre relève d’un effet non voulu. La cause, précise-t-il, ne serait toutefois pas exactement celle avancée dans l’analyse, qui soupçonne donc un tirage pseudo-aléatoire déterministe fondé sur un identifiant WireGuard stable.
Le fournisseur a donc lancé des tests sur une partie de son infrastructure pour corriger ce qui déraille, et prévoit de réexaminer les choix assumés jusque-là, l’attribution des IP de sortie relevant d’un équilibre délicat entre confidentialité, stabilité des connexions et confort d’utilisation.
C’est aussi ce qu’a souligné Carl Dong, CEO d’Obscura et partenaire de Mullvad. Randomiser davantage les adresses IP de sortie peut sembler évident dit comme ça, mais une adresse qui change trop souvent risque de perturber des connexions en cours, de provoquer davantage de captchas ou de déconnexions, et d’alerter les systèmes antifraude des sites web.
En attendant que Mullvad déploie son correctif, la manœuvre la plus sûre consiste à éviter d’enchaîner les changements de serveur avec la même clé WireGuard lorsque l’on cherche à séparer plusieurs usages. Il faut alors forcer la rotation de cette clé en se déconnectant complètement de l’application Mullvad, c’est-à-dire en quittant son compte avant de s’y reconnecter.
L’IP de sortie est l’adresse IP publique visible par les sites quand le trafic passe par un VPN : elle remplace l’IP réelle de l’utilisateur. Beaucoup de VPN font sortir de nombreux clients avec une seule IP partagée, ce qui “mélange” les utilisateurs mais peut attirer les blocages (captchas, listes noires) si cette IP est trop sollicitée. À l’inverse, un serveur qui dispose de plusieurs IP de sortie peut répartir les connexions sur plusieurs adresses pour limiter ces blocages et lisser la charge. Ce choix améliore parfois la disponibilité, mais il rend la façon d’assigner ces IP plus sensible côté confidentialité.
Que signifie une “corrélation statistique” entre IP de sortie quand on change de serveur WireGuard ?Une corrélation statistique, ici, signifie que les IP de sortie attribuées à un même utilisateur ne seraient pas totalement indépendantes lorsqu’il change de serveur. Même si les IP appartiennent à des plages différentes, elles pourraient présenter des régularités mesurables (par exemple une “position relative” comparable dans chaque plage), ce qui réduit le nombre de combinaisons possibles. Un service tiers qui ne voit que les IP publiques pourrait alors rapprocher plusieurs sessions et estimer qu’elles proviennent probablement du même utilisateur. Ce n’est pas une fuite de l’IP réelle ni un accès au contenu chiffré, mais un affaiblissement du cloisonnement entre usages.
Dans WireGuard, à quoi servent la clé publique et l’adresse IP interne du tunnel, et pourquoi leur stabilité peut poser problème ?WireGuard identifie chaque pair via une paire de clés cryptographiques ; la clé publique sert d’identifiant technique côté serveur pour associer des paramètres (droits, routage, configuration). Le client reçoit aussi une adresse IP interne dans le tunnel, utilisée uniquement à l’intérieur du VPN pour acheminer les paquets. Si l’attribution de l’IP de sortie dépend directement ou indirectement d’un identifiant stable (clé publique ou IP interne), alors des reconnexions successives peuvent produire des schémas répétables. La “rotation de clé” réduit ce risque, mais seulement si elle intervient au bon moment et suffisamment souvent, pas uniquement à intervalle fixe sans lien avec les changements de serveur.
