WireGuard multihop available in the Mullvad app | Hacker News Reader

WireGuard multihop available in the Mullvad app

mullvad.net

379 pointsqalter130 comments

This isn't Tor-like multi-hop (but is similar to other multi-hop VPN providers out there). A proper multi-hop would happen across two different vendors in control of two different networks, as it were.

The iCloud Relay paper outlined a pretty private and secure design [0] (and the intention to standardize it via IETF would probably make it simpler to self-host such a solution [1][2]). Among the VPNs, orchid.com's distributed VPN stands out as a cross-provider multi-hop solution whose privacy guarantees are closer to Tor's.

Eventually the hope is HTTP (www) itself bakes in desirable privacy properties, so regular users don't have to pay the cost of multi-hops [3].

[0] Overview: https://datatracker.ietf.org/meeting/111/materials/slides-11...

[1] https://ietf-wg-masque.github.io/

[2] https://tfpauly.github.io/privacy-proxy/

[3] https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/

Splitting hairs no? I mean you're comparing multi-hop with onion routing.

I'm just speaking as a layman end user. When I see multi-hop it's self-explanatory, it's literally in the name.

Onion routing is another type of multi-hop with the onion routing algorithm.

Since it's the same company with access to both the first and second server, it wouldn't be too hard to log network on both ends and sync it up.

With iCloud Private Relay, it'd be harder for a single actor to de-anonymize requests; you'd either need collusion between the companies or a government entity would need to ask both companies to log network traffic at once, and this would complicate the "exit node" server since it can't filter/only record traffic from the target customer's connection without company 1 setting up a single server dedicated to being the proxy for that customer.

The point of multihop, tor or otherwise, is for each node in the route to not know what the other knows. The first node sees packets coming from you, but not where they're going. The second see's where they're going but doesn't know where they're from (and vice versa). If the two nodes exchange this info (ex. if same person runs both nodes) then there's no point. Nothing is gained, you just incur the overhead of the extra hop.

Where is this defined? Because the word multi-hop only implies more than one hop. Anything else needs to be defined as a specific algorithm, like onion routing for example. That's why I think this is semantics.

I think what people want in this case, is quick access to a different exit IP to appear on the internet with.

Shameless plug, for my undergraduate senior thesis in 2014 I coauthored a paper related to this called “A TorPath to TorCoin” [0]. The main premise was proof-of-bandwidth cryptocurrency, but its resistance to Sybil attacks was partially dependent on assignment of publicly verifiable but privately addressable circuits. So the “TorPath” part was about circuit assignment, and in retrospect perhaps more interesting than the cryptocurrency aspect of it. The tl;dr is a Neff shuffle with a matrix of relays and assignment servers.

We never developed it further beyond the initial research (it was senior spring, not a lot getting done, I even forgot to buy Bitcoin). I remained (and remain) interested in decentralized VPN networks, and played around with implementing something around it, but ultimately I didn’t have the experience to build what I wanted.

Personally, I like what Orchid, Tailscale and ZeroTier are doing. I also like Fly.io and Cloudflare Workers and generally any product that iterates toward a Network Function Virtualization (NFV) platform. The root obstacle is incumbent compute-based clouds oversubscribing compute by gouging on bandwidth. This makes the cloud environment inhospitable for any cost-effective, transit-intensive business like a CDN/VPN, increasing the barrier to entry by requiring self-hosting a distributed network.

[0] https://dedis.cs.yale.edu/dissent/papers/hotpets14-torpath.p...

For what its worth I have used the open source Tinc VPN [1] for mesh multihop routing for ages. It is nowhere near as fast as Wireguard but I could envision Tinc incorporating support for Wireguard if the author were so inclined. Like you mentioned Tinc does not mesh directly with other VPN's AFAIK. I've had to use route statements to join it with Strongswan and other VPN networks.

[1] - https://tinc-vpn.org/

I use (and really like!) Mullvad, but have never tried the app, preferring to use my existing OpenVPN clients with the profiles Mullvad provides.

This isn't because I have any reason to mistrust their app, but just because if I've already got a perfectly serviceable client on my device, why add another binary to do the same thing?

But I would be interested to hear, from folks who have used the app, what you like and don't like about it. In particular, I've had some headaches setting up split tunneling/proxying via OpenVPN - I was never all that good at its config language - and I'm wondering if the Mullvad app might make those easier to achieve.

I've found their apps to be (subjectively) higher quality than most OpenVPN clients on platforms I care about (macOS, iOS, Windows). It's nice to have a consistent UI, and not have to think or care about specific profiles — it's easy for me to jump between servers much more easily (I typically connect relatively locally, but occasionally find that certain out IP addresses have been blacklisted from specific sites; it's trivial to "refresh" the connection to hop over to a different server and not have to think about it).

And, of course, easier (for me) to set up and configure. Maybe no _huge_ incentive to switch over to it if your setup works, but might be worth trying out if you're curious.

I'll +1 your anecdote with mine: that Mullvad's app is pretty great. It's very simple, isn't buggy, has just what's needed, and has a good UI. I'm pleased with it. Better than the others I've used.

I'll also +1 your anecdote that the Mullvad app is simple, convenient and stable.

I would agree with a couple additional points. The first is that the app has a nice GUI that works across all platforms I'm interested in (mainly Linux) - but it also has a very handy CLI.

I've also found that the client devs respond to issues. This is great as well as I feel as though I'm getting a complete solution with Mullvad.

While I have no doubt Mullvad is great as a vanilla VPN without their client - I feel as though I'd be missing out on a few features and convenience items if I were forced to bring my own.

And to be clear - while Multihop is new, it's not new as in today. It's been out for a while in beta (if I'm remembering right) and landed in GA about a month ago. I don't see much need for it in my use case, but it's nice they're continually enhancing the overall product.

The app is great in my opinion, giving less-technical users a simple interface to toggle their VPN connection and see at a glance where their chosen server is on a map.

If you're comfortable setting up OpenVPN profiles, the Mullvad app doesn't have much to offer you as far as I can tell. I don't recall seeing split tunneling options, though that would be cool to see

I've been using the app for a couple of years now and I have mostly enjoyed the experience relative to the few other VPN solutions I've tried (OpenVPN, Nord (old version), ProtonVPN).

Things I mostly like:

- The relative simplicity of the app interface (though 'advanced' settings should just be a sub-section of 'preferences')

- How quickly/easily I can get connected (download, paste in account #, click connect - or change location.

- Relatively easy split-tunneling

- Easy switch between OpenVPN and Wireguard protocols

- Easy local network sharing (preference toggle)

- Tracker and ad block options (have not tested efficacy, appears to be DNS-based)

- Internet kill switch (will not fall back to non-vpn connections if set)

Things I don't like:

- Can cause issues on boot/reboot if kill switch is enabled (Windows - disable kill switch, restart app, re-enable kill switch)

- Limited options for mobile apps (and some unexpected disconnections on android)

- No configuration of app layout or color scheme

- Somewhat annoying upgrade (not bad, just no in-place upgrade solution)

The Mullvad app is huge ~100MB which is odd for what it needs to do.

I believe it's Electron-based, which is another reason I've hesitated to try it out. I like Electron - from the developer's perspective, it's great! - but I do still try to avoid its resource impact until there's a compelling reason to take the hit.

My mullvad installation on Windows has 258MB but memory footprint is low. I find 5 entries in the task manager with a total of 14.6MB with active connection.

Maybe not Electron, then. Perhaps I'm confusing it with ExpressVPN's first-party app, which definitely was Electron when I tried them a few years back.

It does use electron. The source code is available on github.

https://github.com/mullvad/mullvadvpn-app

That is one of the nitpicks that I missed, along with their downloads being excruciatingly slow when already connected to the service, for whatever reason (I may just be doing something wrong).

I've noticed that as well. The trick as I found (and even recommended by their support) is to download from their GitHub repo.

If you don't want to switch to the Mullvad app, it's still worthwhile to switch to their wireguard profiles. Connections seem more stable and wireguard is far easier to configure.

Hey I’m curious about the terminology you guys are using here. Is there a manual or a page which I can read to learn more about wireguard profiles and what mullvad has done for them perhaps?

Wireguard is the latest VPN protocol. Check out the Wikipedia page (https://en.wikipedia.org/wiki/WireGuard) or it's homepage (https://www.wireguard.com/). Not all VPN providers support it yet (notably Proton VPN), but it is generally faster and more secure than OpenVPN.

It was made by Jason A. Donenfeld.

Search HN re Wireguard. It's a much more secure, efficient, and very widely respected. Linus has integrated it into the kernel, for example.

Linus has integrated more than a few questionable things into the kernel so that’s not a ringing endorsement for me. Perhaps it’s a good implementation for the new standard, perhaps not. Regardless, I want to say to you that I appreciate your comment and I’m going to go off and do some further research before I begin to have an opinion.

Split tunneling an app to NOT GO THROUGH the tunnel is easy

Setting split tunneling to ONLY TUNNEL A SPECIFIC APP is hard

I don't use OpenVPN but wireguard, but I do use split tunneling and my setup is a bit complex but not hard to achieve.

I wanted to have a VPN up 24/7 but certain sites apps don't really like VPNs. I basically have steam and privoxy set as my split tunneling apps. Steam because it seems their website's CDN breaks half the time and privoxy so I can access specific websites without a VPN.

For privoxy to work properly I use a browser extension called SmartProxy[1] which lets me setup a proxy and then I can quickly add/delete sites from using that proxy, I just add 127.0.0.1:8118 and I can basically have any site either use the VPN (default) or whitelist it so it goes through my home connection.

[1] https://chrome.google.com/webstore/detail/smartproxy/jogcnpl...

Why not use a wireguard client instead? Connection is instant (unlike openvpn which can take a few seconds to connect) and drains less battery as well. Their app uses wireguard as well, and you can use other wireguard client too.

My main application is to get passed region block to keep up with news/TV in other places I've lived previously. The app makes changing your exit node very straight forward and I've not encountered any bugs, so it does what it should.

I’m wondering how this compares to Apple’s iCloud Private Relay.

Mullvad is trying to increase their transparency and make sure users can trust them which is great. But would there be a way for them to make it so that users do not have to trust them? What if the second server was hosted by another entity?

I believe that with iCloud Private Relay, the second hop is a different company (Cloudflare/Akamai/Fastly). Whereas multihop offered by Mullvad and other VPN companies they own both hops which would make correlation easy for them.

"I'm wondering how this compares to Apple’s iCloud Private Relay."

Simple answer: Apple doesn't get your info. Mullvad is one of the non-logging VPN providers so unless you're compromised in some other way (like logging into Google, Facebook, etc) then running a make on your is far more difficult than just serving a warrant to Apple.

> Mullvad is one of the non-logging VPN providers

How do you know that they're not logging? Or that their ISPs are not logging?

Here's the latest Mullvad security audit (June 2020).

https://cure53.de/pentest-report_mullvad_2020_v2.pdf

Unless I'm mistaken that's just a security audit of their client applications, which would not in any way prove that they aren't logging.

You are correct. I don't use Mullvad and had assumed this was an audit of their infrastructure, not their app. Thanks for pointing that out.

I don’t believe there’s any way to completely validate any service providers claims - there’s always a bit of trust required

That said, mullvad facilitates fully anonymous signup and payment, if you’re so inclined… so in that regard even if they’re secretly logging, if your OPSEC is up to par then it’s fairly moot.

Just my 0.02$

Then the user would just go find a second VPN provider.

I'm a happy Mullvad user. But I have one concern.

Recently, Instagram "tagged" my account as either based in Russia or using Russian currency. I'm based in Western EU and set up the VPN to connect to the same country or neighboring ones.

I'm trying to figure out if some endpoints belonging to Mullvad have been shadowbanned by Meta/Instagram. Is there someone else who uses Mullvad to surf on Meta products whose account has been impacted by sanctions directed at Russia?

My first guess is that it's a mislabelling problem or bots going rogue for an unkown reason. And, IG support is taking too long to clarify what's the culprit. So, I'm making all kind of hypotheses to reach a logical explanation before getting an official answer.

I suspect that "Russian" will be the new pejorative that Big Tech is able to throw at anything they feel like banning. Want to ban a user for using a VPN because it's harder to track them? Accuse them of being "Russian linked" and bam, no further justification needed.

You probably don't even need to lie, it's likely Russian hackers are using every major tor/VPN available commercially.

I've noticed the IPs on their relatively newer servers using "xTom" as a provider are being incorrectly identified as Russian by some IP based geolocation services... it's a bit hit or miss.

I'm guessing xTom acquired an IP block from someone in Russia a while ago and IP geolation databases are just very slow to update.

I use Mullvad and I constantly run into things like ASN bans etc. For example, cloudflare often bans whole ASN making many websites not accessible through Mullvad.

Seems like mullvad is being used by a lot of bad actors and they're not really doing anything about it.

I like their software and monetization but their IPs are probably the lowest quality IPs in the VPN market.

> Seems like mullvad is being used by a lot of bad actors and they're not really doing anything about it.

If you set up your own VPN server on popular cloud platforms, you'll notice that almost all Cloud platforms face the same issue. Basically this is what you get when you use a data center IP for Internet browsing.

It's a bit odd to indict Mullvad for not doing anything about nefarious actors using their service, as the whole selling point of their service is that they don't keep track of who is up to what. If they start policing user traffic, I will cancel my service, and I'm sure many others would to.

FWIW I run my own VPN server on a common cloud provider, and I actually encounter more trouble there than when I'm logged into Mullvad. I think the services who can't think of more creative solutions than blanket IP bans are the real problem here.

Tangentially related:

Users can use Mullvad’s TOR address: http://o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7k... to generate their account ID and make their payment with Bitcoin seamlessly.

I have never experienced such a smooth way to purchase from a provider, this was brilliant.

+1 to Mullvad

The ease with which you can pay anonymously makes me feel that its more likely a genuine privacy provider rather than a CIA run honeypot like Crypto AG.

You can also mail them an envelope with your user ID # and some cash. It's pretty great.

I started by using the cash-in-an-envelope option. For my most recent subscription, I paid in Bitcoin. All methods were pretty easy, neat and fast.

Bitcoin is not private but many people don't know this, and they refuse to accept Monero, so I follow the same logic but come to the opposite conclusion.

How does it matter that your payment is anonymous when all your traffic is going through them?

If mullvad gets compromised, you can still remain anonymous if the payment method is anonymous as long as the traffic you've sent to mullvad been anonymous as well. Obviously, if you log into your normal Facebook account, it isn't, but there are plenty of other uses.

If mullvad is compromised, then all my traffic is also compromised and potentially my client machine is also compromised (since I'm running mullvad client). Alternately, to begin with, if my traffic wasn't sensitive or personally identifiable, then I don't actually need this multi-hop setup.

Yes, if mullvad + your machine is compromised, then indeed there is not much you can do. But first, not everyone uses mullvads client, but instead the provided configuration files for wireguard/openvpn. Secondly, not all traffic is indeed personally identifiable, especially if you're using something like mullvad with for anonymous traffic to begin with. Imagine you have another account than vinay_ys that you only use via mullvad (and potentially other accounts). Using something like cash (or bitcoin for that matter) as a payment method makes it less likely the real person you will be connected to this other account.

Security and privacy is not a true/false thing, it's a thing you do at layers. Making payments anonymously is obviously adding another layer. Maybe it's not worth it for you, but for some it is.

With a Wireguard VPN to reach Internet, all traffic from this machine meant for Internet is going via the tunnel, including the OS generated background traffic, and application generated background traffic (like update servers, analytics beacons/telemetry, license verification servers etc). These can contain tracking identifiers that can be tied back to app purchases, and even laptop purchase itself.

If you really have only limited sensitive traffic (even with fake identity), you are better off using just tor browser than using a full machine vpn.

Yes, indeed, if there is identifiable traffic coming from the OS, you're screwed. This is why I said "not all traffic is indeed personally identifiable". If you are doing things where you have to be anonymous, there are plenty of OSes you can run to not have all those things giving away your identity. If you think just adding a VPN on top of the OS you use for other things, you're screwed.

I think you're missing the point here. Even if you use Tor browser or a completely new OS installation of Tails or whatever, if your payment method can be tied to you, you're once again screwed. Being able to anonymously pay, removes that vector, it's as simple as that.

The point was exactly that – you are already screwed, irrespective of being able to pay anonymously. If you are the kind of actor who will (or needs to) take all the countermeasures needed to be truly anonymous at a whole machine traffic level, then you are likely not going to be using mullvad.

To a typical customer of mullvad who also reads hn I would say this – you aren't going to gain any additional privacy by using anonymous payments. Here's why: either you believe Sweden is a safe haven for user data privacy or not.

– If it is, then you have nothing to worry about even with payment method tied to you.

– If it is not, then a Swedish government agency can compel mullvad to reveal the customer details (like payment method details) based on the WireGuard UDP socketpair details. But then they can also very likely compel mullvad to give them a live dump of traffic within the tunnel.

For truly high-risk people (journalists/whistleblowers against powerful entities, not regular geeks who want to block ad tracking), I'm not sure if any vpn service like this is a net help or does it actually cause more harm.

> If you are the kind of actor who will (or needs to) take all the countermeasures needed to be truly anonymous at a whole machine traffic level, then you are likely not going to be using mullvad.

That's the wrong conclusion. The right one is: if you're the kind of actor who needs 100% privacy, mullvad is likely a part of solution (because of their track record), together with many other services and tooling. No one relies on one part to remain anonymous, as again, privacy and security depends on layers, not just a single layer.

> either you believe Sweden is a safe haven for user data privacy or not.

Even if Sweden is "a safe haven for user data privacy" or not, the government is not the only threat against mullvad. Mullvad themselves, the location they have their servers, their payment processors and many else can also be compromised. Paying Mullvad in cash (and protecting yourself in more ways) helps more than paying with a credit card attached to your full name, as any middleman can be compromised (and not just by a government).

> For truly high-risk people (journalists/whistleblowers against powerful entities, not regular geeks who want to block ad tracking), I'm not sure if any vpn service like this is a net help or does it actually cause more harm.

High-risk people don't rely on a single VPN service but again, layers of them in order to facilitate things like proxy chaining and multi-hop.

But, talking with you back and forward, makes it clear that you haven't actually engaged with any of these "high-risk people" you feel so sure to proclaim how things work for. I urge to actually talk to some of them and see what kind of setup they can tell you about, as you'll learn some more about how you can protect yourself and remain anonymous, if you really want to.

No idea how mullvad setup is done, but in theory I think you could use Tor -> mullvad wireguard configured VPN -> target site.

That way your traffic would be "legitimized" (no infernal Captcha loops), and if the sites you visit have certificate pinning mullvad network compromise wouldn't matter.

A bunch of ifs, but that's the state of things.

edit: written before thinking out all the details, probably can't tunnel udp connections over Tor.

Tangential, but I recently discovered Mullvad. For years, I've used whichever mainstream VPN provider had a good deal on come renewal time, and cycled through a few of the usual suspects. Recently, I was with Surfshark, and was really struggling to get download rates above a few hundred K/sec - and sometimes even worse. I didn't even suspect the VPN at first, but ultimately tried a different provider as a diagnostic step.

I randomly came across a recommendation for Mullvad from reddit, and signed up for a month. Hot damn if my download rate didn't shoot up to 15-20 MB/sec (that's megabytes, not bits) - essentially close to maxxing out my fibre.

Turns out you really do get what you pay for - and I doubt I'll be leaving Mullvad any time soon.

(no affiliation - just a happy and surprised customer!)

+1 for Mulvad, it Just Works and they are a great service provider.

(also no affiliation, just a happy customer)

Which exit point are you using? How close is it to you? I only get about 5MBps no matter which node I use and have suspected ISP throttling, but haven't tested too much since 5MBps is enough to get by with; this might make a good way to gather more info.

With Surfshark, an assortment of (mostly) European locations - e.g. Germany, Netherlands, Czech Republic, Switzerland. When things were slow, the choice of exit location didn't seem to make much difference - tho' sometimes I needed to cycle through to find one that worked at all.

With Mullvad, a similar choice of locations - again, it doesn't seem to matter, but in a good way.

How are Mullvad apps across multiple platforms? I've been with PIA for quite a while, and I got it to work they way I want it, on macOS, windows and android, and I liked even more some of their recent exit points marked "for streaming", as I watch sports online, and there is a significant improvement when using those, with some countries local free broadcasting, but performance in the rest , sometimes, is really atrocious. I am just concerned about trading performance gain for tweaks/options/stability on multiple platforms (never found OpenVPN to be better, at least when it comes to PIA apps).

used it on macos, ios, linux. the app is solid. wireguard rules.

I use the app frequently on Android and Arch Linux, and it works equally well on both.

I use it on Mac, Windows, and iOS - they just work well.

The ios app reviews of PIA says it's now owned by a company which used to make malwares. I'm really happy with PIA as compared to Mullvad. Works better for me but this review is making me feel unsafe :(

The PIA app is lovely. Mullvad's as well

I used mullvad for streaming sports in Australia being in Europe at the time, no problem streaming in full HD. My machine is running linux although I doubt that makes a difference.

Mullvad is fantastic. I get full bandwidth when torrenting 24/7 from my NAS, and I don't get blocked when I need to stream something unavailable in my country, and they have port forwarding support. They also have an Android TV client so I can watch on my couch.

All for €5 a month? Such a great company.

That's strange. I've had the opposite experience. I was with Cyberghost and, after 3 yrs of good speeds, almost overnight it basically became so slow that it was unusable. I then tried out Surfshark and have been very happy with the speeds that I've gotten for the past year+.

I had been with Surfshark for nearly a year when everything slowed down. They could have been having temporary technical issues, of course, but it went on over a long enough period that my troubleshooting made it through multiple steps to trying a different VPN provider - so over a week, IIRC.

In the end, it depends on how your ISP peers with your VPN provider's network. VPN companies tend to host their servers on networks with cheap bandwidth, which don't necessarily have great peering with many residential ISPs.

The UI we have is somewhat awkward, but this has also been supported for a while in our Orchid app (to the point where I have been actually working on another app designed to surface this one feature better, but that isn't out yet), supporting arbitrarily deep tunnels across multiple WireGuard (or OpenVPN, even going back/forth between them) providers (unlike this, which seems to just be "two hops, both from Mullvad").

Have been using them off and on for years. Met some people who work for them at some conferences. Company makes a great impression in general.

My favorite thing they do is trying to make server infrastructure transparent:

https://mullvad.net/en/blog/2022/1/12/diskless-infrastructur...

Lots of bumps here in support of Mullvad and it's warranted. OVPN is another that is top-rung as far as quality, no-logging, speed, etc. They even went to court to prove they didn't have any logs. Not affiliated, just a happy subscriber. Support Wireguard too.

IVPN has wireguard multihop since a while I believe: https://www.ivpn.net/knowledgebase/general/what-is-a-multiho...

The iOS app has been more reliable than the mullvad app so far, which is the reason I switched. Additionally, it allows to configure "trusted" and "untrusted" networks, which is quite useful as well. (And yes, this is not a secure feature, as a network can easily be spoofed, but I use IVPN mostly for data privacy and not for safety/security reasons)

"The entry WireGuard server will be able to see your source IP and which exit server the traffic is headed for, but it can’t see any of the traffic."

So server2 terminates the request twice? One for server1 and another time for the client who generated the request? I don't understand how it's possible for server1 to not be exposed to the data.

You probably missed

> It’s a WireGuard tunnel being sent inside another WireGuard tunnel

Edit: replaced with a better diagram (and again, now based on example in [0]):

                   ▼    ▼                    ▼    ▼
                  YOU->NL1 tunnel           SE4->NL1 tunnel           PLAIN/TLS

            YOU ────────────────────► SE4 ───────────────────► NL1 ───────────────► CATPICS.COM

    On the wire:  YOU->SE4 traffic          SE4->NL1 traffic       NL1->CATPICS.COM traffic
                 ┌────────────────┐        ┌────────────────┐            ┌──────┐
    Inside:      │YOU->NL1 traffic│        │YOU->NL1 traffic│            │ DATA │
                 └────────────────┘        └────────────────┘            └──────┘

[0] https://mullvad.net/en/help/wireguard-and-mullvad-vpn/

This isn't how it works. If you actually pull down one of their multihop configurations - you'll see:

- the WireGuard public key for server 2

- the IP address for server 1

- a unique port for server2 on server 1

So all they're doing is a standard iptables redirect to the second host (which may or may not itself be under a WireGuard tunnel).

Well, I stand corrected, because I relied on their promo description. *shrug_emoji*

I replaced the diagram in the previous comment, take a look.

This can be very confusing indeed, since there are multiple ways of doing multihop. Please see my description in https://news.ycombinator.com/item?id=31012071.

The guide at https://mullvad.net/en/help/wireguard-and-mullvad-vpn/ only talks about how the config files does it. Which is completely different from how the app does it!

Your description is correct for the configuration files, yes! But it's not correct for the app. There are multiple ways of doing multihop with Mullvad. The config files use a simple redirect where each server has a unique port it's reachable over on all other servers. That's what the config files are doing.

But the app actually has a wg tunnel inside another wg tunnel. If you (on Linux) run `wg` (as root) in a terminal when it's connected with multihop you will see that it has two peers set up for the `wg-mullvad` interface, one peer is routed through the other.

So the only thing that SE4 can see is encrypted WireGuard traffic headed for NL1.

Are we required to force it to use Wireguard instead of "Automatic" for this to work?

Seems similar to ProtonVPN's Secure Core, but using Wireguard directly. Nice.

I see you like wireguard, so i put a wireguard connection in your wireguard connection. jokes aside, huge fan of wireguard and mullvad

Has anyone got multihop working using the standard Wireguard app? Can it be added in config files or is it by CLI only?

This thread seems to be full of people that use a VPN, I personally don’t as I find DoH + HTTPS to be enough.

Why do so many of you use VPNs?

1) To simply make it harder for my ISP to see which websites I visit.

2) SNI sniffing makes some websites unavailable to me, so DoH isn't enough.

I’d never considered SNI sniffing. Great point. I’m quite fortunate in that the ISP I’m with (AAISP) is fairly privacy first and don’t _appear_ to be snooping on me in any meaningful way.

That said, I can’t say the same for my phone provider.

But do you also trust your phone carrier? (I don't trust either my ISP nor my phone) Or when you're out on WiFi that isn't yours? It's a cheap way to add a little extra bit of security and privacy.

> don’t _appear_ to be snooping on me in any meaningful way.

SNI is cleartext enough to be passively logged, so you never know. Maybe some government-mandated (or supplied) switch is logging them to some short-lived log file in case they ever need to pull your hostname history.

Note that SNI sniffing protection is in the works by encrypting the client hello[0]. While it's been in draft for some years now, Chrome has a lot of work being put into it[1], so hopefully it'll be done sometime next year with support within Cloudflare and browsers soon after.

0: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?includ...

1: https://bugs.chromium.org/p/chromium/issues/detail?id=109140... (comment 20 onwards)

3) Even without SNI sniffing and DoH some sites could be outright banned by IP so you can't reach them anyway.

I think DoH + HTTPS works well in concert with a VPN, they're not mutually exclusive. VPN has a host of benefits, including relative anonymity, that go beyond encrypted egress to the public web.

I use it to watch my streaming service subscriptions while I'm traveling abroad.

> I find DoH + HTTPS to be enough. / Why do so many of you use VPNs?

They solve different problems, and can be used together.

HTTPS encrypts the contents of packets between your browser and the server. Therefore it reveals to your ISP what service you are using and when, which also indicates where you are at that time (e.g., in front of your computer at home). And it reveals to the Internet service (e.g., Facebook, etc.) identifying information about your computer. That metadata - knowing what people are doing and when, and identifying information - is generally considered to be as valuable as the contents of their transactions.

VPNs encrypt everything between your computer and the VPN provider. That hides from your ISP and other intermediaries everything you do, other than indications of activity (though traffic could be your computer downloading an update, or example, without you being home). It hides some identifying information from the Internet service, such as your IP address, though your computer may communicate much more that identifies it. However, a VPN reveals to the VPN provider everything that would have been revealed to the ISP; you are merely shifting your trust from one vendor to the other (which is why HTTPS and VPNs are used together).

In a sense, a VPN provider becomes your ISP, including determining the apparent location of your computer - you can look like you are in a different country, which might change what DRM-controlled media you can access. (VPNs also are used for secure tunnels, for example by remote workers and by security-concious network administrators.)

I have shitty ISP that's slow when accessing many sites. It has great connection to mullvad servers though, so I can work around my ISP issues with VPN.

My country is also blocks many sites and requires ISP to transparently route all DNS traffic to DNS servers that implement the government's block list. DNS over https is also really slow with frequent timeouts. I suspect they mess with popular DoH servers to discourage people to use it. Again, VPN solves this.

Tested this a bit when it was announced, works well albeit with an expected hit on latency and throughput.

Absolutely love Mullvad.

Been using Mullvad for years, this is pretty nice. I actually get great throughput with multi-hop on.

Not available on their mobile app?

+2 Mullvad

10 years ago i was working at in a shared office where companies could hire a room. We all had a common lunch place and shared microwaves.

There I met two security nerds. They never shutdown their computers and if it happened, they did a full format and reinstalled the os - because if security.

They spoke with passion about security fixes they made in the vpn client that no other had.

They got many requests regularly from others that they should add there server as an endpoint - and they sad always no. All endpoints must be 100% secure by their knowledge. Never trust anyone.

If they had to leave a laptop they used some old coffee paper trick so that one could not open the lid without visible marks.

I was super impressed by them and have never met any like them. I guess they have grown out of their tiny office now, Mullvad.

What is the coffee paper trick?

It must be attached such it tears when opened, tamper-evident- similar techniques are common fro doors, either across the frame or more stealthily near the hinge. You want it to be a little stealth because an informed adversary could break the seal, remove it, and be prepared to replace/recreate it when they're done (like faking a new wax seal)

Maybe overspray some spraypaint on the paper first and take a picture of the droplet pattern, so it can't be replaced easily.

spot on, but they used coffee to make a unique pattern.

I would think you'd do the exact opposite.

If you leave a computer running anyone (Well "anyone" being a skilled adversary) can simply pull out the RAM and grab encryption keys in clear text. Law enforcement does this so often, it's practically routine. The only "safe" system is one that has been long powered off and is using tried and true cryptography, ideally open-source FDE that's been fully audited.

Mullvad is fully open source, with the source code provided here [1], which has also undergone multiple rounds of audits with the reports available to the public [2][3].

[1] https://github.com/mullvad

[2] https://mullvad.net/en/blog/2021/1/20/no-pii-or-privacy-leak...

[3] https://cure53.de/pentest-report_mullvad_2021_v1.pdf

It's a shame the API isn't open though. I maintain a Terraform provider for it, but it has to come with a fat warning that it can break due to (reversed) API changes, and that fixing it may require breaking changes or even not be feasible etc.

FDE is not enough against physical access, see the evil maid attack.

Well obviously, FDE also doesn't protect you if someone is standing over your shoulder reading you type the password. The point is that leaving a machine turned on, while not in your physical possession puts all of your data at risk. My company would freak if I did this and I don't even work in the security space.

As you know, the evil maid attack is something different. It's better to be precise and not give a false-sense of security to readers who may be less informed about this subject.

Full disk encryption won't prevent "evil maid" attacks where keylogging hardware is interposed between the keyboard and the main board, or the entire board is swapped with one with firmware enabling remote "management".

What if I have some sort of trigger (accelerometer attached to a door connected to a serial port, for example) that makes the system kexec to memtest86 before the system is taken?

> simply pull out the RAM

One does not simply pull out the RAM

It’s practically routine for law enforcement to extract encryption keys from RAM, since when?

I’ve only heard of it being done by researchers and/or special situations.

Is this just speculation?

> can simply pull out the RAM and grab encryption keys in clear text

Leaving aside the leg work "simply" does here, especially in a coffee shop environment: would AMD's "encrypted memory" help against these kinds of attacks?

I have a laptop with an AMD Zen 3 Pro CPU that has this option in the BIOS and was wondering whether it actually did any good, as opposed to being just some marketing shtick.

Interesting, I didn't know this was a thing, but after some cursory research it does seem like part of its use case is to stop this attack vector.

> pull out the RAM and grab encryption keys in clear text

How to defend against this?

Shut down your device, don't leave it on at all times. I don't know if there's a way to suspend and encrypt RAM though. But other than that, there's no way to keep a computer running without the miscellaneous data being kept in RAM

Besides memory encryption (AMD PRO & Epyc) you can zero-out in-use memory keys before suspend & restore on resume, preferably using sealed storage, like TPM. This is ‘the’ reason to prefer home encryption vs. full disk. The thing is if someone is prepared to attack your laptop with liquid nitrogen they might as well just wait for you to unlock your laptop and then steal it right there, or watch you type in your password; better get your privacy blanket ready ;) Not having physical security is a huge disadvantage, and there’s really no way around it—you automatically start in the defeated position, and have to stack gizmos just to break even.

there are methods to store keys in RAM in encrypted form and decrypt them only on the cache and CPU registers

Talked about a bit here: https://youtu.be/pKeiKYA03eE?t=963

Using debug registers to hold an AES key purely in the CPU is genius.

> pull out the RAM

...which could be soldered. Plus, there are methods to store keys in RAM in encrypted form and decrypt them only on the cache and CPU registers.

  > "They never shutdown their computers and if it happened, they did a full format and reinstalled the os - because if security."

I don't get it

I don't recall why, it was so long time ago. But my best guess is that they wanted to guarantee that they know what has been booted?

The sibling comment already mentioned evil maid attacks (not as much of an issue nowadays thanks to SecureBoot and TPMs), but there's also DMA attacks through physical ports: https://en.wikipedia.org/wiki/DMA_attack

Offline attack aka Evil Maid

Reply on news.ycombinator.com