[HN Gopher] WireGuard multihop available in the Mullvad app
___________________________________________________________________
WireGuard multihop available in the Mullvad app
Author : qalter
Score : 280 points
Date : 2022-04-12 16:54 UTC (6 hours ago)
(HTM) web link (mullvad.net)
(TXT) w3m dump (mullvad.net)
| doubleorseven wrote:
| "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.
| [deleted]
| justsomehnguy wrote:
| 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]): V V
| V V 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/
| topdancing wrote:
| 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).
| justsomehnguy wrote:
| Well, I stand corrected, because I relied on their promo
| description. *shrug_emoji*
|
| I replaced the diagram in the previous comment, take a
| look.
| kingkawn wrote:
| Not available on their mobile app?
| BrightOne wrote:
| Seems similar to ProtonVPN's Secure Core, but using Wireguard
| directly. Nice.
| mirceal wrote:
| I see you like wireguard, so i put a wireguard connection in
| your wireguard connection. jokes aside, huge fan of wireguard
| and mullvad
| Trias11 wrote:
| +2 Mullvad
| cpressland wrote:
| 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?
| trashburger wrote:
| 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.
| cpressland wrote:
| 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.
| godelski wrote:
| 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.
| judge2020 wrote:
| > 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=10
| 9140... (comment 20 onwards)
| justsomehnguy wrote:
| 3) Even without SNI sniffing and DoH some sites could be
| outright banned by IP so you can't reach them anyway.
| spmurrayzzz wrote:
| 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.
| otterley wrote:
| I use it to watch my streaming service subscriptions while I'm
| traveling abroad.
| dosshell wrote:
| 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.
| [deleted]
| [deleted]
| [deleted]
| gavinray wrote:
| > "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
| [deleted]
| dosshell wrote:
| 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?
| justsomehnguy wrote:
| Offline attack aka Evil Maid
| Rastonbury wrote:
| What is the coffee paper trick?
| LanternLight83 wrote:
| 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)
| cma wrote:
| Maybe overspray some spraypaint on the paper first and take
| a picture of the droplet pattern, so it can't be replaced
| easily.
| dosshell wrote:
| spot on, but they used coffee to make a unique pattern.
| oceanplexian wrote:
| 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.
| WhitneyLand wrote:
| 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?
| goodpoint wrote:
| > 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.
| vladvasiliu wrote:
| > 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.
| matheusmoreira wrote:
| > pull out the RAM and grab encryption keys in clear text
|
| How to defend against this?
| goodpoint wrote:
| there are methods to store keys in RAM in encrypted form
| and decrypt them only on the cache and CPU registers
| sodality2 wrote:
| 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
| deno wrote:
| 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.
| codewiz wrote:
| 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".
| hatware wrote:
| > simply pull out the RAM
|
| One does not simply pull out the RAM
| gzer0 wrote:
| 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
| tenebrisalietum wrote:
| 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?
| Kototama wrote:
| FDE is not enough against physical access, see the evil maid
| attack.
| oceanplexian wrote:
| 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.
| Kototama wrote:
| 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.
| mft_ wrote:
| 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!)
| sph wrote:
| 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 EUR5 a month? Such a great company.
| clsec wrote:
| 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+.
| mft_ wrote:
| 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.
| toomuchtodo wrote:
| +1 for Mulvad, it Just Works and they are a great service
| provider.
|
| (also no affiliation, just a happy customer)
| throwanem wrote:
| 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.
| mft_ wrote:
| 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.
| netfortius wrote:
| 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).
| mft_ wrote:
| I use it on Mac, Windows, and iOS - they just work well.
| mirceal wrote:
| used it on macos, ios, linux. the app is solid. wireguard
| rules.
| seanw444 wrote:
| I use the app frequently on Android and Arch Linux, and it
| works equally well on both.
| ignoramous wrote:
| 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/
| sva_ wrote:
| I think what people want in this case, is quick access to a
| different exit IP to appear on the internet with.
| INTPenis wrote:
| 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.
| teawrecks wrote:
| 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.
| judge2020 wrote:
| 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.
| daqhris wrote:
| 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.
| tomxor wrote:
| I use wireguard directly so I'm more aware of exactly which
| server I'm connected to. 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.
|
| You wouldn't believe the amount of grief I received from some
| online multiplayer games due to IP geolocation being miss-
| labelled as Russia... Opened my eyes to ridiculous people are
| in blaming Russian citizens for what is happening - they aren't
| enlightened, it's not "banality of evil" level of accusation,
| it's much closer to xenophobia, then again the internet and
| multiplayer games are full of the worst humans so maybe it's
| just the "worst humans" affect.
|
| Anyway, yes, random sites may block you on xTom because of
| this, but to be honest this will occasionally happen on any VPN
| server regardless of bad IP geolocation due to abuse of a
| shared IP causing per-service blacklisting (which will not be
| apparent from the "blacklisted" status on the mullvad page).
| When this happens you simply need to switch server.
| Thorentis wrote:
| 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.
| saurik wrote:
| 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").
| throwanem wrote:
| 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.
| DenseComet wrote:
| 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.
| postingposts wrote:
| 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?
| dempedempe wrote:
| 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.
| uneekname wrote:
| 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
| [deleted]
| lighttower wrote:
| Split tunneling an app to NOT GO THROUGH the tunnel is easy
|
| Setting split tunneling to ONLY TUNNEL A SPECIFIC APP is hard
| [deleted]
| twojacobtwo wrote:
| 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)
| CPAhem wrote:
| The Mullvad app is huge ~100MB which is odd for what it needs
| to do.
| throwanem wrote:
| 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.
| twojacobtwo wrote:
| 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).
| silizium wrote:
| 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.
| throwanem wrote:
| 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.
| Foxboron wrote:
| It does use electron. The source code is available on
| github.
|
| https://github.com/mullvad/mullvadvpn-app
| _rend wrote:
| 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.
| seanw444 wrote:
| 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.
| windexh8er wrote:
| 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.
| anakaine wrote:
| I'll also +1 your anecdote that the Mullvad app is simple,
| convenient and stable.
| UberFly wrote:
| 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.
| [deleted]
| _joel wrote:
| Tested this a bit when it was announced, works well albeit with
| an expected hit on latency and throughput.
|
| Absolutely love Mullvad.
| Exuma wrote:
| Are we required to force it to use Wireguard instead of
| "Automatic" for this to work?
| gzer0 wrote:
| 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
| pydry wrote:
| 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.
| AlexandrB wrote:
| You can also mail them an envelope with your user ID # and
| some cash. It's pretty great.
| daqhris wrote:
| 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.
| [deleted]
| vinay_ys wrote:
| How does it matter that your payment is anonymous when all your
| traffic is going through them?
| capableweb wrote:
| 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.
| vinay_ys wrote:
| 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.
| capableweb wrote:
| 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.
| vinay_ys wrote:
| 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.
| capableweb wrote:
| 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.
| mhitza wrote:
| 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.
| johnwayne666 wrote:
| 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?
| E4YomzYIN5YEBKe wrote:
| 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.
| mikece wrote:
| "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.
| matthews2 wrote:
| > 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?
| clsec wrote:
| Here's the latest Mullvad security audit (June 2020).
|
| https://cure53.de/pentest-report_mullvad_2020_v2.pdf
| odensc wrote:
| 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.
| encryptluks2 wrote:
| Then the user would just go find a second VPN provider.
| wiseguy317 wrote:
| Been using Mullvad for years, this is pretty nice. I actually get
| great throughput with multi-hop on.
___________________________________________________________________
(page generated 2022-04-12 23:00 UTC)