Reproducible builds don’t do anything to help you when the US government has access to all your obscura traffic meaning they know which mullvad server you are connecting to and then they can just do traffic analysis and timing attacks to see which websites you are visiting as they know where you are exiting from. Essentially you might as well be using single hop mullvad.
2 Likes
By reproducible builds don’t help, I specifically mean that even if you use obscura with wireguard configa without their app, just having your traffic is enough since they will be forced to log
Tor could be 2 hops instead of 3, if those 2 hops didn’t collude. The point of the middle node is to make it difficult for the entry and exit to identify each other, thus reducing the possibility of collusion.
This is exactly what I have been trying to explain to you the whole time, that the network security model is valid if neither party colludes with one another.[1]
The security of the client application is an entirely different issue than the security of the network, which is what I have always been talking about. You have created this strawman about client-side software that was not relevant in the first place.
It has never been in question that the security of the client-side software needs to be separately considered. Obscura is clearly aware of this, because they plan to address it with things like reproducible builds in the future. What does this have to do with the number of parties in the network connection chain? Nothing.
Your logic here seems to suggest that the reason Tor uses 3 hops is to protect against Tor Browser compromise, which clearly makes no sense. This is why I am not conflating network security and client security at all.
What are you even talking about? Of course there is. Virtually every server without remotely attestable code can make changes to how they process data that are undetectable to the end-user. Not only is there such a thing as undetectable changes to server-side code, but that is the norm among internet services.
I think it is very dangerous advice for you to be telling people to purchase their own VPN exit node in a self-made setup. Any direct interaction with the exit node dramatically increases your risks of opsec failure.
And importantly, this is a mutual decision both parties would have to make. Not one that could be made unilaterally by a single malicious party. ↩︎
3 Likes
A note I’ll make here about remote attestation of server code: We’ve looked into this closely before and the current options are not great.
For the remote attestation to be meaningful, you need hardware support and enforcement (at least we haven’t yet seen a convincing software-based scheme). That means either Intel SGX, Intel TDX, or AMD SEV (we haven’t looked too closely at System Transparency just yet).
Intel SGX has an extremely limited runtime. It is quite difficult to port anything that does I/O to SGX, and it will incur a massive performance hit for every I/O operation. VPNs are almost all I/O, so this makes things difficult.
AMD SEV and Intel TDX (both VM-based) are a bit better w/re the porting experience, but still have flaws. AMD SEV has been around for a few years, so some of these flaws may have been addressed, whereas Intel TDX is brand new and limited to very new platforms, so it would be wise to wait until it’s gone through more penetration testing to seriously consider it.
4 Likes
IIRC you can configure the amoint of hops in your .torrc.
Agree. I am not aware of any good solutions to this problem, which is why reducing trust in servers as much as possible is so important, as you already know with your plans to use reproducible builds, and hopefully also have external client-side code audits of those reproducible builds 
I know that because of this Apple has developed their own custom solution with Private Cloud Compute that I will have to look into further sometime, not that it helps much here lol
Both of you seem to be talking past each other.
The other person is talking about how MPR where its just wireguard over wireguard is not any more private than simply setting up wireguard over wireguard since you have to trust the first party to handle traffic correctly, and also trust them to not collude with mullvad (which is not easy since the current first party’s existence depends on this mullvad boost right now). Apple private relay is better because of better protocol and because cloudflare and apple are not codependent on their partnership succeeding.
You keep talking about how it makes it easier to manage opsec since you only need to maintain 1 payment identity. This is also true, but only marginally so. If a person can maintain 1 payment identity, they can trivially maintain 2.
No, they need the exit node to not track their requests, not do DNS poisoning, or to correlate session traffic (where they track actions across each session).
The ones recommended by PG don’t send any identifier with network requests. Proton has one additional bit about payment status sent on initial connection. Are you talking about IP as an identifier?
Wrong, either party can compromise.
They can decrypt, reencrypt, and send.
Wrong. Explained above.
Again talking past each other. They seem to be talking about possibility of making it detectable, you are talking about it being currently undetectable.
Sounds wrong.
1 Like
Is the ability to use mullvad as first hop and obscura as second on the roadmap or is it a one way partnership?
To be frank, I trust mullvad more than a newcomer US based VPN with no Monero support. So I would want my IP and payment info to go to them, and then pair that to you for exit.
2 Likes
Yes I agree. I rather be able to use obscura as my last hop instead of my first.
No, Obscura does not hold the decryption keys to act as an MITM. This is for the same reason Apple doesn’t have the ability to do so. Using WireGuard in this case does not affect this property of end-to-end encryption.
No, at least with WireGuard the tunnel’s public keys themselves act as identifiers. This is why I brought up the importance of key rotation in the first place: Mullvad has partnered with Obscura VPN - #29 by jonah
Whether they log which keys are tied to which accounts is another question, but you are relying on trusting their no-log policies in this case, which is not the same as a technical guarantee.
Icloud private relay has technical guarantees. Multihopped wireguard does not
Multi-hopped WireGuard does have technical guarantees when the connection to the exit node is tunneled through the connection to the entry node, instead of being decrypted in the middle, re-encrypted, and relayed.
Multi-hop from a single service provider like the common feature in many VPN clients has no technical guarantees because the keys are held by a single entity. This is a different situation.
1 Like
In a trustless MPR system, the second relay only knows that the first relay is any possible user. In icloud private rleay, the second hop only knows that the first hop could be any possible apple user
In Obscura, mullvad knows that it is a specific obscura user connecting from a specific obscura server. This is very different from being any possible obscura user. Chained wireguard is very different than icloud private relay and this is still the case even when you chain different providers
Indeed, and it is also very different from being a customer of Mullvad directly
As I’d brought up above, there are certainly limitations with just the WireGuard protocol that Obscura needs to work around, yes. Mullvad has partnered with Obscura VPN - #29 by jonah
Edit: To be clear, the more often Obscura rotates WireGuard keys, the less feasible it becomes for Mullvad to correlate a bunch of data together as a single Obscura user. If Obscura used a new WireGuard tunnel for every single connection to the internet then Mullvad shouldn’t be able to correlate different traffic to a single Obscura user at all.
Of course, this is extremely impractical with WireGuard. There is probably a middle-ground where rotating keys every hour or so + the option to rotate on-demand would provide good enough protection. In this case Mullvad would be able to know that all traffic within a certain timeframe is tied to a specific Obscura user. But yes, this is certainly a limitation of using the standard WireGuard protocol instead of a scheme like Apple’s.
1 Like
That’s my point. In a 2-party VPN setup, you have to trust both those parties, who are already in explicit, legal business relationship, to do the right thing.
Not one that could be made unilaterally by a single malicious party
The party if it controls the client software can also unilaterally do whatever it wants, no?
Besides, the legal contracts are not public, so we don’t really know, if all parties can’t be coerced.
My point has been that a lot of trust is required even in multi-party VPNs setups, especially of the party that’s doing the selling & building clients (Apple in case of Private Relay).
It is relevant in the context of “what about unilateral maliciousness by a single provider” if one of the providers also controls the client a end-user must use, as discussed above.
If so, WireGuard’s lead developer is a sorry sob to be investing the time and effort into securely coding and building official multi-platform WireGuard apps. They could have simply stopped at the design and implementation of the protocol library?
The thing is, if you’re forced to use the client built by one of the parties in that network chain, then that party can unilaterally own you. No collusion necessary (as discussed above). It is another case, if the end-user could use any client.
No. My logic is, without the Tor Browser + Hidden services (and even OS), the guarantees of the Tor network is close to useless. Client side security matters. Just the hops, 2 or 4 or 20, aren’t enough. The Tor network, otherwise, is merely a slow (but free, at least) VPN.
The only reason I mentioned 3 hops is, for your threat model to hold, in a setup where you consider only the network (and not the client), 3 hops are minimum amount that meet it. The minute you go 2 hops, you must trust both those hops to not collude. As in, they may never, but you’d have to trust them; which is no different than having to trust them individually (the first hop, for its client & enrollment; the second hop, to refuse collusion if it ever comes to that).
Jay Freeman, the creator of Cydia / Substrate / Orchid Protocol, raised similar points: And yet, Tor--even in its browser form--uses three hops, despite not having glob... | Hacker News
No different to multi-party VPN (which also forces me to use their client) as in now I have to trust the first hop (out of my control) to not own me. Super dangerous, just the same (as discussed above).
That was rhetorical as another user explained.
Like another user said, both of us mostly are talking past each other. I get your point about separation between network security & client security (software engineering wise). I don’t agree that your model (entry only knows who; exit only knows what) holds the minute we define entry (or exit) as parties that may control just one hop of the network, but may control 100% of the client. In which case, that network/client separation only exists in our head (and dangerously so), but not in reality.
2 Likes
Yes.
See, this is where I lose you. Trusting two independent organizations to not collude is a different situation than trusting a single organization to not work against you.
If you use a single VPN, the VPN can deanonymize you at-will, i.e. a single organization can break your trust. This is obvious, since it’s just shifting trust.
If you use iCloud, Cloudflare cannot deanonymize you at-will, they don’t have all the information about you. Similarly—and once again considering only the network and not a client-side attack for the sake of the argument—Apple cannot deanonymze you at-will, because they have no information about what you’re doing. Both your trust in Apple and your trust in Cloudflare would have to be broken simultaneously for this to be a problem.
You can use this knowledge to place more trust in the overall combined system than you might otherwise place in just Apple or Cloudflare alone. With parties that are even more independent (i.e. they’re in different jurisdictions, etc.) you can reasonably decide to place even more trust in the system if you’d like.
You are misinterpreting me saying that the security of the client is a different issue as the same as me saying the security of the client is not an issue at all. This is not what I am saying.
There is no question that the security of the client is critical, but if we go all the way back to where this discussion started, the question was whether you can buy two VPN services yourself, and chain them together to achieve a similar outcome.
The answer to this question is: not unless you obtain the exit VPN provider completely anonymously.
This is because the exit provider can break your trust and tie your traffic to the account information you used when registering for the service, entirely on their own, no matter what network you use to connect to them with.
This is the problem I have been describing here this whole time, and it is entirely related to the network security model, and not at all related to the client you use.
1 Like
So in layman’s terms does PG recommend giving this a try? Using Obscura I mean?
Not yet - when they meet all the requirements PG has set. Hopefully in the future. But I suspect not anytime soon for another year at-least.
I could be wrong though.
1 Like
They would need an audit before they meet the minimum requirements. Although I’m not sure if this would go in the VPN section or a new section for MPRs. I think we can just wait a bit and see what improvements they make over time.
1 Like
It matters because the entire premise of “multi-party” is that there’s more than one party. If so, how can we state that compromises by a single party do not extend to the client they control? Private Relay (network anonymity with 2 hops iff the client is included in the whole ceremony)[1] would look very different if that didn’t matter. So would Tor (requires minimum 3 hops).[2]
If we insist that client security must be kept out of the threat model for MPRs, then MPRs must document just how entry enrolls the end-user with exit (and this enrollment will depend on the protocol, the way APIs are implemented, and other KYC-related legalities). Without an anonymizing enrollment & subsequent authorization ceremony, MPRs are relegated to being the same as multi-hop VPNs.
I am not contesting this assertion. For 2-hop MPRs, equivalent (network) threat model only holds if the end-user appears “anonymous” to exit (these guarantees must come from both control & data protocols or in the form of “trust me bro”).
In absence of protocol-level guarantees:
- My point is: The MPR’s “trust me bro” dance == end-user having to trust the
exitnode.[3]
In presence of protocol-level guarantees:
- Your point is: MPR’s anonymizing ceremony >> end-user enrolling with
entry&exitanonymously (because it is “trickier”). And that’s fair. - My point was: They’re equal, in the sense, implementing a 2-hop MPR setup like Private Relay is equally tricky and the providers can/will mess up.[4] With the end-user enrolling anonymously (tricky just the same, sure), at least they remain in control of their anonymity.
Yes, but MPRs (depending on their deployment mode) suffer from the same problem.
Who (single (unilateral) or both (collusion) or multiple (external)) can compromise what (via enrollment, payment, network; enrollment & payment bring client into the threat model):
| Deployment | Enrollment | Payment | Network (VPN Tunnel) |
|---|---|---|---|
| 1. Non-anonymous auth/z | Single – entry-controlled client and entry server automatically enroll you, revealing your exit node identity to entry. |
Single – Payment to entry (if non-anonymous) links you directly to the enrolled exit account. |
Both – entry & exit must work together |
| 2. Anonymizing auth/z | Both – An anonymizing authorization mechanism (e.g. Privacy Pass) prevents entry from linking you directly. |
Both – Anonymous payment methods (if used) ensure that neither entry nor exit has full identifying data alone. |
Both – Neither entry nor exit has complete info, so only collusion reveals the link between your identity & traffic. |
| 3. 3p Client, non-anonymous auth/z | Single – When using a 3p client, you must enroll separately with entry & exit, so each sees your identity. |
Single – Non-anonymous payment directly ties your identity to entry & exit. |
Single – exit, having received non-anonymous signup info, can de-anonymize you on its own. |
| 4. 3p Client, anonymous auth/z | None – Using anonymous sign-up methods (monero, cash) ensures that neither entry nor exit learns your true identity at enrollment. |
None – Anonymous payment decouples your identity from the payment process. | Multiple – Although enrollment is anonymous, exit still sees traffic; deanonymization may require additional external collusion. |
| 5. The onion router | None – There’s no formal enrollment process. | None – No payment is involved. | Multiple – No single relay sees both ends; full circuit compromise is needed for deanonymization. |
If we were merely talking past each other, then I guess, both of us will agree on the matrix above that #2 (tricky for providers), #4 (tricky for users), and #5 (well-known tricks) provide highest guarantees. #1 (easy for providers) and #3 (easy for users) provide pretty decent guarantees, if the parties involved are highly trustable (and hence, in my eyes, they’re equivalent).
Including creating a whole new protocol based on QUIC that doesn’t require preset & unique client-side trust anchors. ↩︎
Again, reliance on TLS which doesn’t require preset & unique client-side trust anchors. ↩︎
Completely fine to do so, if
exitis run by a privacy-respecting VPN, for example. ↩︎Or get owned by their downstream / subprocessors servers/software/setups/systems/providers in various ways. Apple’s Private Compute Core, and Signal’s server designs (part of the “network” security model) take this in to account. ↩︎
2 Likes