Conjure: Summoning Proxies from Unused Address Space (CCS 19)

[wkrp]

Conjure: Summoning Proxies from Unused Address Space
Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, Eric Wustrow
https://censorbib.nymity.ch/#Frolov2019b

Conjure is a refraction networking design, distinguished from others in that the covert traffic is directed towards an unused address ("phantom host") rather than a live decoy server. The design eliminates a lot of technical complexity and allows for better performance and vastly more freedom in choosing an obfuscated proxy protocol.

Using the system requires two steps. First, the client sends a covert registration signal to a Conjure station at a cooperating ISP that indicates the client's desire to start a refraction networking session. There are many imaginable ways to send a registration signal; the authors have found it convenient to reuse the chosen-ciphertext steganography technique from TapDance (§3.1), which involves sending an HTTPS request through the Conjure station to a real web server (this is not the part that uses unused addresses). Besides signaling the start of a Conjure session, the registration message contains a seed that allows the client and the Conjure station to agree on the address of a phantom host. In the second step, the client sends packets that are directed to the phantom address, and the Conjure station intercepts them and redirects them to an application proxy service. The client and Conjure station do not need to maintain a synchronized view of what addresses are unused behind the Conjure station: in the event that registration results in a "phantom" that is actually live, the client just tries again with a different seed.

Past refraction networking systems, in order to maintain the illusion of continuing conversation with a live decoy host, have had to play tricks with details of TLS and HTTP that put constraints on the data-transfer protocol. Conjure, because it doesn't need to maintain that illusion, can choose any covert proxy protocol—basically, anything that on its own won't get blocked by a censor, like obfs4, WebRTC, obfuscated SSH, or TLS with some form of SNI protection. The authors tested an implementation by deployment at a mid-sized ISP in the manner of Frolov et al. 2017. Conjure has 1000× better upload bandwidth, more consistent download bandwidth, and lower latency than TapDance.

[wkrp]

Conjure ... can choose any covert proxy protocol—basically, anything that on its own won't get blocked by a censor, like obfs4, WebRTC, obfuscated SSH, or TLS with some form of SNI protection.

One of the possible covert proxy protocols, new in this work, is "mask sites" (§4.2.3, §5.3.2, §7.1). The overall idea is that the Conjure station forwards phantom-addressed TLS traffic to some actual web site running at its own address—until the Conjure station discovers that the client is using a special prearranged key, at which point the station hijacks the connection and begins forwarding it to an application proxy instead. The motivation here is that TLS makes a good covert channel, but has a few caveats: in order to look like a genuine TLS connection, the server needs to present a valid CA-signed certificate (not a problem with TLS 1.3), and the client needs to present a plausible SNI (even with TLS 1.3, at least until ESNI arrives). By always forwarding at least the first part of the TLS connection to a real site, the client is able to provide a plausible SNI (that of the mask site) and the Conjure station is able to provide a genuine certificate that matches that SNI (forwarded from the mask site).

Here's how it works more concretely. The client sends a registration signal that indicates it wants to use mask sites. The client and Conjure station agree on a phantom address P, and also derive a special shared secret key. The station begins forwarding traffic addressed to P to instead go to the mask site, say example.com. It's not IP-layer forwarding, it's TCP-layer forwarding: the Conjure station itself acts as the endpoint for incoming TCP connections that are addressed to P (sending back its own SYN/ACK, etc.), then initiates its own, separate TCP connection to the mask site, forwarding only the contents of the TCP connection, not the TCP segments themselves. While forwarding, the Conjure station passively inspects the TLS stream, looking for an Application Data record. The client, instead of encrypting the Application Data record using the key that resulted from the TLS handshake, encrypted the record using the prearranged key that it shares with the Conjure station. The Conjure station attempts to decrypt the record using the same key, and, if successful, ceases forwarding to example.com and instead starts forwarding to an application proxy service. The key-switching magic is made possible by uTLS. If decryption using the special key does not work, the Conjure station just carries on with unmodified TCP-layer forwarding until the connection ends.

The idea requires some care in choosing mask sites. The censor-observable communication flow is that of a client having a TLS session with a real TLS server, just at an IP address other than one at which that server would normally be found. So, for example, if the censor knows that a certain site normally resides on one and only one IP address, it can block all TLS connections that purport to be for that site while being addressed to a different IP address. Ideally, one chooses a mask site that could plausibly reside past the Conjure station at a phantom address in its range. §4.2.3 lists considerations for mask site selection. Another consideration with mask sites is that, because the Conjure station forwards TCP payloads and not IP packets, the observable TCP fingerprint of the connection may not match that of a direct connection to the mask site. If the censor knows, for example, that the mask site usually has an initial TCP window size of 16384, but observes a connection with 14480, or that the TCP timestamp frequency is 200 Hz when it should be 1000 Hz, it could block connections on that basis. Some considerations along these lines appear in §7.1.