[HN Gopher] Trust, 2-Party Relays, and QUIC
___________________________________________________________________
Trust, 2-Party Relays, and QUIC
Author : kevincox
Score : 41 points
Date : 2025-02-11 18:44 UTC (4 hours ago)
(HTM) web link (obscura.net)
(TXT) w3m dump (obscura.net)
| barathr wrote:
| 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 wrote:
| (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 wrote:
| 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-...
| dongcarl wrote:
| Carl from Obscura here!
|
| Happy to answer any and all questions you may have
| smw wrote:
| 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?
| saurik wrote:
| 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.)
| dongcarl wrote:
| 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.
| kfreds wrote:
| > .. 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 wrote:
| 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.
| MrAlex94 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| lapcat wrote:
| 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?
| dongcarl wrote:
| 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 wrote:
| > _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)?
|
| See also: https://news.ycombinator.com/item?id=43017140
| dongcarl wrote:
| 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.o
| rg/tpo/applications/tor-browser-b...).
| kfreds wrote:
| > 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 wrote:
| > _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
| kfreds wrote:
| 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."
| ignoramous wrote:
| > _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)?
| kfreds wrote:
| 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.
| ignoramous wrote:
| 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)?
|
| "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_
|
| 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."
| ziddoap wrote:
| 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.
| remram wrote:
| 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.
| dongcarl wrote:
| Hey! Let me know if this answers some of your questions :-)
|
| https://news.ycombinator.com/item?id=43017755
| remram wrote:
| 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.
| leishman wrote:
| There is no perfect solution, but I would argue that a blind
| relay is very clearly _strictly_ better than the alternative.
| beeflet wrote:
| This is essentially recreating Tor with fewer relays. The use of
| QUIC is very welcome though because of latency
___________________________________________________________________
(page generated 2025-02-11 23:00 UTC)