5 ms·

Trust, 2-Party Relays, and QUIC

60 points by kevincox 2y ago

barathr 2y ago
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/hotnets22_schmitt.pdf https://conferences.sigcomm.org/hotnets/2022/papers/hotnets2...
- dongcarl 2y ago
  (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 2y ago
    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-01.html https://www.ietf.org/archive/id/draft-private-access-tokens-...
    - dongcarl 2y ago
      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!
dongcarl 2y ago
Carl from Obscura here! Happy to answer any and all questions you may have
- smw 2y ago
  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 2y ago
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 2y ago
  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 2y ago
  > .. 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/tor-design.pdf 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.
MrAlex94 2y ago
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 2y ago
  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 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/ https://bootstrappable.org/), work that is [referenced by the Tor project](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32523 https://gitlab.torproject.org/tpo/applications/tor-browser-b...).
  - MrAlex94 2y ago
    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 2y ago
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 2y ago
  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 2y ago
    > 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 https://news.ycombinator.com/item?id=43017140
    - dongcarl 2y ago
      Perhaps my answer [here](https://news.ycombinator.com/item?id=43017681 https://news.ycombinator.com/item?id=43017681) addresses your concerns! > The client software is here: https://github.com/Sovereign-Engineering/obscuravpn-client 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/ https://bootstrappable.org/), work that is [referenced by the Tor project](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32523 https://gitlab.torproject.org/tpo/applications/tor-browser-b...).
beeflet 2y ago
This is essentially recreating Tor with fewer relays. The use of QUIC is very welcome though because of latency

60 points by kevincox 2y ago

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/hotnets22_schmitt.pdf https://conferences.sigcomm.org/hotnets/2022/papers/hotnets2...

dongcarl 2y ago
(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 2y ago
  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-01.html https://www.ietf.org/archive/id/draft-private-access-tokens-...
  - dongcarl 2y ago
    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!

dongcarl 2y ago

Carl from Obscura here! Happy to answer any and all questions you may have

smw 2y ago
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 2y ago

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 2y ago
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 2y ago
> .. 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/tor-design.pdf 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.

MrAlex94 2y ago

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 2y ago
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 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/ https://bootstrappable.org/), work that is [referenced by the Tor project](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32523 https://gitlab.torproject.org/tpo/applications/tor-browser-b...).
- MrAlex94 2y ago
  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 2y ago

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 2y ago
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 2y ago
  > 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 https://news.ycombinator.com/item?id=43017140
  - dongcarl 2y ago
    Perhaps my answer [here](https://news.ycombinator.com/item?id=43017681 https://news.ycombinator.com/item?id=43017681) addresses your concerns! > The client software is here: https://github.com/Sovereign-Engineering/obscuravpn-client 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/ https://bootstrappable.org/), work that is [referenced by the Tor project](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32523 https://gitlab.torproject.org/tpo/applications/tor-browser-b...).

beeflet 2y ago

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