Mel+Geph: securing a production VPN app with Mel light clients

Our first demo of off-chain composability in action

We recently released the first production demo of securing off-chain applications with Mel — Geph, an open-source privacy and anti-censorship-focused VPN, now uses a Mel-based public key infrastructure.

Let’s talk about how we accomplished that, and how that fits into our vision of a Mel-backed off-chain Web3!

The problem

Despite being a centralized VPN service, Geph already has many measures in place to reduce trust in its server infrastructure — for instance, the use of blind-signature authentication to reduce the ability of Geph server to track users across VPN sessions. But Geph’s architecture still requires trust in servers for important security properties, like the confidentiality and integrity of proxied network traffic.

In Geph, clients access the internet through trusted exit servers. Traffic between clients and exits are then optionally routed through untrusted bridge servers to bypass national filtering (bridges blacklisted by national firewalls are quickly replcaed by new ones). Clients obtain the list of available exits and bridges through a central server cluster: the binder.

Before this integration with Mel, clients completely trusted the binder for what exits and bridges they could connect to. This means that if an attacker gains control of the binder, they have complete control over all Geph traffic. They could deploy malicious exits that spy on users’ traffic, man-in-the-middle connections and serve misinformation, exercise censorship, … (Bridges can’t decrypt user traffic, so their security is not as important.) A client had no way of automatically verifying whether the exits they’re given are even consistent with what other clients see, so attacks could even be targeted to one user and remain hidden!

The fix

Our objective with the Mel integration is to eliminate the binder as a single, fragile trusted party, and to only leave Geph’s developers (and their offline signing keys), as well as the individual exits, as trusted parties. Compromising all exits is significantly harder than taking over a single binder system, and malicious use of developer signing keys is both harder (requiring compromising Geph’s developers or hacking their personal machines) and leaves more evidence.

This is done by publishing a cryptographic hash of the most security-critical piece of information — the list of exit servers and their keys — onto Mel. Then we modified the Geph client to check the exit list it receives from the binder against the hash on Mel, which it trustlessly accesses via an embedded Mel light client. More specifically:

1. We published the hash of Geph’s list of exits and keys on the Mel betanet using gibbername, a prototype decentralized naming system that is trustlessly accessible using any Mel light client. Geph’s exit list hash is stored in the gibbername jermeb-beg – go check out its contents using the gibbername Rust crate!
2. We modified the client to obtain the exit list hash using a Mel light client and verify the binder’s list against this. How this Mel client can access the Mel network turned out to be the trickiest part of this integration: most Geph users live behind powerful national firewalls (in places like China and Iran), so our Mel client needs to be able to access Mel even if all Mel nodes are blacklisted by the client’s ISP! Fortunately, the Geph binder already solved this problem using domain fronting. So we simply added a method to the Geph binder to reverse-proxy Mel nodes and directed our embedded Mel client to access Mel through the binder.
3. Now that we can access the exit list hash on Mel, we simply check against this in the client every time we request the list of exits from the binder.

Now, an attacker who has gained control of the binder can no longer deploy malicious exits without either (1) stealing the secret key controlling the jermeb-beg gibbername off of our personal computer or (2) gaining control of the entire Mel network. To do (1), the attacker needs to get their hands on an offline key, which is quite a bit more challenging compared to compromising an online server provider. (2) will also be provably hard once Mel is fully decentralized. But since Mel is still in beta and not yet decentralized, the integration has yet to reach its full security potential. But at least the attacker needs to compromise more than 1 server provider to get (2)!

All of this is now in production use with Geph version 4.8.

Next steps

Having a hash of the exit list on Mel gives us the basis for adding many new security guarantees to Geph, especially after Mel exits betanet and $MEL has real monetary value. For example, we could put lots of money in the Mel wallet that controls Geph’s gibbername and thus provably have a large monetary incentive to secure the centralized root of trust for Geph. We could transfer that gibbername to a multisig wallet to guarantee that all changes to the exit list are signed by at least N holders of keys to that wallet…

But that’s not all we plan to do. This integration is only the first step towards transforming Geph into a full-stack technology demo of Mel’s off-chain composability vision — a decentralized confederal anti-censorship relay protocol, in which users have sovereignty over their identities rather than being at the mercy of any provider, including the “official” Geph servers.

We look forward to sharing new progress on this journey soon!