Trust, 2-Party Relays, and QUIC | Hacker News Reader

Trust, 2-Party Relays, and QUIC

obscura.net

60 pointskevincox33 comments

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?

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.

> 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)?

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...).

> 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)

> 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).

https://www.venice.coe.int/files/Spyware/SWE-E.htm / https://archive.vn/LgE7a

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."

> it doesn't apply to us

This is also what your website says,

  But it could be interpreted contrarily - that VPN services through, for example, encryption via signals that the VPN service itself has power over through agreements with subcontractors, etc. could possibly be seen as an electronic communications service ...

And I'm not just talking about Mullvad VPN (the "electronic communication service" provider), but Mullvad AB, which also hosts websites and builds apps (like the browser and VPN clients), too.

So, is the "law doesn't apply" a fact? If so, may want to reword this bit on your website to make that much clear:

  [Mullvad's] opinion is that the reasonable interpretation is that a VPN service is not to be considered as an electronic communications service based on previous legislative history.

If not, due to the "covert" nature of the Act, if Mullvad was coerced to co-operate with the govt, it seems Mullvad couldn't even publicly talk or hint about it (like warrant canaries, for example)?

I'm writing this on my phone and for whatever reason can't find the passages that you're quoting. Are they in the same article that I linked?

In any case, to my knowledge the law in question doesn't apply to us. If the Swedish government tried to argue otherwise we'd get our lawyers involved.

Having said all of this, I am concerned about National Security Letters and similar concepts. Technologies like reproducible builds, transparency logs, and remote attestation can help there.

Thanks.

> Are they in the same article that I linked

https://mullvad.net/en/help/new-law-for-electronic-communica... / https://archive.vn/86hGz

> to my knowledge the law in question doesn't apply to us

Fair. This isn't the official Mullvad position, then (which is that the law may apply)?

The "Communication provider" part aside, another source (quoted above) makes it explicit that backdooring "websites" (Mullvad has a website) are fair game, btw.

> If the Swedish government tried to argue otherwise we'd get our lawyers involved

I don't doubt you would. Given the "covert" nature of the Act, Mullvad's arguments & Sweden's counter-arguments and the outcome from it (backdoors, compromises, coercion etc) will be kept a state secret. That is, there doesn't seem to be a way for the public to independently ascertain the claim that the Mullvad did fight and indeed "the law didn't apply"? [0]

> reproducible builds, transparency logs, and remote attestation

Much needed (:

Per Mullvad's posts, the Act seems to grant wide-ranging powers to Swedish authorities, including installing hardware & other sorts of physical compromises (which no amount of software mitigations would thwart, I don't think).

[0] Focusing on the premise: "Forced by government: Here I'd say look at the jurisdictions of the orgs."

> Fair. This isn't the official Mullvad position, then (which is that the law may apply)?

I'm pretty sure our official position is that it doesn't apply, rather than it may apply. Note that the article on our website that I quoted is more recent than the one you quoted. I can't find a more recent legal opinion than that.

Regarding backdooring websites, that's interesting. I'll have to ask someone about that. Thanks.

> the outcome from it (backdoors, compromises, coercion etc) will be kept a state secret

I am not a legal expert, but I'm pretty sure you're wrong. The first-order outcome would be a court case that says the law applies to VPNs, or not. The second-order outcome would be secret coercion in a specific criminal case, or nothing. The first-order outcome would be public. Interesting question though. I'll have to ask about this too.

> Much needed (:

Yes. :)

It might interest you to know that I've spent the past six years working on things like that. My role at Mullvad since several years is only strategic, as I spend almost all of my time on applied research. See glasklarteknik.se and tillitis.se.

> (which no amount of software mitigations would thwart, I don't think)

Physical security is hard. However, I see no reason to limit ourselves to only software-based mitigations.

> Regarding backdooring websites, that's interesting. I'll have to ask someone about that. Thanks

No, thank you! I look forward to an update on Mullvad's help/blog on this.

> The first-order outcome would be a court case that says the law applies to VPNs, or not.

My contention was, Mullvad AB (the other parts of its services like the app, the browser, the website, & the parts of its infrastructure like its control plane that isn't running the VPN) is already subject to 2020:62 (the Act) in ways which may remain secret, if enforced. I'm not an expert in Swedish law, but also, I'm not sure who else to ask.

For example, here's some revealing text (on just who 2020:62 applies), from a 3p source I linked to in my first reply:

  The possibility for the police and security police to use spyware was introduced by the Act (2020:62) on Secret Reading of Data. For domestic purposes, secret data reading means  that "information, which is intended for automated processing, is secretly and with technical means, read from or recorded in a readable information system".

  "Readable information system" in turn means "an electronic communication device or a user account for, or a correspondingly delimited part of, a communication service, storage service or similar service".

  Thus, it covers both physical equipment, such as a mobile phone or a computer, as well as a user account to, or a correspondingly delimited part of, a communication service, storage service or similar service.

Note that "electronic communication service" is just ONE of the 3 entities subject to 2020:62, per that source. The legal language is pretty wild and pretty wide, imo. Which brings me to...

> The first-order outcome would be a court case that says the law applies to VPNs, or not ... would be public.

May not matter as Mullvad AB might decisively meet other criteria laid out in 2020:62 (the Act). That is, regardless of whether Mullvad "VPN" is subject to 2020:62, Mullvad as a business building all kinds of other software might be.

> only software-based mitigations

True. Thanks for being so patient. I tried to send follow-up queries to you folks via PrivacyGuides, but for some reason they didn't & in fact, they stonewalled, & even deleted/removed posts on the topic. Now that I'm hearing from you directly, I feel that much more assured.

I guess, it pays to go direct rather than fight it out on some forum with gatekeepers.

> tillitis.se

Dang... didn't realise 'twas you folks. Amazing.

> glasklarteknik.se

Eventually expect Mullvad severs to experiment with either microkernels (ala Fuschia) or unikernels, to replace the monolith that is Linux Kind of like (the uber sophisticated) OpenVPN vs. (leaner, meaner) WireGuard.

Thanks once again.

It is worth noting that your second quote is from a blog posted in May 2020, and the link that kfreds posted is from their follow-up blog post, dated July 2020.

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.

Hey! Let me know if this answers some of your questions :-)

https://news.ycombinator.com/item?id=43017755

No. It seems very likely that if Mullvad wanted to identify some traffic, they would be able to get some metadata information from you, their partner. Your entire product depends on theirs.

There is no perfect solution, but I would argue that a blind relay is very clearly strictly better than the alternative.

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...

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

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-...

You're absolutely right, Privacy Pass would definitely be helpful to consumer VPN users! :-)

We haven't implemented Privacy Pass yet as it would require a browser extension, but it is one of the technologies we keep an eye on!

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.)

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.

> .. 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.

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.

after having some direct awareness of how traffic shows up in netflow and the nature of global routing, i am not convinced that it requires a global visibility per se, but certainly is dependent on where traffic lands in a global sense. it’s a small world on the big ol internet.

And yet, Tor--even in its browser form--uses three hops, despite not having global passive adversaries in its attacker model. I guess I thereby don't understand your thesis, which seems--to me--a bit muddled... you are saying Tor does not solve all problems (it would have to be the opposite to make sense... Tor hops would need to protect concrete models that Obscura doesn't solve, providing an excuse for the fewer hops) and you are saying users give up anonymity in other ways anyway (which is both a non-sequitur and also a bit wrong, as I will assert someone can be happy giving their real name and driver's license to Facebook but not be happy divulging their current IP address, as the many varied forms of private personal identification are not inherently fungible; and like, Tor being a browser doesn't even solve this: that solves yet a different problem that is out of scope for the hops)...

...but the only reason you cite for why 2 and not 3 is that 3 is slower than 2. You know what's even slower than 3? 4! ;P But AFAIO Tor doesn't, in fact, think "more hops is better than fewer": they believe there is a single correct number of hops, and that if you add even more hops you actually can cause new problems with their structure? Regardless, I think we all agree that 1 is slower than 2, and yet 1 definitely isn't enough ;P.

So, for a given attacker model, I contend that there seems to be a lower bound on the number of required hops... and therefore either there is a specific attacker Tor solves that this doesn't, or they are wrong on the number of hops required to protect against their attacker model. I am willing to buy either, but do feel this needs to be explained by projects that go with 2, as the Tor people seem very sane to me ;P.

(Regardless, I am very curious about the structure of the "partnership" with your company... would you be open to partnerships with other companies? Is there anything special you added on your side to make this partnership work that maybe could be generalized and taken advantage of by other projects? I am not convinced at all by Obscura, but I do like Mullvad, and have been wanting to work with you all for quite a while now ;P.)

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?

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...).

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.

This is essentially recreating Tor with fewer relays. The use of QUIC is very welcome though because of latency

Carl from Obscura here!

Happy to answer any and all questions you may have

I understand that China and Russia, for instance, are blocking most or all QUIC traffic? Do you know otherwise? Is attempting to bypass state level blocking one of your goals?

Reply on news.ycombinator.com