Conjure: Summoning Proxies from Unused Address Space (CCS 19) about bbs HOT 1 OPEN

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.

from bbs.