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.
I deeply appreciate Mullvad's thorough approach to privacy and ethics. In this day and age, you all are an absolute breath of fresh air. Thanks for that.
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 <hours>` 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.
Thank you for being on our side Mullvad. I'm using Mullvad through Tailscale. It's been an awesome combination for my self-hosting and privacy needs.
I just want to say I absolutely love Mullvad! You guys did a fantastic job at designing a genuinely good and trustworthy (as much as possible) VPN vendor. You communicating here is just another data point towards this.
Any chance on port forwarding coming back?
Thanks for the reassurances. Love your product.
> 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
https://mullvad.net/en/help/how-report-bug-or-vulnerability / https://archive.vn/BeHhrAre you seriously suggesting people shouldn't operate with a bit of common decency unless they're going to get some money out of it?
This ought not be considered anything close to common courtesy. This is work. Mullvad is engaged in the business of making money. They should show how serious they are with your money.
Since when do you have professionals giving you examinations out of common courtesy? Out of courtesy can I get a free cancer screening?
Most of HN readers/writers are American, of course they won't do anything unless they personally profit off it, the entire culture is built around this mindset. Meanwhile, Mullvad is Swedish, and we tend to assume we all want to help build a better world together. Mix the two, and you get this conversation :)
I would hesitate to make generalizations like that about a country with a population 35x larger than yours.
> Most of HN readers/writers are American, of course they won't do anything unless they personally profit off it, the entire culture is built around this mindset
American culture is highly varied. For some this is true, for others this is wrong and highly insulting.
Maybe try a narrower brush next time.
It's OK for the country to have a pervasive culture yet not every resident or citizen of the country to be a part of that culture, or even actively work against it. If you're not one of them matching that description, it shouldn't be insulting, as it's not about you in the first place.
Maybe not everything is aimed towards you, especially if you don't feel like the description actually matches you :)
I think the "others" should open their eyes to the world around them, then.
Not having a bug bounty or dedicated email address does not make it OK to go public immediately
Discovering a bug that could put people's lives and/or freedom at risk if they don't do something about it makes it okay to go public immediately. That said, by all means notify the maintainer/vendor as well.
It should always be assumed that someone else (if not several someone elses) have already discovered the same flaw and are currently taking advantage of it while users remain totally unaware of their actual risk. By going public immediately, you give as many of those users as possible a chance to protect themselves.
Waiting to disclose something harmful when the users in danger could otherwise take steps to make themselves safe would be like not warning people entering a building not to go in because of a gas leak until after you've contacted the building owner and the fire department has shown up.
> Expecting people to hold off on disclosure of something harmful
That's not what they said though. They said "please consider notifying the maintainer/vendor before publishing your findings, even if you intend to publish right away" (emphasis mine)
I do think hitting "send" on the email to the responsible party immediately before publishing (or at least notifying them as quickly as you can afterwards) is a smart thing to do. I mean, why wouldn't you? My concern was more about the "Not having a bug bounty or dedicated email address does not make it OK to go public immediately" comment. It can sometimes be difficult to track down the right person to notify and so when the risks to people are high enough whichever one you can accomplish the soonest is probably where I'd start.
Depending on the severity of the issue. Emailing support with a draft of the blog post and waiting even a couple of hours for a response so they can fix it first would have been more responsible than dropping the blog post to the whole wide world and catching Mullvad with their pants down.
Oh yeah fair enough
> Discovering a bug that could put people's lives and/or freedom at risk if they don't do something about it makes it okay to go public immediately
The flipside of course is ... does your disclosure increase the risk?
> aiting to disclose something harmful when the users in danger could otherwise take steps to make themselves safe would be like not warning people entering a building not to go in because of a gas leak until after you've contacted the building owner and the fire department has shown up
I don't think it's like this at all. The risk of a gas leak is not increased by telling people about it and can't be prevented after its occurred. To stretch your analogy, I'd say its more like you've found the gas leak and instead of turning off the gas supply are instead running around outside the building shouting about how there's a gas leak.
> The flipside of course is ... does your disclosure increase the risk?
When you've got that much on the line you have to assume that the risk is already present for all users. It's true that there's always a chance that some users won't find your disclosure in time and additional would-be attackers who weren't aware of it already will start taking advantage of the flaw, but the alternative is that no users are safe.
> The risk of a gas leak is not increased by telling people about it and can't be prevented after its occurred.
It's true that warning people not to enter wouldn't make the gas more dangerous, but it limits the death count of the impending explosion. It keeps at least some people from entering the building and walking into a death trap.
There's no way to shut off the gas supply when you can't control what's already running on user's devices and more users are downloading and installing the buggy code all the time. It's really not a perfect analogy. The point is that immediate action will save some people, while waiting around means that nobody has a chance of being saved.
Yes it does actually.
I don't feel like its hard to come up with examples where (I would say) its ethically wrong to disclose immediately. If you spotted a company's mistake that might endanger their user's lives or safety, would you put those users at risk simply because there was no obvious financial reward?
If so, I guess we just have different opinions on the ethics involved here.
if they don't think it's OK, then they should have a bug bounty program.
why are companies so entitled to get free security research/audits?
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.
> I'm not sure what you mean by "Oof".
I second this.
Clearly the person who wrote "Oof" has never emailed Mullvad support.
Whenever I have emailed Mullvad support I have received a prompt reply from a human being who clearly actually cares about taking ownership of the question and seeing it through to resolution.
I have also witnessed first-hand the support person taking the question to an internal team member where it requires additional input. So there are clear paths for escalation if circumstances require it.
Finally the support mail allows for PGP encryption of communications too.
(I am not a Mullvad shill. Not a Mullvad employee. Just a satisfied customer)
It still probably makes sense to alias it to security@mullvadvpn.net for privacy/security concerns.
I'm not familiar with how you run your company -- without the context you gave most people would hesitate emailing support@ for security issues.
Human psychology is weird and some things are just cultural. If you have the ops team make the security@ email alias just forward to support, you could avoid having to go into all that.
"Just email support@" feels like you don't care. That you do, and that your support team is awesome, doesn't change the fact that there are other companies out there who's aren't. Security people are human with human egos, and they want to feel special, so giving them a special way to reach you, even if it's the same thing behind the scene, makes a world of difference.
Can we have an Open Suse client.
Sorta odd you don't support one of Europe's most popular distros.
It already has official packaging for Tumbleweed, see https://github.com/mullvad/mullvadvpn-app/issues/2242 for the upstream issue. Leap can use the normal Linux application, you will just have to provide the dependencies yourself.
https://mullvad.net/en/help/install-mullvad-app-linux
>The Mullvad VPN app is available in our repository for the following supported Linux distributions:
Ubuntu (24.04+) Debian (12+) Fedora (42+)
The only thing I see on the issue you linked is a way to jerry-rig the fedora package. When I tried that I kept getting untrusted key warnings. You can skip them of course, but it kind of undermines any type of trust here
> When I tried that I kept getting untrusted key warnings. You can skip them of course, but it kind of undermines any type of trust here
Yes, the expected procedure would be to trust those keys for that package instead of disabling integrity checks.
This is an issue between you and your package manager and not something Mullvad or any other packager (except OpenSUSE maintainers) can fix for you.
You complain about the packaging and support of mullvad maintainers when you are having skill issues with your distro.
https://github.com/mullvad/mullvadvpn-app/issues/2242#issuec...