Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mullvad exit IPs are surprisingly identifying

tmctmt.com

Post reply on HN
Print view View original

191–200 of 408 posts

Re: Mullvad exit IPs are surprisingly identifying

#191

Post by TurdF3rguson »

lxgr wrote: post #177
tschumacher wrote: post #171

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…

> 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. On the flip side, if they’re getting banned by a service because of a noisy neighbor on the same IP, they’d have no way to work around that, no?

You mean if the neighbor somehow burned every VPN location?

Re: Mullvad exit IPs are surprisingly identifying

#192

Post by azalemeth »

kfreds wrote: post #178

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 wheth…

You really do provide a reassuring, good service -- thank you.

It's also worth stating that the client (including the cli client -- which, with a bit of work, you can get running in most situations where you'd use native wireguard) by default has a key rotation interval of I think 72 hours.

`mullvad tunnel get` will show it and `mullvad tunnel set rotation-interval ` will change it. This is the preferred mitigation method of the post.

I personally don't mind having a pseudo-static IP (some other suppliers offer a static IPv4 as a feature!) as I wish to prevent network-level snooping from my ISP and governments. It's also worth stating that I think having a smaller IP space is an advantage for a privacy VPN: there are more potential users acting behind any given externally visible IP. Combined with technologies like DAITA (which effectively adds chaff to the tunnel) and multi-hop entrances and I personally think that this service really does plausibly make harder the life of those who snoop netflows all day.

Re: Mullvad exit IPs are surprisingly identifying

#193

Post by codethief »

arcfour wrote: post #173
solenoid0937 wrote: post #32

> 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…

Mullvad predates the Snowden leaks by several years and was not mentioned anywhere in them. Sure, there are other intelligence agencies, but that's the one I'd be the most worried about. Since either they run it, or they would know of it and want to emulate the idea, or know of it and have access to it from the partner agency running it. Or they are not a threat to me. There's also the issue of no publicly known case…

> Mullvad predates the Snowden leaks by several years and was not mentioned anywhere in them.

Wow, I didn't realize Mullvad was this old! Then again, maybe they weren't popular enough back then for intelligence agencies to target them? For instance, Mullvad kinda rode WireGuard's popularity wave by being the first(?) VPN provider to implement the protocol. Big ads on billboards came even later. So maybe they only became a target in recent years?

Re: Mullvad exit IPs are surprisingly identifying

#194

Post by wren6991 »

ignoramous wrote: post #186
kfreds wrote: post #178

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 wheth…

> 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 How to report a bug or vulnerability ... we (currently) have no bug bounty program ... send an email to support@mullvadvpn.net https://mullvad.net/en/help/how-report-bug-or-vulnerability / https://archive.vn/BeHhr

To support? Oof.

Re: Mullvad exit IPs are surprisingly identifying

#195

Post by MuteXR »

hackinthebochs wrote: post #160
linkregister wrote: post #120

Earlier quoted context omitted.

Then why complicate it by being publicly insecure? If Mullvad were wanting to defeat anonymity, they could simply log the traffic metadata while falsely advertising they aren't. Their ads on San Francisco's public transit are good.

Good VPNs tout the fact that they had nothing to give in response to a subpoena, or that there was nothing a law enforcement agency to find when they seized a server. For mullvad to be effective as a honey pot it needs to survive these events with its reputation in tact.

If it were a true honeypot by a state agency, they'd be able to just lie about having nothing too.

Re: Mullvad exit IPs are surprisingly identifying

#196

Post by reincoder »

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.

Re: Mullvad exit IPs are surprisingly identifying

#197

Post by netdevphoenix »

linkregister wrote: post #124
sph wrote: post #103

Earlier quoted context omitted.

That’s been my pet theory from day 1, and not because of DDoS. Simply because they are the SSL terminator for most of the internet and can see anything going on in cleartext (and I’ve seen them protecting some shady stuff) I recall a PRISM slide showing the diagram of Google and the public internet, with a big arrow on GFE saying, quote, “SSL added and removed here! :-)” If NSA aren’t installed at Cloudflare, I wonde…

It's within the realm of possibility that NSA is collecting data with Cloudflare's consent. It seems unlikely that Cloudflare would jeopardize their entire business model over it. Unlike other companies in the leaked NSA slides that participated in PRISM, Cloudflare would face a near-total loss of customers. Their entire value proposition is being an unobtrusive traffic intermediary.

> Cloudflare would face a near-total loss of customer

I think more people than you would expect would be happy to accept that as the price for protection against malicious actors

Re: Mullvad exit IPs are surprisingly identifying

#198

Post by cubefox »

jesterson wrote: post #164
cubefox wrote: post #89

Earlier quoted context omitted.

> Almost all commercial VPN services farm and sell your data. Citation needed.

I understand it's not up to your (or anyone's) level of belief, but I am in intimately familiar with their modus operandi. For everyone in the industry it is le secret de Polichinelle.

I think they don't sell their VPN data, because if that ever came out, that would destroy their business. Selling the data would be far too risky for them.

Re: Mullvad exit IPs are surprisingly identifying

#199

Post by netdevphoenix »

linkregister wrote: post #148
sph wrote: post #130

Earlier quoted context omitted.

> Unlike other companies in the leaked NSA slides that participated in PRISM, Cloudflare would face a near-total loss of customers People didn’t care when they learned about PRISM, why would they care now when it’s a known fact? The sane stance would be to assume Cloudflare is in cahoots with NSA.

All the companies involved in PRISM made public statements saying they ceased participation. Google undertook a costly initiative to add encrypted connections over their datacenter circuits. The NSA leaks were a forcing function that led to a massive uptake of encryption. Up until that point it was common for websites to support only HTTP. The NSA leaks dominated news cycles for the entirety of 2013.

> All the companies involved in PRISM made public statements saying they ceased participation. Google undertook a costly initiative to add encrypted connections over their datacenter circuits

This is as helpful as Whatsapp's so called E2E encryption comms (that just happens to not be applicable by default in certain situations).

Re: Mullvad exit IPs are surprisingly identifying

#200

Post by kfreds »

wren6991 wrote: post #194
ignoramous wrote: post #186

Earlier quoted context omitted.

> 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 How to report a bug or vulnerability ... we (currently) have no bug bounty program ... send an email to support@mullvadvpn.net https://mullvad.net/en/help/how-report-bug-or-vulnerability / https://archive.vn/BeHhr

To support ? Oof.

I'm not sure what you mean by "Oof". We don't have a dedicated security team because security and privacy are integral to all aspects of our service. It doesn't make sense to centralise it.

As for our support team they are responsive and experienced. Several of them have worked with us for many years and do offensive security research in their free time.

Unlike many organisations we don't see customer support as a cost center, just like we don't see security as a cost center. Our support team represent our customers, and as a consequence contribute a lot to how we prioritise our roadmap.

Post reply on HN