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/

Comments URL: https://news.ycombinator.com/item?id=47065598

Points: 5

# Comments: 0

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.

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.

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.

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.

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

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

Let us know what you think!

Disclaimer: I'm the creator of Obscura.

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

   *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!

We just upstreamed our patch to quinn-rs that pads Datagrams to MTU: https://github.com/quinn-rs/quinn/pull/2274