Turbo Tunnel, a good way to design censorship circumvention protocols

A common need

My purpose in writing this paper is to make the case that censorship circumvention systems should incorporate an interior session and reliability layer, independent of the obfuscation layer that provides blocking resistance. Circumvention systems of all kinds stand to benefit from a design that decouples session and obfuscation, whether in increased performance or better resistance to blocking. More importantly, the flexibility afforded by such a design facilitates new and daring circumvention designs that are not easy to realize today.

The need for a session layer separate from obfuscation has been felt, if not stated, by the developers of diverse circumvention systems over many years. In most systems, the obfuscation layer does double duty, being both a vehicle of evasion and a frame for the user's session. This unnecessary fusion of responsibilities causes a number of practical problems, major and minor, which, when not ignored, are typically dealt with uniquely within each system. One of the contributions of this work is to call attention to a common challenge. The solution I propose is to insert a dedicated session/reliability protocol—not necessarily tailored to circumvention—into the middle of the circumvention protocol stack, a design pattern I call Turbo Tunnel. See Figure 1.

To motivate the discussion, let us first outline a few specific problems facing circumvention systems and see how a Turbo Tunnel design can help. These examples will be treated in more detail in Section 3.

Problem: Censors can disrupt obfs4 by terminating TCP connections.

obfs4, like many circumvention protocols, relies essentially on an underlying TCP connection [30 §0]. There is no "session" apart from the TCP connection; when it ends, all end-to-end state is lost and a new connection must be started from scratch. This characteristic makes obfs4 vulnerable to attacks on the underlying TCP connection, like the ones that occurred in Iran in 2013, where certain connections were dropped [7] or throttled [2 §4.4] after 60 seconds. Protocols like HTTP that use short connections were hardly affected, while circumvention tunnels had to be constantly restarted. The attack has not recurred, but it remains a potential danger to protocols like obfs4 that rely on a single long-lived TCP connection.

The problem is solved by the introduction of a separate, "virtual" session that outlives any one TCP connection. When one obfs4-protected TCP connection is terminated or throttled, the client may reconnect and resume the session on another. The session protocol provides continuity by retransmitting any information lost during the transition. A TCP connection ceases to be the indispensable backbone of a session, becoming merely a transient and replaceable carrier of bytes.

Problem: meek is half-duplex.

meek creates a bidirectional stream by stringing together a sequence of HTTP requests and responses [10 §5]. meek already has the notion of a session: each HTTP request is tagged with a session identifier so that the server can associate requests from the same client. Since requests are independent at the HTTP layer, they must somehow be kept in order. The Tor deployment of meek maintains ordering by permitting only one outstanding request: the client waits for the response to its previous request before making another, giving rise to a "ping-pong" communication pattern in which only one side may send at a time.

The situation is helped by having HTTP requests and responses contain encapsulated packets of a session protocol with sequence numbers. The client may make a request whenever it has something to send. Both peers buffer and reorder incoming packets before passing their contents to an upper layer. The stream multiplexing feature of HTTP/2 means that interleaved requests do not block each other, even if they happen to use the same TCP connection.

Problem: Snowflake can use only one temporary proxy.

Snowflake [24] is built on browser-based proxies. Each proxy connection is reliable and in order while it lasts, but a proxy may disappear at any time, leaving the user with a broken session. Because proxies are run by volunteers and assigned to clients randomly, even a working proxy may, by chance, simply be too slow to use tolerably.

An independent session layer solves this problem by enabling a Snowflake client to persist a session through a sequence of disjoint proxy connections—or even to use many proxies at once, splitting traffic across them, as a hedge against one of them being slow. The session layer retransmits whatever is lost when a proxy disappears, and reassembles interleaved packet sequences that arrive over different proxies.

Problem: DNS does not guarantee order nor delivery.

DNS over HTTPS [14] has potential as a circumvention tunnel, because HTTPS encryption hides the protocol features that otherwise make DNS tunnels detectable. But any DNS tunnel requires some form of sequencing layer, because the DNS protocol is unreliable. DNS over HTTPS is reliable only up to the first recursive resolver: after that, the recursive queries use plain old UDP-based DNS, which may drop or reorder messages.

Contemporary DNS tunnels use a variety of custom reliability schemes [9]. The Turbo Tunnel approach is to treat reliability as a separable and solved problem. DNS messages can contain encapsulated packets of an existing, tested and debugged, session/reliability protocol. One part of the code can be devoted purely to encoding and decoding DNS messages, while another part builds a reliable channel on top of them, similar to how TCP builds on IP.

The DNS example hints at what is perhaps the greatest advantage of a Turbo Tunnel design: more freedom to the developer. The design of circumvention systems is a creative activity, demanding the flexibility to combine protocols in original and unexpected ways. Separating the concerns of session management and censorship evasion reduces conceptual complexity, empowering the designer to attempt more ambitious ideas. Imagine, for example, a system that permits switching between different obfuscation strategies, without losing end-to-end session state.

Implementing a Turbo Tunnel design

The essential component of a Turbo Tunnel design is an internal protocol that takes care of segmenting an outgoing stream into packets, attaching sequence numbers, and deciding when to retransmit unacknowledged data; and on the receiving side, acknowledging received data and reassembling packets back into a stream. The protocol must, of course, be realized in code as some sort of library. The core requirement on the library is that it must permit abstracting its network operations. It must not, for example, insist on sending its own UDP datagrams, but should provide hooks for the calling application to send and receive the library's packets in whatever way is appropriate for the obfuscation layer. The session layer uses the obfuscation layer as a censor-resistant network interface: whenever it would do a socket operation, it calls into the obfuscation layer instead.

In late 2019 I did a small survey [19 #14] to find protocols and libraries suited to implementing Turbo Tunnel designs. I focused on libraries written in Go, because it is commonly used among circumvention developers. The survey turned up two good candidate protocols, KCP [23] and QUIC [16], with implementations in the kcp-go [28] and quic-go [4] libraries. How the protocols work hardly concerns us; what matters is they provide the right interfaces. For our purposes they are basically interchangeable, and in fact most of the implementations in Section 3. were done twice, once with kcp-go and once with quic-go. KCP does not conform to any external standard, but is fairly simple and battle-tested. By itself, KCP provides a single reliable stream, but the related smux [29] library adds support for multiple streams. QUIC is in the process of being standardized [15]. In its usual UDP-encapsulated form, QUIC is the basis of HTTP/3 [3], and already accounts for a notable fraction of web traffic. QUIC is complex, has built-in support for multiple streams, and mandates the use of TLS.

Building a Turbo Tunnel–based circumvention system is a matter of marrying some form of obfuscation with a session/reliability library like kcp-go or quic-go. Essentially, it's a lot of glue code; see Figure 2 for how the pieces fit. The user's streams are fed into the session layer, not directly into the obfuscation layer. The session layer produces discrete packets, which must be encapsulated into the obfuscation layer such that they may be recovered at the other end. The details of encapsulation depend on the particulars of the obfuscation channel, which may itself be packet-oriented, stream-oriented, or something else entirely. The encapsulation must also associate with each packet a session identifier, a unique value that enables the recipient to distinguish packets belonging to different sessions, analogous to the four-tuple in TCP. The session identifier, being decoupled from any network address, enables roaming by the client, as in Mosh [27 §2.2] and WireGuard [5 §II-A]. The details of roaming depend on the obfuscation, but generally, a server receiving upstream packets tagged with a certain session identifier from a particular network address assumes that downstream packets for that session may be sent to that same network address.

Naively implemented, a Turbo Tunnel design may increase a circumvention system's susceptibility to traffic analysis; that is, detection based on packet sizes and timing. The headers of the session layer impose additional structure on the tunnelled data, and the sending of acknowledgement and keepalive packets may result in distinctive timing patterns. Geddes et al. showed how effective this kind of attack can be, identifying acknowledgement packets through timing and selectively interfering with them to disrupt a circumvention tunnel [13 §4.3]. This style of detection has not, so far, been a serious problem for deployed circumvention systems, but it is wise to allow room in the design for manipulating of traffic features. This means, for example, that the packet encapsulation scheme should allow for padding. It may also mean not sending a complete packet as soon as it is available, but delaying sends and consolidating or splitting packets so that the on-the-wire packet boundaries do not reflect the packet boundaries of the session layer.

The case studies of the next section have source code available that provides examples of implementing Turbo Tunnel. I have also prepared a simplified example that focuses only on the essential elements at https://www.bamsoftware.com/papers/turbotunnel/example/.

Case studies

My process for developing the Turbo Tunnel concept has been to implement it in disparate circumvention systems. The process culminated in the creation of a new DNS tunnel built to take advantage of the possibilities of DNS over HTTPS, with high performance compared to other DNS tunnels. The descriptions here are only sketches; see the "history and availability" section for links to source code and more details.

Toward a reusable library?

I have resisted positioning Turbo Tunnel as an importable library, preferring to present it as a general design pattern or a way to think about circumvention protocols. This was to avoid the risk of settling on a programming interface before first understanding all the requirements. The integrations of Section 3 were each done as if starting from scratch, sometimes borrowing previously written code but not making use of a shared Turbo Tunnel module. With the experience of having implemented the same idea several times, I am skeptical of whether a truly modular "libturbotunnel" is possible. Circumvention designs often demand breaking abstractions and accessing low-level protocol details. Some aspects of the interaction between the session and obfuscation layers, like the encoding of session identifiers into protocol messages, defy easy factorization into a library.

Nevertheless, a few common patterns have emerged that are amenable to modularization and may form the basis of a reusable library. The two main abstractions that have proved useful in every integration are (to use their dnstt names) QueuePacketConn and RemoteMap. QueuePacketConn is an adapter that transforms the "push" interface of kcp-go and quic-go into a "pull" interface. The WriteTo method of QueuePacketConn stores outgoing packets in a queue, so that the obfuscation layer may process them at its own pace (perhaps batching several packets into one send operation, or waiting for an incoming HTTP request or DNS query to respond to). The ReadFrom method of QueuePacketConn draws from a queue of incoming packets, which is replenished by the obfuscation layer as encapsulated packets arrive. RemoteMap manages a mapping of session identifiers to outgoing queues. It is used in servers to buffer outgoing packets for each ongoing session until there is an opportunity to send them. (For instance, the meek server must hold onto packets until it gets an HTTP request to which it may respond.)

kcp-go and quic-go are adequate for the task of implementing a Turbo Tunnel design, but they require a fair amount of adaptation to make them work in the way required. A session protocol designed for embedding in a circumvention system would work somewhat differently. Here is a rough list of features I found myself wishing for while working on implementations:

• A "pull" interface, not a "push" interface. Instead of calling a WriteTo callback whenever it wants to send a packet, the session library could buffer the stream of outgoing data, only breaking it up on demand, when the calling code requests a packet. The session library would still decide what actually goes in each packet—how to set the acknowledgement field, for example. It would be the caller's responsibility to poll the session library frequently enough to put packets on the network in a timely manner. Such a "pull" interface would remove the need for the QueuePacketConn adapter.

• A variable maximum size per packet. kcp-go permits setting a global maximum packet size, which is handy for limited-space contexts like DNS messages. It would be even more useful if the maximum size were not global, but could be specified for each packet as it is requested. A good interface would be "give me a packet of at most n bytes, or, if none is available, return immediately with nothing." A motivating case for this feature is DNS, in which different resolvers may have different packet length limits. The best one can do with a global maximum packet size is set it conservatively to a low value that is appropriate for all resolvers. An adaptive limit would allow more efficient use of space.

• No built-in cryptography. End-to-end encryption and authentication are, generally speaking, good features to have in a session protocol, but the cryptographic facilities of KCP and QUIC are not a good match for the Turbo Tunnel model. kcp-go supports an optional layer of symmetric-key encryption, which is unfortunately not useful in the common circumvention setting of a single proxy server accessed by mutually untrusting clients: they all know each other's key. QUIC mandates TLS for every connection, which is burdensome to set up and provide a user interface for, which is needless when the user-level protocol is something like Tor that provides its own end-to-end security.

• Few dependencies. Every added dependency is a burden on maintenance. The deployment of Snowflake in Tor Browser patches out unused cryptographic and error-correction code from kcp-go, solely to eliminate dependencies and ease maintenance.

Related work

Session-like layers have appeared many times in circumvention systems, usually out of necessity in those that are not built on a reliable channel like TCP. Code Talker Tunnel builds a reliable channel atop UDP by including sequence and acknowledgement numbers [18 §6.2]. OSS similarly embeds sequence and acknowledgement numbers into HTTP URLs [11 §4]. The StegoTorus chopper breaks a stream into packets that may be sent over disparate steganographic channels and arrive out of order [26 §3]; however each channel must itself be reliable, as the chopper does not do retransmission. Conflux proposes to improve the performance of Tor by splitting traffic across multiple simultaneous circuits; circuits are associated with a session identifier, and Tor cells contain a sequence number to permit reassembly at the exit router [1 §3]. The Camouflage system splits traffic across multiple cover channels: different streams may be assigned to different cover channels, but each stream can use only one cover channel at a time [31 §3]. TapDance prepends a session identifier to each covert flow [25 §3.2] that enables a central proxy to concatenate a sequence of short-lived flows into one long-lived session.

Some circumvention systems support tunnelling over QUIC, with optional obfuscation. Psiphon can run QUIC packets through a stream cipher before sending, so that they are not identifiable as QUIC [22]. V2Ray can transform QUIC packets to resemble other UDP-based protocols, like SRTP and DTLS [21]. These applications of QUIC may be viewed as limited implementations of Turbo Tunnel, where the session/reliability layer is QUIC, and the obfuscation layer is lightweight packet-by-packet transformation.

MASQUE [17] is a proposal to colocate proxy servers with web servers over HTTP/2 (TLS/TCP) or HTTP/3 (QUIC/UDP), such that proxy traffic looks like ordinary web traffic. Despite the use of QUIC, MASQUE is not really an example of the Turbo Tunnel idea—the key difference is that it puts QUIC on the outside of the protocol stack, not the inside. To put it in terms of this paper, MASQUE uses QUIC as an obfuscation layer, not a session/reliability layer. However, thanks to the fact that QUIC works well for both purposes, MASQUE could be adapted into a Turbo Tunnel design in two ways. First, one could run some other session protocol through the MASQUE tunnel, treating MASQUE as just another obfsucated proxy. Alternatively, one could encapsulate MASQUE's QUIC packets into some other obfuscation layer (obfs4, say, or even another instance of MASQUE) and use MASQUE as an inner session layer.