Home
Conjure is a growing research project so speedbumps and issues will occur. If you encounter a new problem please document it in an issue! Currently Issue #43 tracks a number of solved persistent issues in the station standup process.
Most of today’s censorship circumvention tools use the same fundamental approach: they encrypt the user’s traffic to make it look innocuous, and channel it to a proxy server located outside the censored network. This leads to a fundamental problem: Once the censor discovers the proxy server, the proxy itself becomes just another site to block. If users can find the proxy servers, the censors can too.
In this race to find and use—or find and block—proxy servers, censoring governments enjoy natural, growing advantages over censored users. For example, they can examine all data flowing across their borders in search of disfavored activity. Strategies that rely on friendly servers are failing against increasingly sophisticated state-level censors who can see and control a country’s entire network.
Refraction networking* takes a different approach. Rather than trying to hide individual proxies from censors, refraction brings proxy functionality to the core of the network, through partnership with ISPs and other network operators. This makes censorship much more costly, because it prevents censors from selectively blocking only those servers used to provide Internet freedom. Instead, whole networks outside the censored country provide Internet freedom to users—and any encrypted data exchange between a censored nation’s Internet and a participating friendly network can become a conduit for the free flow of information.
Conjure was designed as a successor to the TapDance system and has worked to incorporate as many of the good ideas and hard learned lessons from previous refraction protocols as possible. First and foremost Conjure implements the tap based architecture of the TapDance system. However, instead of parasitizing a connection to a live host Conjure allows clients to connect to the unused address space that routes past a refraction station and responds as though it is a server at that address with limited reachability. Because the default state of the endpoints in use is to never respond to traffic, Conjure limits exposure to RAD, asymmetrical routing, and probing attacks.
Conjure uses a two stage process to establish a proxied connection, similar to the architecture of the Cirripede system. To effectively circumvent censors, both of stages must be non-trivial to block. The first is the registration in which a client generates and shares connection parameters with the station. This process is designed to be modular in order to keep clients online if any one registrar is blocked by quickly transitioning to another. Currently Conjure supports two independent registrars. The first uses a TapDance (and Telex) style tagged connection that embeds session details in an HTTPS GET request using an X-IGNORE header and securely leaking the TLS keys and registration information to a listening station. The second registrar is a simple http API which can be used in a a direct configuration or composed with a third part proxy (e.g. domain fronting) intermediary.
The second stage is connection during which a client connects to a Phantom address, using a “transport protocol” that wraps the clients connection. Phantoms are chosen during the registration phase from a set of subnets pre-shared with the user in a configuration file. Again, the transport protocols are modular and swappable to make them as difficult to block as possible. Currently Conjure supports a minimal transport which prepends the data stream with a 32 byte random during connection initialization (to allow for de-duplication when phantom tuples collide), and Obfs4 where each connection generates unique key materials based on the secrets shared in the registration. The original Conjure paper proposed a third transport similar to the Slitheen protocol that would allow a client to specify a “Mask Site” that the station would mimic and embed client traffic within, though this has not yet been used in production due to implementation complexity. The transport connection transfers information from the client to the station, wrapping the protocol that is sent to the covert destination. Functionally, the client operates as though it is communicating with a host at the phantom address though in reality it is the station responding by spoofing the address in any response packets. Conjure uses two contiguous network connections to accomplish this, one connection from the client to the station(phantom) and a second from the station to the covert address with data buffered and transferred between. Conjure requires no kernel level modifications to the client, making adoption relatively simple. It is important to note that the tap design of stations necessitates that any packets sent by the client to the phantom address continue past the station — any downstream routers will attempt to deliver the packets to the phantom address.
Because connections to phantom addresses can be long lived, the multi-station coordination issues facing Conjure are different than those identified in the TapDance deployment. As clients can register past any one station and connect past any other, the stations optimistically share registrations. Conjure uses the registration API as a centralizing node that allows stations to work together. When a station validates a registration, it shares it with the API which then publishes it to the other stations.