← Back to context

Comment by kfreds

5 hours ago

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.

25 comments

kfreds

Reply
azalemeth  5 hours ago

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.

lionkor  4 hours ago

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.

ignoramous  5 hours ago

> 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

  • abanana  31 minutes ago

    Are you seriously suggesting people shouldn't operate with a bit of common decency unless they're going to get some money out of it?

    • embedding-shape  27 minutes ago

      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 :)

      1 reply →

  • dust-jacket  4 hours ago

    Not having a bug bounty or dedicated email address does not make it OK to go public immediately

    • autoexec  3 hours ago

      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.

      5 replies →

    • r_lee  2 hours ago

      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?

  • wren6991  5 hours ago

    To support? Oof.

    • kfreds  4 hours ago

      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.

      3 replies →

999900000999  2 hours ago

Can we have an Open Suse client.

Sorta odd you don't support one of Europe's most popular distros.