Tapdance: End-To-Middle Anticensorship Without Flow Blocking Eric Wustrow, Colleen M
Total Page:16
File Type:pdf, Size:1020Kb
TapDance: End-to-Middle Anticensorship without Flow Blocking Eric Wustrow, Colleen M. Swanson, and J. Alex Halderman, University of Michigan https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/wustrow This paper is included in the Proceedings of the 23rd USENIX Security Symposium. August 20–22, 2014 • San Diego, CA ISBN 978-1-931971-15-7 Open access to the Proceedings of the 23rd USENIX Security Symposium is sponsored by USENIX TapDance: End-to-Middle Anticensorship without Flow Blocking Eric Wustrow Colleen M. Swanson J. Alex Halderman University of Michigan University of Michigan University of Michigan [email protected] [email protected] [email protected] Abstract tools, researchers have recently introduced a new ap- In response to increasingly sophisticated state-sponsored proach called end-to-middle (E2M) proxying [21, 26,49]. Internet censorship, recent work has proposed a new ap- In an E2M system, friendly network operators agree to proach to censorship resistance: end-to-middle proxying. help users in other, censored countries access blocked This concept, developed in systems such as Telex, Decoy information. These censored users direct traffic toward Routing, and Cirripede, moves anticensorship technology uncensored “decoy” sites, but include with such traffic a into the core of the network, at large ISPs outside the special signal (undetectable by censors) through which censoring country. In this paper, we focus on two techni- they request access to different, censored destinations. cal obstacles to the deployment of certain end-to-middle Participating friendly networks, upon detecting this signal, schemes: the need to selectively block flows and the need redirect the user’s traffic to the censored destination. From to observe both directions of a connection. We propose a the perspective of the censor—or anyone else positioned new construction, TapDance, that removes these require- between the censored user and the friendly network—the ments. TapDance employs a novel TCP-level technique user appears to be in contact only with the decoy site. that allows the anticensorship station at an ISP to function In order to block the system, the censor would have to as a passive network tap, without an inline blocking com- block all connections that pass through participating ISPs, ponent. We also apply a novel steganographic encoding which would result in a prohibitive level of overblocking to embed control messages in TLS ciphertext, allowing us if E2M systems were widely deployed at major carriers. to operate on HTTPS connections even under asymmetric Deployment challenges While E2M approaches ap- routing. We implement and evaluate a TapDance proto- pear promising compared to traditional proxies, they face type that demonstrates how the system could function technical hurdles that have thus far prevented any of them with minimal impact on an ISP’s network operations. from being deployed at an ISP. All existing schemes as- sume that participating ISPs will be able to selectively 1 Introduction block connections between users and decoy sites. Unfor- tunately, this requires introducing new hardware in-line Repressive governments have deployed increasingly so- with backbone links, which adds latency and introduces a phisticated technology to block disfavored Internet con- possible point of failure. ISPs typically have service level tent [5,50]. To circumvent such censorship, many users agreements (SLAs) with their customers and peers that employ systems based on encrypted tunnels and proxies, govern performance and reliability, and adding in-line such as VPNs, open HTTPS proxies, and a variety of flow-blocking components may violate their contractual purpose-built anticensorship tools [1, 2, 13, 25, 37]. How- obligations. Additionally, adding such hardware increases ever, censors are able to block many of these systems by the number of components to check when a failure does discovering and banning the IP addresses of the servers on occur, even in unrelated parts of the ISP’s network, po- which they rely [46,47]. Some services attempt to remain tentially complicating the investigation of outages and unblocked by frequently changing their IP addresses, but increasing downtime. Given these risks, ISPs are reluc- they face a tension between the desire to make their net- tant to add in-line elements to their networks. In private work locations known to would-be users and the need to discussions with ISPs, we found that despite being willing keep the same information secret from the censor. to assist Internet freedom in a technical and even finan- To avoid this tension and escape the cat-and-mouse cial capacity, none were willing to deploy existing E2M game that results between censors and anticensorship technologies due to these potential operational impacts. USENIX Association 23rd USENIX Security Symposium 159 Furthermore, our original E2M proposal, Telex, as- 2 Review of Existing E2M Protocols sumes that the ISP sees traffic in both directions, client- decoy and decoy-client. While this might be true when There are three original publications on end-to-middle the ISP is immediately upstream from the decoy server, proxying: Telex [49], Decoy Routing [26], and Cirri- it does not generally hold farther away. IP flows are of- pede [21]. The designs for these three systems are largely ten asymmetric, such that the route taken from source to similar, although some notable differences exist. Figure 1 destination may be different from the reverse path. This show the Telex scheme, as one example. asymmetry limits an ISP to observing only one side of a In each design, a client wishes to reach a censored connection. The amount of asymmetry is ISP-dependent, website. To do so, the client creates an encrypted connec- but tier-2 ISPs typically see lower amounts of asymmetry tion to an unblocked decoy server, with the connection to (around 25% of packets) than tier-1s, where up to 90% this server passing through a cooperating ISP (outside the of packets can be part of asymmetric flows [48]. This censored country) that has deployed an ISP station. The severely constrains where in the network E2M schemes decoy can be any server and is oblivious to the operation that require symmetric flows can be deployed. of the anticensorship system. The ISP station determines Our approach In this paper, we propose TapDance, that a particular client wishes to be proxied by recogniz- a novel end-to-middle proxy approach that removes these ing a tag. In Telex, this is a public-key steganographic tag obstacles to deployment at the cost of a moderate in- placed in the random nonce of the ClientHello message of crease in its susceptibility to active attacks by the censor. a Transport Layer Security (TLS) connection [12]. In Cir- TapDance is the first E2M proxy that works without an ripede, users register their IP address with a registration inline-blocking or redirecting element at an ISP. Instead, server by making a series of TCP connections, encoding our design requires only a passive tap that observes traffic a similar tag in the initial sequence numbers (ISNs). In transiting the ISP and the ability to inject new packets. Decoy Routing, the tag is placed in the TLS client nonce TapDance also includes a novel connection tagging mech- as in Telex, but the client and the ISP station are assumed anism that embeds steganographic tags into the ciphertext to have a shared secret established out of band. of a TLS connection. We make use of this to allow the In both Telex and Cirripede, the tag consists of an el- system to support asymmetric flows and to efficiently liptic curve Diffie-Hellman (ECDH) public key point and include large steganographic payloads in a single packet. a hash of the ECDH secret shared with the ISP station. In Although TapDance appears to be more feasible to de- Decoy Routing, the tag consists of an HMAC of the previ- ploy than previous E2M designs, this comes with certain ously established shared secret key, the current hour, and tradeoffs. As we discuss in Section 5, there are several a per-hour sequence number. In all cases, only the station active attacks that a censor could perform on live flows in can observe this tag, using its private key or shared secret. order to distinguish TapDance connections from normal Once the station has determined that a particular flow traffic. We note that each of the previous E2M schemes is should be proxied, all three designs employ an inline also vulnerable to at least some active attacks. As a poten- blocking component at the ISP to block further commu- tial countermeasure, we introduce active defense mech- nication between the client and the decoy server. Telex anisms, which utilize E2M’s privileged vantage point in and Decoy Routing both block only the tagged flow us- the network to induce false positives for the attacker. ing an inline-blocking component. Cirripede blocks all Even with these tradeoffs, TapDance provides a real- connections from a registered client. Cirripede’s inline istic path to deployment for E2M proxy systems. Given blocking is based on the client’s IP address and has a long the choice between previous schemes that appear not to duration, possibly making it easier to implement than the be practically fieldable and our proposal, which better flow-based blocking used in Telex and Decoy Routing. satisfies the constraints of real ISPs but requires a careful After the TLS handshake has completed and the client- defense strategy, we believe TapDance is the more viable server communication is blocked, all three designs have route to building anticensorship into the Internet’s core. the station impersonate the decoy server, receiving pack- Organization Section 2 reviews the three existing ets to and spoofing packets from its IP address. In Telex, E2M proposals. Section 3 introduces our chosen cipher- the station uses the tag in the TLS client nonce to com- text steganography mechanism, and Section 4 explains pute a shared secret with the client, which the client uses the rest of the TapDance construction.