alt Hacker NewsMullvad exit IPs are surprisingly identifying
Comments
> As an example, imagine that you are a moderator on a forum and you suspect that a new face is actually a sockpuppet of a user you banned the day prior. You check the IP logs, and despite using different Mullvad servers, both accounts resolve to the overlapping float ranges 0.4334 - 0.4428 and 0.4358 - 0.4423. This gives you a >99% chance that they are the same person.
This sounds like how I'd design a VPN if I were an intelligence agency.
> As an example, imagine that you are a moderator on a forum and you suspect that a new face is actually a sockpuppet of a user you banned the day prior. You check the IP logs, and despite using different Mullvad servers, both accounts resolve to the overlapping float ranges 0.4334 - 0.4428 and 0.4358 - 0.4423. This gives you a >99% chance that they are the same person.
I don't see how the author is arriving at this ">99% chance" purely from the numbers provided in the article. Assuming the first (banned IP) seed and the second seed are both in the range 0.4423 - 0.4358 (a stronger assumption than is justified by the example), all this tells us is that the first and second IP addresses both have seeds in a range that would contain 0.4423 - 0.4358 = 0.65% of all Mullvad users, which 0.0065 * 100,000 = 650 users. We've eliminated >99% of users as "suspects", but we haven't actually gotten >99% accuracy in identifying an individual across multiple exit IPs.
In more Bayesian thinking, the overlap in potential seeds is great evidence to think these IP addresses represent one and the same person (or Mullvad VPN account at least), but as far as I can tell, that's not what the author is saying.
The purpose of a VPN does not include anonymizing users with respect to the sites they visit,so it shouldn't be too surprising that Mullvad doesn't enforce unique exit IPs. Users who want anonymity should use networks like Tor.
Missing from the story: did they reach out to Mullvad? Would have been interesting to see how their security team responded.
Great find by the author and I have no trouble believing this is an oversight by Mullvad. Kind of shocking that something this simple slips by them but I could see myself missing it.
Putting aside the IP correlation across multiple servers, at first I wondered why even keep the user IP stable on one server. But I think it makes sense because as the author states other VPNs usually have only one IP per server so they are essentially simulating that. The advantages for the user are, if they find a server that works for accessing some service they can connect to that server again and it will work again because they get the same IP.
The IP correlation across multiple servers they should fix though with something like rand.seed(user_pub_key + server_id)
> Surprisingly, the exit IP you are given is not randomized each time you connect to the server, but deterministically picked based on your WireGuard key, which rotates every 1 to 30 days (unless you use a third-party client, in which case it never rotates).
I'm a little confused on this... what is stopping third parties from doing key rotations like the main app clients if it is detailed in the repo how to do it?
It seems surprising that people would expect a VPN to be comparable to Tor.
It does seem ridiculous once you spell it out like that, and then you have to realize that it’s plausible to de-anonymize even Tor users by controlling exit nodes.
We keep adding layers of encryption and the metadata keeps snitching on us anyway.
I work for IPinfo. Even though we are in the VPN detection business, I will give Mullvad the benefit of the doubt, to be honest. They were one of the three VPN providers we found that did not attempt to submit inaccurate geolocation information to IP geolocation providers like us. I am sure they will fix the issue.
Given that Mullvad is basically a bulletproof VPN host[1], it would be great if site operators could rely on this property to enact bans. Given that the solution is simple (add a pseudorandom seed), Mullvad will likely push out a fix within a couple days.
1. It's the preferred VPN of TeamPCP.
I maintain a list of
"23034 IPs to blocklist.txt"
blocked IPs they contain all VPN providers. Often VPN providers seed Geofeeds with wrong data, this is why i use traceroute and ping network to locate their real location.
It's a game of cat and mouse. The service keeps banning IP ranges, the user keeps reconnecting to different servers and regions. The server can't know exactly who's who, just that a bunch of users are using mullvad, while the user just need to find one server on one IP range that works.
Seems like a good deal to me. I don't care if they know I use mullvad, I care they don't know I'm me, and that's not something mullvad will easily disclose.
surprising that the mapping may be stable enough to become a user-level signal. and rotating away from deterministic assignment seems like a cheap way to avoid creating an extra fingerprint
>Surprisingly, the exit IP you are given is not randomized each time you connect to the server, but deterministically picked based on your WireGuard key
What's the point of this? This seems more complicated to implement than mapping exit ips at the server level, so surely they must be doing this for a good reason?
This is why VPNs have always been crap. The pool of IPs are backlisted/tainted, so you will run into various roadblocks and cpatchas, in addition to slow speed. If you are serious about privacy and don't want blocks and blacklists, buy high speed private proxies. Don't use a pooled service.
Reusing the same VPN between multiple identities is a horrible idea regardless. And let's be real. As a forum moderator if you ban a Mullvad user and then a new Mullvad user signs up the next day it is probably the same person. You should be using residential or mobile proxies if you want privacy and to blend in to everyone else.
I just use it to watch iPlayer outside of the UK lol
[flagged]
[dead]
[dead]
I work at Mullvad. (co-CEO, co-founder)
Some aspects of the described behavior are as we intended and some are not. The cause is not exactly as described in the blog post. As for mitigation, we are already testing a patch of the unintended behavior on a subset of our infrastructure. If any of you try to reproduce the blog post's findings you may get confusing results throughout the day.
We will also re-evaluate whether the intended behaviors are acceptable or not. Some of this is a trade-off between multiple aspects of privacy, and multiple aspects of user experience.
Please note that this is my current understanding, which may change. I was only made aware of this an hour ago, and most of that time was spent talking with Ops, considering what to do immediately, and writing this post.
Finally, for those of you who do security research: when you find a security or privacy issue, please consider notifying the maintainer/vendor before publishing your findings, even if you intend to publish right away.