Mid level overview of Conjure registration connection flow

Detector The Detector process watches all packets on the tap, does TCP flow tracking, and forwards the TCP flows that belong to / are headed toward registered phantoms to the Application (which will do the proxying). If the detector sees a packet/flow going to a phantom, it'll forward it to the application (via a tun interface which has some DNAT rules to steer packets to the application). This requires that the detector has a map of currently registered phantoms, which can be updated by any type of registration (e.g. decoy registration, API registration, etc). The detector will also watch for decoy registrations, since this will show up in traffic to non-phantoms. We check for tapdance-style tags in the TLS packets the tap is observing here. When one is seen, it sends the registration to the Application (via ZMQ), which will do liveness testing, and send it to Redis. The list of registered phantoms lives in a Redis instance that the various components can publish/subscribe to, and serves as the central list of what phantoms are currently registered. Here's where the detector subscribes to Redis and updates its local map of registered phantoms.

Application The application receives packets/flows forwarded by the detector (via the tun interface), and figures out what specific registration it's for, handles the transport logic (e.g. obfs, WebRTC, etc), and connects/proxies to the covert destination specified in the registration.

The application also acts as the central place for anyone that wants to add a registration, and performs liveness testing before sharing them with the Detector or the Registration API. Here's where the Application receives ZMQ messages, and parses them into registrations. Registrations end up getting shared with other stations via the Registration API, and with the local Detector via Redis.

Registration API The registration API serves the REST endpoint for registration. When a registration comes in, it forwards it to the Applications on each station via ZMQ, which in turn share the registration with their respective Detector via Redis.