Mullvad has partnered with Obscura VPN

Privacy
102

Depends on the identifier.

If by identifier, we mean “account identity” (authentication), then VPNs like Mullvad & Windscribe tell us that they keep them separate from their data plane.

If by identifier, we mean enrolled keys (authorization), this is the part where the user is in full control. They generate the configs and rotate them as and when they want to. Besides, in our example, Mullvad has no knowledge of the keys used for Windscribe & vice versa. This is strictly better.

Privacy Pass is a cryptographically guaranteed way to keep authentication and authorization separate. It changes nothing (in terms of privacy), if we already trust Mullvad & Windscribe to do so.

True. In a single party setup, it doesn’t make much sense to implement the full RFC (just the blind tokens part may be enough). In a multi-party setup, Privacy Pass provides an avenue for one VPN party to let the client (end user) anonymously enroll with the second VPN party. It doesn’t really change anything wrt WireGuard and its key generation & key exchange mechanisms (that is, the “identifier” must be ideally rotated even in this setup; or, the providers use MASQUE instead).

1 Like
103

I’m also curious about quantum-resistant encryption. It seems like that should be possible to add to Obscura’s VPN client (if it isn’t already) since Mullvad already supports it on plain WireGuard tunnels.

+1

104

To remind, the original assertion was, “Because how are you going to acquire multiple VPNs safely”, and my answer was it isn’t as tricky at all:

All PG recommended VPNs meet a set of criteria, including “no logs” on the data plane. As in, all the end-user has to do is to use privacy-respecting VPNs in their chains. That pretty much is it.

Besides, both those providers couldn’t do much even if they colluded, if the end-user was careful enough (this part is tricky, sure; but collusion is also a high threat model that even Private Relay doesn’t meet).

Some more reasons to chain VPNs:

  1. Traffic correlation is that much more difficult.
  2. Multiple jurisdictions: The first hop knows client IP but not the destination. The second hop knows the destination but not client IP. Helpful in places where the first hop VPNs are forced to log data.
  3. 3 > 2: A chain can be 3 or 4 hops. Though, 3 is better than 2, the value of 4 or more hops is dubious, imo.

Not necessarily. It heavily depends on how the end-user is enrolled with all the parties. The many Privacy Pass deployments solve this (I count 4 different ways to deploy them, 2 of which require existence of an anonymizing transport already to maintain unlinkability between the parties). The end-user is not in control how the enrollment plays out. And as with any deployment, there’s many a slip between the cup and the lip (as in, it is equally tricky for all involved parties to get this right).

Besides, whoever controls the client, can own the end-user, at will.

Same goes for multi-party setups, except replace “exit” with “entry”?

Per my understanding, this isn’t do-able with 2 hops (need 3). So, not the entire point of 2 party systems, at least?

1 Like
105

What makes you say that?

At that point you need to start taking speed and reliability into account, it’s important to strike a balance. The QUIC protocol let’s MPRs stay speedy and reliable, even with two hops it can feel like you’re not proxying your connection at all. You could imagine an MPR with even more than two hops and it would probably be much more usable than chaining 3 VPNs together. Plus with MASQUE you can have different routes per connection.

1 Like
106

No, in this case Obscura does not have a way to surreptitiously monitor your exit traffic.

It is disingenuous to equate the level of trust needed in downloaded software with the level of trust required in an internet service provider running black box software remotely. To say a service like Obscura is in an identical position to Mullvad in your example is akin to saying that Tor is trivially compromised because they could simply ship a malicious Tor Browser.

Undetectable server-side modifications are a completely different ballpark from shipping malware for users to run locally.

1 Like
107

… if the end-user was careful enough.

That is, in my example, if the end-user paid Mullvad & Windscribe with Monero or cash; setup Mullvad (exit; knows where you are connecting to) over Windscribe (entry; knows your IP), then all they’d know is your IP (which may be behind a CGNAT, in which case, it is shared by 1000s) and your destination (which may be Tor or VPS etc).

That’s not what you said. You said, “if Mullvad (exit) works against you”. My point was, if the first party (entry) works against you, you’re done for, just the same. Isn’t entry node the one taking payments and enrolling the client with the exit node? You’re thinking of compromises after enrollment. In my mind, the security guarantees actually come from the enrollment process.

I mean, you need to absolutely trust what you’re running and distrust what your providers are.

Correct? This is the entire reason why the Tor Browser has to be open source and perhaps be routinely audited.

Let’s assume technology X, Y, & Z make malicious mods on the client-side detectable, what should we demand from the providers so that their server-side mods be detectable? That they employ X, Y, & Z, too.

It is disingenuous to claim exit node can unilaterally own an end-user but draw an imaginary line where the party (entry) that controls the very software running on an end-user device unilaterally can’t.

108

“iCloud Private Relay” Are you serious? Apple is the last company to put your faith in their privacy policy, and neither is Google any better either.
As for INVISV; PGPP and Relay Shutdown.

109

Well that’s just wrong and incorrect. Apple is getting worse each quarter but certainly is not the last company.

Saying that without explaining yourself only hints at your ignorance as we have no rationale to evaluate your comment against.

110

smh
just use tor if you’re really concerned
otherwise this is still a valuable improvement

112

Tor ! First part is to find which entry, or exit nodes are FBI nodes, to blacklist, it not like they are advertising.

113

I don’t know how to explain more clearly that a service being able to track you in an undetectable manner is not the same as a service being able to track you in a detectable manner :man_shrugging:

114

Multi party relays where the second relay only knows that ANY possible user has connected to one of their servers which is how icloud private relay works is much better than a service where the second relay does exactly which user from which entry server has connected. Also if obscura decides to turn on its users we certainly can’t trust its own app software. Also in either case you are already putting so much trust in each party that I think you are better off just using mullvad as your first hop and using trusted vpm providers paid in monero as your next hops or even free proton as your next hops if you are unable to obtain monero or rather just have a kyc free VPN connection.

115

The thing is, to suit the model you have in mind, which is roughly, “entry knows who you are, exit knows what you do”, requires you to be dishonest about just who controls the client app and what they could do.

If this didn’t matter, the Privacy Pass RFCs would have 2 parties (issuer+origin) instead of 3 that they do (issuer+attester+origin). Tor would be 2 hops instead of 3. And Carl himself is more honest about it than you are.

True. This is why all client side source code will be released and reproducible builds offered on platforms that support it.

If you don’t know what code you’re running, yeah you’re screwed either way.

Source

Also, is the assumption that the end-user can “detect” tampered clients … ? It is patently observable from known universes that end-users get owned all the time by 3rd parties doing undetectable stuff to installed apps (like Chrome, WhatsApp).

Even if we assume the end-user is more in control of the client they install, a custom first-party client entirely defeats the rationale of “the first hop only knows who you are”, unless you absolutely trust the first party to do the right thing. Which, if you do so, you might as well trust the privacy-respecting VPN providers to individually do the right thing and chain them + use a client you trust, that doesn’t have to come from any of the said providers in your chain.

btw, there’s no such thing as “undetectable” changes to server side. The providers, if they so choose, could deploy remotely attestable code. Signal does this? In fact, in my conversation with the Mullvad co-founder, they seemed to agree to that much.

I am concerned about National Security Letters and similar concepts. Technologies like reproducible builds, transparency logs, and remote attestation can help there

kfreds, Mullvad co-founder, in response to Clarification on the Swedish Covert Surveillance Act

Seems like, the implementers of these apps and services themselves are more honest about the shortcomings than folks who have preset notion of what sells for usable security (aka could be setup “easily”). Would be funny if folks would scream “argument from authority” and dismiss the makers themselves. They don’t “understand”…

1 Like
116

Oh cool! I didn’t know about them, will add to our list for outreach.

Yes, we do have plans to add this. I don’t think the API Mullvad has given us access to right now has this functionality, but we’ll work with them to enable!

Transparency is a core tenet of our philosophy here at Obscura, and we hope to do better and better now that we’re launched! It’s part of the reason why I’m here on Privacy Guides :laughing:

@vimug Are there any interviewers that you’d like to see interview me? Which ones do you find the most trustworthy?

We started with Bitcoin over Lightning since I’m a former Bitcoin Core developer and know the protocols and operational logistics there well. We’ll look into Monero more! Funnily enough we had fluffypony (former lead maintainer of Monero) retweet our launch announcement.

Really appreciate that sentiment Walter :blush:. Developing a polished app for folks to use is not an easy task, and our resources are limited. Hopefully now with real paying users we can ramp up our efforts and earn y’alls trust!

This is actually a problem that I’ve thought about for a long time (since 2019). This is why we have our client source code on GitHub, and have plans to make reproducible builds of our Apps. In fact, I previously led the effort to revamp Bitcoin Core’s reproducible builds system to be bootstrappable, work that is referenced by the Tor project.

6 Likes
117

As for youtube interviews.

Watchman Privacy
Opt out podcast by Seth for privacy
Monero talk

Also would be nice if you guys addressed your US jurisdiction and whether or not you have plans to move or not. If you do intend on staying I don’t know how anyone can trust your service when the US can send your company a NSL at any time and force you to cooperate. If your response is just going to be, that users don’t need to trust you because this is a trust less design, I would argue that users are better off just using mullvad solely if you guys are just going to be inevitably forced to start logging

118

Hasn’t this been discussed elsewhere on the forum that jurisdiction isn’t the end-all-be-all for a VPN provider?

119

Jurisdiction is not the end all be all. Except when it comes to countries like the US where you can literally be forced by the government to start logging via national security letters and gag orders where you aren’t even allowed to contact a lawyer

120

Reproducible builds would be a major step against that in my view. It’s not an unsolvable problem.

121

Software isn’t going to protect against hardware compromises. If the law enforcement demands hardware-level interference, it is pretty much game over.

Glad you’re taking serious and holistic view of this. I want to point out that my comment was in the context of claims that

  1. It is tricky for the end-user to enroll with multiple VPNs safely.
  2. And that, multi-party VPNs are inherently better because collusion among those parties is a prerequisite to own the end-user.
  3. And that, server side compromises are “undetectable” but client side compromises are detectable.