Ah that's excellent! Do you have a link to the thesis?
243 karma · joined October 5, 2016
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
This is why we need more [MPRs](https://www.privacyguides.org/articles/2024/11/17/where-are-...)
1) Here's what [one of our FAQ entries](https://obscura.net/#faq-trust) say:
> Additionally, our app displays your current exit hop’s WireGuard public key on its “Location” page. You can check this key against what Mullvad publishes [here](https://mullvad.net/servers) to ensure that you’re connected via a genuine Mullvad exit hop!
2) I really hope that the VPN industry comes together and become each others' 1st/exit hops!
3) Not totally sure what you mean, but we [use WireGuard-over-QUIC](https://obscura.net/blog/bootstrapping-trust/).
> Does Mullvad have the budget and expertise to protect itself against determined, highly-resourced attackers?
I think Mullvad is actively working on [System Transparency](https://www.system-transparency.org/), which will help a lot.
> Finally, is it possible for a third party, intercepting traffic between Obscura and Mullvad, to identify the public key used to encrypt it? I don't think so - the only way to validate a signature is with both keys; that's kind of the point. But maybe there is an attack I'm unaware of?
I had asked this question a long time ago on either a noiseprotocol or wireguard IRC channel, and the answer is no, a third party intercepting traffic between Obscura and Mullvad, WON'T be able to identify the public key used to encrypt it.
Here's what [one of our FAQ entries](https://obscura.net/#faq-trust) say:
> Additionally, our app displays your current exit hop’s WireGuard public key on its “Location” page. You can check this key against what Mullvad publishes [here](https://mullvad.net/servers) to ensure that you’re connected via a genuine Mullvad exit hop!
Let me know if that's unclear!
Totally! Mullvad is _the_ pioneer in this space, and we look up to them. This is why they were our top pick for being an exit hop provider!
This is actually quite an interesting point that we’ve been discussing internally.
Right now Obscura rotates your WireGuard key on every “Connect”, but in a future release we will start caching (persist) your WireGuard keys on your client. When we flip that switch, we will also enable recurring key rotation and add a button in the UI for manual key rotation. This rotation would make it harder for Mullvad to track a user across the same key. (Not that they would anyway)
All of this is available for folks to verify at on our GitHub repository: https://github.com/Sovereign-Engineering/obscuravpn-client
Woah I didn’t know about the specific term “VPN cascading”… And it seems like my GLiNet travel router can do it too?
Well in any case, it seems like with cascading you’d have to register with 2 different providers, offering your personal info (if necessary) to both.
Tor still offers more privacy benefits than Obscura for sure, but you want a shorthand, “Tor with 2 hops” works :-)
You’re absolutely right, we fixed it and forgot to push to prod XP
Ah we added payment and pricing to our navbar in staging but forgot to push to prod. Doing so now!
Happy to answer any questions y’all might have!