dongcarl

dongcarl

12 hari yang laludiscuss

Appreciate the shoutout! :-)

dongcarl

12 hari yang laludiscuss

Thanks for the shoutout!

dongcarl

2 bulan yang laludiscuss

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

dongcarl

2 bulan yang laludiscuss

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/

dongcarl

9 bulan yang laludiscuss

> should Chat Control not pass

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!

dongcarl

9 bulan yang laludiscuss

We've had many reports that it works. In fact, one of our users told us he took an hour video call over Obscura in China and things worked smoothly!

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.

dongcarl

9 bulan yang laludiscuss

You could probably implement a pluggable transport for it?

dongcarl

9 bulan yang laludiscuss

Ah that's excellent! Do you have a link to the thesis?

dongcarl

9 bulan yang laludiscuss

Yes, you can with Obscura. That limitation of Private Relay is just an arbitrary limitation made by Apple.

dongcarl

9 bulan yang laludiscuss

We should really be moving towards a world of Multi-Party Relays rather than Single-Party VPN operators: 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.net, which does exactly this with Mullvad (our partner) as the Exit Hop.

dongcarl

10 bulan yang laludiscuss

Actually, they don’t need to do a reverse lookup at all.

They can just look at the TLS SNI field and the hostname is there in plaintext.

It’s _more_ trouble to do the reverse lookup.

dongcarl

10 bulan yang laludiscuss

If you can't see your VPN's source code, you can almost safely assume that they're broken in some way.

dongcarl

10 bulan yang laludiscuss

It's trusting A OR B, rather than A AND B

dongcarl

10 bulan yang laludiscuss

Yup, when you're not using a VPN, even with encrypted DNS and HTTPS, you're still sending hostnames (e.g. wikileaks.org) over plaintext in TLS SNI for every HTTPS connection. I believe most firewall appliances now even prefer to use SNI for deep-packet-inspection since it's so reliable.

dongcarl

10 bulan yang laludiscuss

I'm surprised no one has mentioned iCloud Relay-style Multi-Party Relays yet: https://www.privacyguides.org/articles/2024/11/17/where-are-...

It greatly improves on the existing VPN trust model by separating the "who" (connecting IP, potential payment info, etc.), from the "what" (IP traffic). You no longer have a trust a single entity not being malicious or compromised.

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

dongcarl

11 bulan yang laludiscuss

We're working on it! Android is next :-)

dongcarl

11 bulan yang laludiscuss

We should link it in more places, apologies!

Here it is: https://github.com/Sovereign-Engineering/obscuravpn-client

dongcarl

11 bulan yang laludiscuss

Very possible, though many of our users are saying that in network environments where WireGuard is blocked they were able to use Obscura.

dongcarl

11 bulan yang laludiscuss

Give Obscura a try, we get around internet restrictions by using QUIC as transport, which looks like HTTP/3 and doesn't suffer from TCP-over-TCP meltdown: https://obscura.net/

Technical details: https://obscura.net/blog/bootstrapping-trust/

Let us know what you think!

Disclaimer: I'm the creator of Obscura.

dongcarl

11 bulan yang laludiscuss

I actually spent a few months prototyping SGX/SEV VPNs before settling on a Multi-Party Relay scheme for obscura.net

Things may have changed since mid-2023 but here were my takeaways:

-----

Re: Vendor lock-in

Vendor lock-in is (was?) a huge problem (at least for process-based TEEs)

Process-based TEEs (mainly SGX) operated by providing essentially a whole new system abstraction. At the base level, there was no `libc`-like or `POSIX`-like interfaces, only Intel specific ones. This is why there are projects like [Gramine](https://github.com/gramineproject/gramine) and [Fortanix](https://github.com/fortanix/rust-sgx) that aimed to provide a more `libc`/`POSIX`-like interface to developers, even though this was the leakiest of abstractions (you can’t even create a UDP socket).

This is not only a problem in terms of Developer Experience though, this is also a huge problem for vendor lock-in. Porting things were nigh impossible, and you’re stuck with the Intel platform. I think Intel is making a genuine attempt at making a good TEE right now, but what if Intel decides to axe their budget for TEEs or drop support altogether?

*Possible solution*: Use VM-based TEE abstractions like SEV or TDX, which can run a full VM, which is at least a more portable solution and has a full Linux environment (with some caveats).

-----

Re: Trust model

A convincing trust model for TEE VPNs was possible, but a big engineering challenge.

1. TEEs without remote attestation and reproducible builds of the backend are near-meaningless: If a VPN operator hands you a proof co-signed by Intel that they’re running in SGX… so what? They could simply be running a data-harvesting pipeline in SGX.

   *Possible solution**: A **remote attestation** of *what they’re running*, which requires that they have a reproducible build of *what they’re running*, and for the remote attestation to verifiably attest to that reproducible build

2. For VPNs: it is always possible to hand the user a *remote attestation* to one server, then just swap out that server for another when the user is connecting.

   *Possible solution**: A way to link the **remote attestation** to what you’re connecting to.

-----

Re: Vulnerabilities

Back in mid-2023, it seemed like vulnerabilities in different TEEs were still popping up. However, I don’t want to overstate them here or engage in FUD: over time, it seems like the newly revealed vulnerabilities were becoming more and more theoretical attacks hard to carry out in the real world.

I think this is something that improves over time as the different TEE platforms matures, but *relying solely on TEEs* to make claims about privacy and security seemed a bit shaky to me.

This was the final straw for me for why not to start with TEEs back in 2023: Given that we wanted to avoid vendor lock-in as much as possible, we only had AMD SEV as a choice at the time. I came across this vulnerability ([GitHub](https://github.com/PSPReverse/amd-sp-glitch), [arXiv](https://arxiv.org/abs/2108.04575)) and (from my reading) it was very practical and almost unforgive-able, see [this image](https://forum-uploads.privacyguidesusercontent.com/original/...). Funnily enough, you can even see my post in 2023 to understand if the AMD VLEK addition mitigated the vulnerability ([GitHub comment](https://github.com/PSPReverse/amd-sp-glitch/issues/3)).

*Possible solution*: MPR but each hop is a different TEE implementation. That way an attacker would have to have an exploit for all the TEE implementations to break the security model.

-----

Anyway, these were my thoughts back in 2023, things like hardware vulnerabilities may have changed since then, and certainly the availability of Intel TDX (another VM-based TEE) makes vendor lock-in much better, but the “Trust Model” challenges still remain. That is a big engineering challenge though, and not a fundamental problem with TEEs, so I’m very cautiously optimistic!

Submissions

Cloudflare, Chrome, Firefox Developing Next-Gen Privacy Pass: PACTs

Cursed Knowledge

comments