dongcarl

(Carl from Obscura here, posting over Obscura VPN on airplane WiFi)

You may want to check us out: https://obscura.com

We do a Two-Party VPN with Mullvad as the exit hop. You just need to sign up with us and we don't require emails.

(Carl from Obscura here)

Thanks for the shout-out Cider! :)

> https://obscura.com/check/ does this page know the difference between a direct mullvad user and an obscura user, if so, how?

We don't actually, try visiting it with Mullvad turned on!

> Packet padding but no docs about this?

Yeah it's an experimental feature, we're not 100% happy about how we implemented it so we've left it experimental and are working on a v2.

(Carl from Obscura here)

Yeah it'd be a cool addition to combat internet surveillance but in practicality it may have a lot of problems:

1. Deteriorated performance if it's across unequal links (3G vs. Fibre WiFi)

2. Many countries have single exits to the global internet so they'd be able to assemble everything there

3. The most important plaintext data is probably in the TLS SNI which usually sits in a single packet for TLS in HTTP/3

(Carl from Obscura here)

Basically:

Your device <-> Obscura Relay <-> Mullvad Exit <-> Internet

So the exit server knows the IP of the Obscura Relay, but never sees your device's IP, lmk if that's clear!

(Carl from Obscura here)

Yup! Mostly less changes on Mullvad's side. Also QUIC has less overhead than MASQUE by definition.

Good question! It's the latter right now (which is not ideal), but I think Mullvad is going to sign their server pubkeys pretty soon and we'll switch to that.

We do currently show it in the app and there's an easily clickable link so you can verify against Mullvad's website for the pubkey

I believe if your device connects directly to Mullvad they will have your real IP (to know where to send reply packets)

(Carl from Obscura here)

I love folks who are also reasoning through security models! A few things to note here:

- We believe that all software running on a user's computer should be open source, so you can audit and build your own client: https://github.com/Sovereign-Engineering/obscuravpn-client

- With traditional Single-Party VPNs, even if you trust them fully and they're honest, they can still be compromised or hacked. With Obscura, even if we're hacked there's nothing to leak (other than WireGuard packets fully encrypted to Mullvad's servers).

- The change in trust is that instead of trusting a single company (Mullvad), you're trusting that not both Obscura AND Mullvad have been compromised, which is strictly less likely.

(Carl from Obscura here)

I totally agree for traditional Single-Party VPNs, which is why we are a Two-Party Relay. More here: https://obscura.com/blog/bootstrapping-trust/

(Carl from Obscura here)

Very true, but if even 1 of (Obscura, Mullvad) is honest, there's no de-anonymization.

For traditional Single-Party VPNs, you just need to compromise 1 party, with Two-Party Relays, you need to compromise both.

We're heavily inspired by them (see our original blog post which is a bit more technical here: https://obscura.com/blog/bootstrapping-trust/)

The differences are:

- We allow you to choose an exit location (I believe iCloud Private Relay restricts you to the same location)

- Our exit hop is Mullvad instead of Cloudflare+Fastly+Akamai

- We use QUIC for transport instead of HTTP/3 (which is built on QUIC and has a bit more overhead)

(Carl from Obscura here)

I could be wrong but in Tailscale if you use Mullvad as an exit node, the traffic flows directly from your device to Mullvad's servers.

Whereas with Obscura, your traffic flows to the Obscura relay, then the Mullvad exit.

(Carl from Obscura here)

Other than the obvious hassle? XP

If you connect to Mullvad over NordVPN:

- You're giving both Mullvad and Nord some payment information (with Obscura you only give that to us, Mullvad has no idea)

- You don't get our QUIC-based obfuscation (see more here: https://obscura.com/blog/bootstrapping-trust/)

(Carl from Obscura here)

This doesn't prove it. However, Obscura makes it so that there's no *single party* that if hacked or otherwise compromised would hurt your internet privacy.

Can't speak to Iran, but we use QUIC for transport (with an experimental TCP/TLS mode).

I believe QUIC has been harder to block for censors, esp with Chaos Protection on by default in Chrome. See: https://gfw.report/publications/usenixsecurity25/en/

(Carl from Obscura here)

Actually it's WireGuard over QUIC Unreliable Datagrams!

See: https://obscura.com/blog/bootstrapping-trust/

(Carl from Obscura here)

I'm a sucker for retro 8-bit graphics and fun mascots, so we went with that, but when we experimented with 8-bit for actual UI and long text we immediately found it to be super unusable and unreadable :-(

> Bonus point for the TRON reference at the end! “I fight for the users!”

Ah ofc the HN poster knows the reference :-) I've had it as my email signature since high school I think.

(Carl from Obscura here)

Yeah we thought the randomized account number flow was an ingenious idea, so we did that and made the last digit a Verhoeff checksum to check for mistypes!

Though sometimes people forget to write the number down and... There's not much we can do.

Carl from Obscura here

Happy to answer any questions y’all might have!

Also, the technical folks may be more interested in our original post: https://obscura.com/blog/bootstrapping-trust/

We think Mullvad is a great privacy tool, which is why we partnered with them!

As for what's different: We're a Multi-*Party* Relays (vs. traditional VPNs which are Single-Party Relays): https://www.privacyguides.org/articles/2024/11/17/where-are-...

With Multi-Party Relays you no longer have a trust a single entity not being malicious or compromised. More on this here: https://obscura.com/#how

Also, all our apps are open-source as well: https://github.com/Sovereign-Engineering/obscuravpn-client

Disclaimer: I'm the creator of Obscura.

Good to see you here Barath :-)

I didn't realize Chris Wood was also an author!

(Carl from Obscura here)

Yup, exactly!

Re: protocols with trust-minimization in mind, you may be interested in Multi-Party Relays (vs. traditional VPNs which are Single-Party Relays): https://www.privacyguides.org/articles/2024/11/17/where-are-...

With Multi-Party Relays you no longer have a trust a single entity not being malicious or compromised.

Disclaimer: I run obscura.com, which does exactly this with Mullvad (our partner) as the Exit Hop.

Appreciate the shoutout! :-)

Thanks for the shoutout!

Heh yeah we just check for a Mullvad exit IP, it's one way you know we're actually relaying to Mullvad!

Carl here (Obscura CEO, one of Mullvad's partners)

This was an interesting finding, though as kfreds mentioned it would have been better to notify the vendor before publishing.

The main finding (IP-position-in-pool correlation between servers) seems to include genuinely unintended behaviour. Given our great experience with the Mullvad team, I'm sure this will be addressed soon.

In general, if you want different "identities", you should make sure to rotate or use different WireGuard keys.

One small thing from the article I'll comment on:

> Surprisingly, the exit IP you are given is not randomized each time you connect to the server, but deterministically picked based on your WireGuard key, which rotates every 1 to 30 days (unless you use a third-party client, in which case it never rotates).

Context: WireGuard is by design[1] a "Connection-less Protocol", there's no concept of a connection, there's only a "re-keying handshake" (key here refers to the ephemeral Diffie-Hellman key, not the WireGuard key) every 2-3 minutes ONLY IF there's traffic flowing.

The above statement is not too surprising if you consider the counterfactual: What would happen if, even with the same WireGuard key, the exit IP were randomized each time you "connect" to the server (say each time there is a "re-keying handshake" or at more frequent cadence (e.g. every 15 minutes) than the WireGuard key rotation).

In this scenario, ~every 15 minutes:

- At the Transport layer, all your in-tunnel connections that are on non-roaming protocols (basically everything except QUIC) would be disrupted, and the connections would have to be re-established.

- At the Application layer, many application-level sessions that treat "same cookie, new IP" as suspicious would trigger logouts, CAPTCHAs, or risk scoring.

Both are terrible UX, and what's worse would also make users much more uniquely fingerprintable ("this person keeps reconnecting from a different IP, they must be using Mullvad").

[1]: https://www.wireguard.com/protocol/