DNS-Morph: UDP-Based Bootstrapping Protocol for Tor
Rami Ailabouni, Orr Dunkelman, Sara Bitan
https://link.springer.com/chapter/10.1007/978-3-030-78086-9_19
https://arxiv.org/abs/1904.01240
This paper shows a way of modifying certain circumvention protocols (fully encrypted protocols such as ScrambleSuit) to send the initial handshake (and only the handshake) over a separate, mimicry-based protocol. Everything after the handshake is sent over the original, randomized, TCP-based protocol as usual. The idea is that randomized, looks-like-nothing protocols have some nice features such as resistance to active probing, but they are vulnerable to a whitelisting censor that blocks protocols it cannot recognize. Therefore you want to combine the randomized protocol with a “structured stream” protocol that mimics something classifiable. As a demonstration of the idea, the authors implement DNS-Morph, which encodes a two-way exchange of handshake data as a sequence of plaintext DNS queries and responses. With DNS-Morph, a client begins its session by making ≈80 DNS queries to the bridge, either directly or via a recursive name server. Effectively, the first part of the connection goes over a DNS tunnel, but only the first part, while the rest happens normally.
DNS-Morph is implemented as a patch to the ScrambleSuit module in pyobfsproxy. ScrambleSuit’s handshake is half-duplex: it consists of a burst of upstream data sent by the client, followed by a burst of downstream data sent by the bridge. (Other fully encrypted protocols work the same way: compare obfs3 and obfs4.) It is this initial two-step exchange that happens over DNS using DNS-Morph. The client encodes the upstream component of the handshake as base32, breaks it into fragments of 20–50 characters, and sends the fragments to the bridge as type-A DNS queries. DNS-Morph has a custom reliability protocol (based on selective repeat in the upstream direction and stop-and-wait in the downstream direction) to ensure that fragments are processed in order. The framing data for the reliability protocol is encrypted by a separate symmetric key that must be shared in advance. The bridge decodes and buffers the fragments in the queries it receives—meanwhile, as a defense against active probing, the bridge forwards the queries to a local, standard DNS server and allows it to respond as it would normally. After it has sent the entire upstream portion of the handshake, the client continues making DNS queries, in order to enable the bridge to send the downstream portion of the handshake, which it does by fragmenting and encoding the data as A and CNAME resource records in DNS responses.
Thanks to the authors for commenting on a draft of this summary.