241 karma · joined October 5, 2016
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.
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
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!
Yup! Mostly less changes on Mullvad's side. Also QUIC has less overhead than MASQUE by definition.
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 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.
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/
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.
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)
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.
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/)
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.
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/
Actually it's WireGuard over QUIC Unreliable Datagrams!
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.
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.
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/
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.
I didn't realize Chris Wood was also an author!
Yup, exactly!
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.
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").
Unfortunately in the world we live in no single jurisdiction is good enough anymore, laws can always change and Chat Control can be re-proposed over and over again.
Luckily, an MPR like Obscura with hops across different jurisdictions (Obscura in US, and Mullvad in EU) give you a much better scenario than just being in one jurisdiction.
> it would be great if you prioritized accepting Monero as payment
Definitely prioritized, one of our engineers is working on it right now.
> Also, how much control do we have over the features Mullvad offers (e.g. DAITA, quantum resistance, DNS filters, IPv6, integration with Mullvad Browser)?
We're limited by the Partner API that Mullvad offers right now, but we'll be looking into many of these soon. For example, we're implementing DNS filtering as we speak!
Unfortunately, because we don't identify users we cannot offer a free tier (since that would allow anyone to use it freely indefinitely).
However, you can always just top-up for 1 month to see how it works for you! Would love to hear your experience.