-
Notifications
You must be signed in to change notification settings - Fork 335
How Geph works
Geph is ultimately a two-layer onion routing network, comparable to three-layer systems such as Tor and I2P. Unlike Tor and I2P, however, Geph is optimized for confidentiality, performance, and censorship circumvention rather than anonymity against strong network adversaries. It is also a centrally curated network rather than a peer-to-peer permissionless one like Tor.
There are four different roles in the Geph network:
-
A centralized binder that maintains global state and acts as a root of trust
-
Exits that connect to the open Internet
-
Bridges that relay traffic between clients and exits
-
Clients that maintain an end-to-end encrypted channel to an exit (via bridges), and access blocked information through this.
The two pillars of Geph's robust censorship resistance are:
-
An extremely resistant bootstrapping protocol that allows clients and binders to communicate in an effectively unblockable, but costly and slow manner. Through this bootstrapping protocol, clients obtain information about bridges, and replace them if any become blocked.
-
A state-of-the-art obfuscated bridge protocol that makes it very difficult for censors to detect bridges. This protocol uses a ScrambleSuit-style probing-resistant handshake with features such as roaming and performance-based bridge selection.
When a Geph client starts, the first thing it does is go through bootstrapping. We use domain fronting via multiple CDN providers to provide unblockable access to our binder.
The binder issues tickets to the client using a blind-signature scheme. Clients then use these tickets to authenticate to the binder again, obtaining a list of bridge descriptors. Finally, the client connects to an exit through the bridges and authenticates with tickets.
Exit nodes, running geph-exit, handle actual browsing activity. They are hosted by highly secure providers and maintain an end-to-end encrypted channel with clients.
Exits, however, have fixed IP addresses and are trivial to block through blacklisting. Thus, for circumvention in countries with sophisticated censorship like China, we can't directly connect to them. That's where bridges come in.
Bridges are servers assigned to clients by the binder. Each bridge has a bridge descriptor consisting of an IP address and a key --- one important property of a bridge is that no adversary without the bridge descriptor can identify bridge traffic. This is accomplished by probing-resistant obfuscation protocols like ScrambleSuit.
Thus, as long as no bridge descriptors fall into the hands of adversaries, bridges will not be blocked. This is accomplished by the binder giving different sets of bridges to different users, and rapidly assigning new bridges to replace old ones.
One notable difference between Geph and other tunnels is that we actually use multiple bridges for every client-exit connection. Geph continually probes for and uses the fastest path to ensure stability in changing network conditions.
-
Why use a two-layer system rather than straight proxying? We don't directly create and assign single-layer proxies because that would force us to use providers that are both secure and have good network connections to e.g. China, which severely limits our possibilities. A separation of bridge and exit allows us to find the fastest bridges and safest exits.
-
How does this compare to Shadowsocks and other systems? First of all, Geph uses a state-of-the-art obfuscation protocol better designed than ad-hoc tools like Shadowsocks, which is vulnerable to replay attacks and active probing attacks. We also choose randomized obfuscation, as well as directly tunneling over "innocent" protocols like HTTPS, rather than protocol imitation (used in V2Ray, StegoTorus, etc). Our position is that imitation is a fundamentally flawed circumvention tactic, as convincingly argued by Houmansadr et al.
-
Can Geph be deployed outside the main network owned by Gephyra OÜ? Geph can indeed be deployed on any infrastructure, although setting up the binder, exits, bridges, etc may be quite complex. We recommend a single-node, ShadowSocks-like deployment for private usage, documented in the self-hosting guide.