Hey Carl! This is the first I'm hearing of Obscura. After doing a deep dive into your product, it looks to be a very fascinating privacy tool. However, I'm concerned with your operating under US jurisdiction, as detailed by others here:
While I understand potentially not wanting to incorporate in the EU (with Chat Control on the horizon) nor Switzerland (due to their own non-EU-related privacy backslide), why still select the US, which historically other privacy tools have largely avoided? It feels like you're already shooting yourself in the foot, whereas you'd be good in the EU should Chat Control not pass. While it's great that you verifiably can't see a user's internet traffic, you're one US court order away from a forced compromising of the service for a user (or at least, giving up the connecting IP). Historically, EU court orders have been easier and more transparently fought by privacy tools.
Non sequitur, it would be great if you prioritized accepting Monero as payment, like your exit hop Mullvad. Also, how much control do we have over the features Mullvad offers (e.g. DAITA, quantum resistance, DNS filters, IPv6, integration with Mullvad Browser)?
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!
Can you control the geography of the exit node? I really like Private Relay but it doesn't get around geo restrictions because the IP is still in the same country you are.
> If you can't see your VPN's source code, you can almost safely assume that they're broken in some way.
This is definitely true insofar that you better be able to see client code. That said, since you cannot see what the server is running, even if they release their code, you will still end up with a trust actor or two (vpn operator or sometimes multiple vpn operators in double hop cases).
That’s exactly the reason we introduced deterministic and verifiable VPN technology on https://VP.NET which allows you to actually see the code the VPN servers are running. Instead of trust in a non deterministic human actor you can now trust deterministic and verifiable code.
Even if you could, there's no way to guarantee it's the same code that's actually pushing your packets around.
Even vp.net which says they use SGX to verify the code that is running on a box... yea you are verifying a box, somewhere, not necessarily the one forwarding your packets. And those packets can still be monitored/modified outside the system at some other part of the network anyways.
And even if you could verify all that, eBPF swoops in and lets you modify code at runtime with no evidence trails.
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.
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.
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/
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.
*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!
You may want to try using a generic WireGuard client (e.g. `wg-quick`) rather than Mullvad's client, you can generate a WireGuard config on Mullvad's website.
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.