Mullvad has partnered with Obscura VPN

[ph00lt0 (Mare Polaris)]

That is a good question. That really depends how it works but i would think they use their own IP and given dns is not encrypted it is fairly likely they could read it. If it is encapsulated packets to mullvad it could be encrypted but i am wonder how that initializes then.

[jonah (Jonah Aragon)]

@Encounter5729

It seems to be from https://sovereignengineering.io/, which is kinda like a hackathon but for "Six weeks of high-bandwidth ideation, experimentation, mentorship, dialog, cross-pollination and discussions on how to build kickass applications, services, and businesses for a self-sovereign future. "

What makes you say this? The team is completely different, I don’t see anything to indicate any sort of relationship here.

@ph00lt0

If it is encapsulated packets to mullvad

This is the entire point of the service, yes.

[Encounter5729]

@jonah

What makes you say this? The team is completely different, I don’t see anything to indicate any sort of relationship here.

I just used their public info from this.

1. Github org is Sovereign Engineering
2. Their Copyright header says this.
   
   

[ph00lt0 (Mare Polaris)]

Well get that but would that work for the DNS? I really would like to see some technical standard on how that would work.

[Prismatic]

https://sovereignengineering.io/ links their github as https://github.com/soveng (compare to the obscura VPN repo you linked: https://github.com/Sovereign-Engineering)

[Gavin]

Better question, why not just use SPN from portmaster, who safing is now owned by IVPN, and in turn, Portmaster / SPN.

I don’t really see the point in this service, as its doing something portmaster does pretty well. And SPN has been around for a lot longer.

[ignoramous]

@ph00lt0

would that work for the DNS? I really would like to see some technical standard

From what I can tell from the code,^[1] the DNS config is sent by Obscura’s API endpoint, and is set with macOS’ Networking APIs.

I imagine that depending on macOS’ documented behaviour (default or desired), either the DNS is sent back into the VPN tunnel (in which case the DNS query should be relayed over Obscura to Mullvad) or not (as in, sent out the underlying network, outside of the tunnel; which tbh seems unlikely to have skipped app developer’s attention).

---

1. I used Sonnet to explore the codebase. Search terms: startTunnel, jsonTunnelArgs, NetworkConfig, NEPacketTunnelNetworkSettings, NEDNSSettings, PacketTunnelProvider. startSendLoop. ↩︎

[jonah (Jonah Aragon)]

@ignoramous

The Obscura app registers your “WireGuard keys” (hopefully, rotated often

I also poked them for some details on Discord about this, this morning.

@jonah

How often are WG keys rotated? It seems like your client’s public WG key could be used as a static device identifier by Mullvad, couldn’t it?

@Obscura VPN

We currently rotate on every connect, but are internally testing local key caching (so that API servers aren’t overwhelmed) with key rotation at regular intervals.

@jonah

Do you think this is a concern for some people? It may not be obvious to users that if they go to Site A and Site B on the same connection, that activity could be correlated by your exit provider.

@Obscura VPN

I see what you mean: inter-connection correlation on the exit hop can still happen with Obscura.

Our main privacy goal, at least for this initial launch, is to sever the correlation between identity (IP address, payment info), and traffic/connection.

With this improvement, inter-connection correlation becomes a bit less worrisome, but admittedly is not solved.

One big mitigating factor is that we’ve deliberately chosen Mullvad as our exit hop partner, and we believe them to be very trustworthy

Thinking about it on a protocol level, I think we’ll need something other than WireGuard for this to work.

@jonah

Yes, I certainly agree this is a huge improvement over just Mullvad or another provider. It is not a gotcha question, I was just curious about your opinion on the issue. I know that Apple spent significant effort on the authentication aspect of their Private Relay protocol to alleviate this concern for example, so when we were reading about your (seemingly much simpler) solution with WireGuard it gave me and some of our other community members on the Privacy Guides forum pause.

I do worry a lot about people being over-confident in their privacy & security tools, generally speaking. I wonder if there is an opportunity to educate people about this risk. Key rotation would probably help a lot here I’m guessing, and giving people the option to manually rotate (as well as informing them when that might be necessary ahead of time) would as well. Of course it sounds like they already have that option, but may not know when it’s necessary in certain scenarios.

There’s always the risk of Mullvad correlating traffic by inspecting it and inferring some relationship no matter what you do probably, but that is a whole different issue than right now where it would actually be relatively trivial.

I think correlation between before and after you rotate WireGuard keys really shouldn’t be possible right? Or am I overlooking some other potential identifier in your/WireGuard’s protocol?

It’s like you say, Mullvad is very trustworthy, but when the goal is to minimize trust then I think you have to be clear when trust is still required. It is clearly a very different situation if Mullvad can say “this traffic came from this specific Obscura VPN user, but we don’t know their identity” as opposed to “this traffic came from an Obscura VPN user, and we don’t know their identity.”

Still waiting to see if they have any thoughts on my last messages, but it’s good to confirm this specific limitation.

Edit:

@Obscura VPN

What a wonderfully thoughtful comment!

Yeah this kind of correlation is exactly why we’re going to ship key caching/persistence with regular key rotation, so at the very least the correlation is broken every rotation.

It’s an interesting idea to allow users to maually rotate keys, I hadn’t really thought of that before! I think that user education and crafting UI that’s powerful without being overwhelming to a non-expert audience is inevitably a large part of the work that’s ahead for Obscura and other privacy-conscious companies, but it’s part of the good fight!

It also sounds like I really need to check out the Privacy Guides forums more often!

[basenote]

What are the benefits of rotating WG keys?

[SkewedZeppelin]

Happy to see this. Long overdue.
Hopefully it gains more platform support or others start offering similar.

It still however doesn’t match Apple Private Relay or Tor which both give unique circuits per site.

[Niek-de-Wilde]

What part of jonah’s post above is unclear? I could give you an explanation. I thought he explained it fairly throughly why rotating the keys are important.

[Niek-de-Wilde]

I mean, MPR will always be a poor mans tor (which i get is an ironic name as this is a paid for service)

[fria]

So Mullvad doesn’t know you’re the same person over a long period of time.

[basenote]

Thank you. I only asked to confirm whether I understood it correctly.

[basenote]

I only asked still because I wanted to confirm whether or not my understanding was accurate. So a more direct and clearer clarification in simpler words would help. But @fria clarified it.

If you have anything to add, please do!

[obscuracarl (Carl @ Obscura)]

(Carl from Obscura here)

DNS queries are relayed over Obscura to Mullvad. I believe folks can check DNS+WebRTC using Mullvad’s existing Connection check | Mullvad VPN page. (Mine is all green on Obscura)

[obscuracarl (Carl @ Obscura)]

One more comment on key rotations / inter-connection correlation: Jonah notes (correct me here if I’m mis-summarizing) that Obscura only decorrelates connections temporally (via key rotation) but not in a fine-grain way (per-connection). By choosing to tunnel vanilla WireGuard packets (over QUIC), we were able to easily integrate with Mullvad’s existing WireGuard infrastructure, but lost the ability to potentially do per-connection key rotation if we had made more customizations to the protocol.

However, I do think we gain a little something from that (staying with WireGuard) though because users can verify that the WireGuard pubkeys they’re encrypting their connection against are the same ones that are on Mullvad’s server website Servers. Otherwise, it would have been much more unclear what goes on behind the scenes and who has the keys and whatnot.

In any case, more good work to be done for sure!

[jonah (Jonah Aragon)]

I’m not sure what you mean by “per-connection” in this context since you do rotate keys every time a new VPN connection is established with Mullvad, don’t you?

Unless you mean per connection to each website the user visits, like what @SkewedZeppelin was saying?:

@SkewedZeppelin

It still however doesn’t match Apple Private Relay or Tor which both give unique circuits per site.

---

Regardless, I do think agree it is very useful to be able to verify keys against Mullvad’s server listing.

[obscuracarl (Carl @ Obscura)]

Yeah by “per connection” I meant “per connection to each website the user visits”!

[jonah (Jonah Aragon)]

Yeah, it is a trickier problem. Although, I think it’s not the most important thing to most people, as long as they are aware it can theoretically be done tbh

Some UI like Tor Browser’s New Identity feature would essentially cover this use-case. This is sort of what I was getting at with the manual key rotation I had mentioned on Discord.