Trust, 2-Party Relays, and QUIC
29 comments
·February 11, 2025lapcat
dongcarl
In the extreme case that Obscura and Mullvad are forced to cooperate, you're right that this is the case. However, this is strictly (and much) less likely than a _single_ party being pressured or even a single party's infrastructure being hacked.
Another important thing to note: in our App, you can check your connected server’s public key against those listed on Mullvad’s server page, since we use the same servers as Mullvad's normal ones. It would be unheard of for a VPN provider (let alone a trustworthy one like Mullvad) to give their WireGuard private keys to a new partner.
ignoramous
> less likely than a _single_ party being pressured or even a single party's infrastructure being hacked.
Since Obscura uses a custom QUIC-based (?) protocol, you'd need to use their custom made (open core) app to pay & register with both Obscura & Mullvad. That means, all your apples are in their app-basket, which is built entirely by a single-party?
Private Relay, otoh, seems like a 3 party setup (Apple, Cloudflare, Akamai)?
dongcarl
Perhaps my answer [here](https://news.ycombinator.com/item?id=43017681) addresses your concerns!
> The client software is here: https://github.com/Sovereign-Engineering/obscuravpn-client, we also plan to make reproducible builds of our apps. In fact, I previously led the effort to revamp Bitcoin Core’s reproducible builds system to be [bootstrappable](https://bootstrappable.org/), work that is [referenced by the Tor project](https://gitlab.torproject.org/tpo/applications/tor-browser-b...).
remram
Well they do cooperate with each other. They are partners, working together to provide the service, and sharing the cost. But you have to trust that if they are trying to attack you, they do it separately...?
Ridiculous, as you point out this doesn't increase my trust at all.
kfreds
> Ok, but... don't users have to reply [rely] on their provider’s pinky-promise that the two parties won't cooperate with each other and share their separate data, thereby connecting the dots? >
Yes. On the other hand, it does complicate things for the attacker, whether it is internal (the orgs) or external - a 3rd party attacker would have to compromise both orgs instead of one.
> After all, the two parties are already cooperating to an extent, so why can't they cooperate even more, either voluntarily or at the command of some hostile government?
Voluntarily: If you look at the business incentives that wouldn't make a lot of sense.
Forced by government: Here I'd say look at the jurisdictions of the orgs.
(disclosure: I'm one of the founders of Mullvad)
ignoramous
> Here I'd say look at the jurisdictions of the orgs.
Per Covert Surveillance Act passed in 2020, looks like Sweden (where Mullvad is based) can ask communication providers / website services to secretly add or assist with backdoors?
... Where the identity of the suspect is not known, but his contacts are known, or a third party (such as a website which the suspects visits) is known, one can permit secret data reading of these contacts, or the third party, but only in order to identify the suspect. Only (stored) historical metadata, not real-time data or communications and not by means of activation of audio or video surveillance functions can be used for this (section 4b).
kfreds
I'm pretty sure you're talking about this law, in which case it doesn't apply to us.
https://mullvad.net/en/help/swedish-covert-surveillance-data...
In short, "Mullvad is thus not covered by either the data storage provisions in the LEK for operations subject to a reporting obligation, or the duty to cooperate pursuant to the Covert Surveillance of Data Act."
leishman
There is no perfect solution, but I would argue that a blind relay is very clearly strictly better than the alternative.
barathr
We've found that this decoupling (multi-party) approach is a good way to improve privacy in a bunch of networking contexts -- here's a paper we wrote a few years ago with colleagues at Fastly and Cloudflare on the topic:
https://conferences.sigcomm.org/hotnets/2022/papers/hotnets2...
dongcarl
(Carl from Obscura here)
Oh very cool! I met Chris Wood at the IETF a while back, he's working on a bunch of cool things including Privacy Pass!
kccqzy
I never met Chris Wood before but I remember this name due to him being a co-author of the Private Access Token idea[0]. I haven't heard of Privacy Pass before but it sounds very similar to PAT.
My understanding is that both of these would be very helpful to a VPN (I'm using the word loosely) user. Do you know if the adoption of Privacy Pass/PAT has reduced or mitigated annoyances such as frequent CAPTCHA checks for Obscura users?
[0]: https://www.ietf.org/archive/id/draft-private-access-tokens-...
saurik
I have never seen any of these two-hop designs (which have been increasingly popular recently) explain why--or frankly even mention that!--Tor was/is somehow wrong for believing its three hops is the minimum required number of hops to achieve the goal of anonymity. Without such an explanation, we frankly must assume that these designs are broken out of the gate due to, at bare minimum--without even having to analyze the situation much--the principle of Chesterton's Fence.
(Irritatingly, this article does link to an option from Tor's documentation, claiming its design is equivalent to a particular mode of Tor's hidden services... but, in addition to being a feature for the opposite side of the service, said documentation explicitly says that feature is "non-anonymous"; and, even still, includes a dire warning about then reusing the directory? Somehow, this feels worse than merely not contrasting their design to Tor at all, as most of these designs seem to do.)
kfreds
> .. Tor .. believing its three hops is the minimum required number of hops to achieve the goal of anonymity.
It's more nuanced than that. Tor's design states the following:
"A global passive adversary is the most commonly assumed threat when analyzing theoretical anonymity designs. But like all practical low-latency systems, Tor does not protect against such a strong adversary."
https://svn-archive.torproject.org/svn/projects/design-paper...
There are tons of ways to de-anonymize users, Tor and VPN users alike. Same goes for mixnets. Whether or not an attacker can acquire a user's real-world identity depends on a lot of parameters. The number of network proxy hops is just one parameter.
Having said that, everything else equal, more hops is better than fewer. Then again, if all the user does is log into Facebook with their real-world identity, the number of hops doesn't matter at all. Or it does, because their adversary isn't Facebook, but their local ISP! It depends on what the user wants to protect against. There is a reason the Tor Project went on to build the Tor Browser. They realized that the sort of anonymity that users were looking for wasn't to be had with only the Tor network. They needed to complement the tor client with privacy protections on the application layer.
Regarding network proxy hops there's also this perspective: strong anonymity, low bandwidth overhead, low latency - choose two. This anonymity trilemma teaches us yet again that security and performance / UX is often at odds. If you want security you have to be prepared for inconvenience.
dongcarl
The trilemma reminds me of [Performance-Enhancing Proxies](https://en.wikipedia.org/wiki/Performance-enhancing_proxy).
With PEPs, strategically placed _extra hops_ actually _help_ with performance for flaky links by terminating TCP connections.
dongcarl
Hey Saurik, long time fan! (since the jailbreaking days)
I actually talked to some of the Tor folks about this, and it seems like it mostly boils down to their chosen trust model and the fact that anyone can be a Tor node.
Most of the two-hop designs have fixed hops, and admittedly they can't beat Tor w/re privacy by any means. The fixed hops can however offer better reliability and latency.
MrAlex94
When I setup the DNS over Oblivious HTTP service for Waterfox, one of the most important parts of our setup was that each step was controlled by a different entity, which was also recommended by Fastly. In our instance it went Client (Waterfox/us) -> Relay (Fastly) -> Gateway (Cloudflare).
As far as I’m aware, Apple do the same with Cloudflare and Akamai, each controlling one relay.
Unless I’m mistaken, you’re both controlling the client software (closed source) and the first relay? As far as I can tell, trust is still essentially put into your organisation since you still control two critical parts of the setup. So maybe better than a traditional VPN provider, but still flawed?
dongcarl
Ah interesting, I didn't know Waterfox used DNS over Oblivious HTTP! (I used to run an Oblivious HTTP proxy)
> Unless I’m mistaken, you’re both controlling the client software (closed source) and the first relay?
The client software is here: https://github.com/Sovereign-Engineering/obscuravpn-client, we also plan to make reproducible builds of our apps. In fact, I previously led the effort to revamp Bitcoin Core’s reproducible builds system to be [bootstrappable](https://bootstrappable.org/), work that is [referenced by the Tor project](https://gitlab.torproject.org/tpo/applications/tor-browser-b...).
MrAlex94
Ah, the client is OSS, that’s good, appreciate the effort on reproducibility - I know how tough that is.
In theory I suppose that makes running one of the nodes less of an issue.
Would you guys ever be open to hosting a relay for other parties? I’ve been wanting to deploy OHTTP Proxy for Waterfox but have struggled being able to justify running a node myself and finding two separate parties has been a PITA.
beeflet
This is essentially recreating Tor with fewer relays. The use of QUIC is very welcome though because of latency
VPN:
> As a result, users must rely on their provider’s pinky-promise that none of their data is logged. Yet even a provider that keeps true to its promise can suffer a security breach and be compromised.
2-Party Relay:
> This splits “who you are” from “what you do”, meaning neither party can tie your identity to your browsing.
Ok, but... don't users have to reply on their provider’s pinky-promise that the two parties won't cooperate with each other and share their separate data, thereby connecting the dots? After all, the two parties are already cooperating to an extent, so why can't they cooperate even more, either voluntarily or at the command of some hostile government?