Multiproxy: a Collaborative Approach to Censorship Circumvention

MultiProxy: a collaborative approach to censorship circumvention

Gaomei Shi

MultiProxy: a collaborative approach to censorship circumvention

Master’s Thesis in Computer Science

Distributed Systems group Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology

Gaomei Shi

28th March 2019 Author Gaomei Shi

Title MultiProxy: a collaborative approach to censorship circumvention

MSc presentation 29th March 2019

Graduation Committee Dr. sc. ETH J.S.Rellermeyer Delft University of Technology Dr. ir. J.A.Pouwelse Delft University of Technology Dr. -Ing. T.Fiebig Delft University of Technology Abstract In recent years, many countries and administrative domains exploit control over their communication infrastructures to censor online materials. The concrete reasons behind the Internet censorship remain poorly understood due to the opaque nature of the systems. Generally, Internet censorship is to disrupt the free ﬂow of information. It involves a series of steps to stop the dissemination of information, or prevent the access to information, for example, disrupt the link between the users and providers. These technologies bring signiﬁcant inconvenience for legitimate users. The goal of the thesis is to undertake a recent study to measure the behavior of the Great Firewall of China (GFW). Based on that, this work designs a Peer-to-Peer (P2P) circumvention system called MultiProxy which exploits the blockchain-based economical model in order to create a balanced environment for resources providing and consuming. The system also uses multi-hop messaging to protect the privacy of the request initiators. The evaluation results show that MultiProxy can evade censorship while protecting users privacy. iv Preface

Censorship is existing and prevalent with the advent of the Internet. It is like a double-edged sword which has both positive and negative impact on the general public. For instance, the Internet censorship limits the bad information from spreading, while at the same time it also restricts the access according to prefer- ences of regimes, and this can cause inconvenient for netizens. Take the GFW, the world’s largest country-wide Internet censorship system as an example. There are few numbers of formal documentation about the operational principles under such a sophisticated system. Therefore, I think its patterns are deserved to be explored, and with knowledge about the working mechanisms of the GFW, a countermeasure could be further designed.

It was very pleasant to be able to work on this exciting and challenging research topic in the Distributed Systems group. First of all, I would like to thank my super- visor Jan, I would not have been able to complete the underlying work without his excellent scientiﬁc guidance. I would also like to thank Martijn for his assistance and support on the project API usage and coding. Finally, I would like to express my sincerest gratitude to my family for their unconditional supporting, encourage- ment and motivational capabilities.

Gaomei Shi

Delft, The Netherlands 18th March 2019

v vi Contents

Preface v

1 Introduction 5 1.1 A brief history of the GFW ...... 5 1.2 The categories of circumvention systems ...... 6 1.3 Thesis Structure ...... 7

2 Problem description 9 2.1 Research Questions ...... 9 2.2 Internet Censorship ...... 10 2.2.1 Client-side censorship ...... 10 2.2.2 Server-side censorship ...... 11 2.2.3 In-path censorship ...... 11 2.2.4 On-path censorship ...... 11 2.3 Analysis and Blocking Mechanisms ...... 11 2.3.1 In-path censorship ...... 12 2.3.2 On-path censorship ...... 13 2.4 Obfuscation of censorship circumvention systems ...... 16 2.4.1 Payload encryption ...... 17 2.4.2 Randomizer ...... 17 2.4.3 Mimicry ...... 18 2.4.4 Tunneling ...... 18 2.5 P2P architecture - Build a trust network to overcome censorship . 20

3 Empirical evaluation of the GFW 23 3.1 Experimental Setup ...... 23 3.2 IP blocking ...... 24 3.3 TCP connection reset ...... 27 3.3.1 HTTP keywords detection ...... 27 3.3.2 DNS keywords detection ...... 28 3.3.3 TCP connection reset module ...... 31 3.4 DNS hijacking and DNS cache poisoning ...... 32 3.4.1 How the GFW intercepts DNS resolution ...... 32

vii 3.5 Experimental results and summary ...... 35 3.5.1 Threat model ...... 35 3.5.2 Results and Circumvention suggestions ...... 35

4 Circumvention System Design 37 4.1 Design goals ...... 37 4.2 System Architecture ...... 39 4.3 Trafﬁc forwarding ...... 40 4.3.1 SOCKS on edges ...... 40 4.3.2 Peer-to-peer system ...... 42 4.4 Token economy ...... 43 4.4.1 Analysis of threats to the system ...... 44 4.4.2 Solutions for threats ...... 46 4.5 Multi-hop messaging ...... 52 4.5.1 Solutions for data privacy ...... 52 4.6 Implementation details ...... 53 4.6.1 Trafﬁc forwarding ...... 53 4.6.2 Token economy ...... 54 4.6.3 Anonymous messaging ...... 55

5 Evaluation 57 5.1 Evaluation framework ...... 57 5.1.1 Network performance ...... 57 5.1.2 System performance ...... 58 5.2 Methodologies and experimental steps ...... 59 5.2.1 System performance ...... 59 5.2.2 Performance Comparison ...... 60 5.3 Results and analysis ...... 61 5.3.1 Network performance ...... 61 5.3.2 System performance ...... 63 5.3.3 Scalability test ...... 66

6 Conclusions and Future Work 67 6.1 Conclusions ...... 67 6.1.1 Results for each research questions ...... 67 6.1.2 Main contributions ...... 71 6.2 Future Work ...... 71

viii List of Figures

2.1 An overview of censorship system ...... 10 2.2 A general censorship model ...... 11 2.3 DNS hijacking and DNS poisoning ...... 16

3.1 Experimental pipeline for categorizing different root causes . . . . 25 3.2 IP blocking ...... 25 3.3 TCP connection reset ...... 27 3.4 The model of TCP connection reset device ...... 31 3.5 DNS hijacking ...... 32 3.6 DNS cache poisoning ...... 33

4.1 A Tor circuit with pluggable transport meek ...... 38 4.2 The average connected clients number of cymrubridge02[32] . . . 39 4.3 Circumvention system architecture ...... 39 4.4 Traffic routing path ...... 40 4.5 Work flow of the SOCKS5 protocol ...... 42 4.6 Bootstrapping of a peer-to-peer system ...... 43 4.7 Challenge response mechanism ...... 45 4.8 A malicious server node ...... 45 4.9 Trustchain protocol[20] ...... 47 4.10 Intel SGX Remote attestation[19] ...... 49 4.11 Intel SGX Remote attestation full work flown[19] ...... 50 4.12 A 2-hop onion routing circuit ...... 52 4.13 The class UML diagram of Multiproxy ...... 53 4.14 Components and work flow of MultiProxy ...... 54 4.15 Packet structure ...... 54 4.16 Build a 2-hop circuit[37] ...... 56

5.1 Premium networking topology of Google Cloud instances[21] . . 60 5.2 Latency with different hop length ...... 62 5.3 Latency measurement ...... 63 5.4 Throughput measurement ...... 64 5.5 CPU usage (%) ...... 65 5.6 Memory usage (MB) ...... 65

1 5.7 Scalability test ...... 66

2 List of Listings

1 Traceroute from uncensored domain ...... 26 2 Traceroute from censored domain ...... 26 3 Packet capture example of TCP connection reset over HTTP protocol 28 4 Packet capture example of TCP connection reset over HTTP protocol during a certain period ...... 29 5 Packet capture example over TCP ...... 30 6 Packet capture example over UDP ...... 32

List of Tables

3.1 Poisoned IP addresses ...... 34 3.2 The proportion of poisoned domain names ...... 35 3.3 The number of domains affected by each blocking mechanism . . 36

4.1 The IP addresses of meek server ...... 38 4.2 MultiProxy system components ...... 41

5.1 Evaluation framework ...... 57

3 4 Chapter 1

Introduction

This chapter gives the background of the censorship. Censorship can occur in various types of media for a variety of reasons, such as politics, religions, copy approval, etc. This thesis does not focus on the root cause of censorship. Instead, it emphasizes the technical aspects of Internet censorship. Since different countries have different implementations of the censorship systems, this work takes the country-wide content monitoring system, the GFW as a case study. Section 1.1 introduces the brief history of the Great Firewall of China (GFW). Following this, a short introduction of different circumvention methods and systems are presented in section 1.2. Section 1.3 outlines the thesis structure.

1.1 A brief history of the GFW

The censorship already exists for many years according to different rules and regulations as the Internet has become a common communication platform. Take the most famous example: The GFW, also known as the Great Firewall of China, is the most extensive and sophisticated country-wide Internet censoring and monitoring system around the world. It is a combination of the hardware and software which aims at distinguishing and blocking the network traffic in the particular blacklist. This undesired web content contains search engines, e.g., Google and DuckDuckGo, social media and social networking websites, e.g., Twitter, Face- book, Instagram, YouTube, etc. The GFW uses multiple techniques and modules to prevent the citizens from accessing the blocked contents. In the last few decades, most application layer protocols such as HTTP and DNS are directly used based on the transport layer protocols, e.g., TCP and UDP. Although these application protocols provide the standard ways of transferring resources, they are vulnerable to man-in-the-middle attacks because of their insuf- ficient considerations of security. All the network traffic is in plain text between

5 the source and the destination. The lack of security gives the GFW a chance to detect the contents inside the specific protocols. In the early years from 2002[41], the GFW starts developing the keyword filtering system to block the access to selected target websites including some search engines and social media websites which can spread a massive amount of information. The main techniques including HTTP keyword detection, TCP connection reset, DNS hijacking, and DNS poisoning. Some simple TCP and HTTP proxies do not work because of these techniques. The GFW also use IP address blocking to prevent netizens from accessing the poisoned websites by its correct IP addresses. Later, some censorship circumvention tools are developed to evade Internet surveillance, e.g., the VPN and proxies, e.g., HTTP proxy and HTTPS proxy. There are also some hidden services, and anonymous peer-to-peer communication systems are developed, e.g., the Tor Project. After a long period of the arms race between the GFW and censorship circumvention systems, the GFW starts to blocking and filtering the specific network traffic, e.g., the SSH protocol and the Open- VPN protocol. Furthermore, once the circumvention services are detected, these service providers such as cloud instances are IP-blocked by the GFW. In addition to that, the GFW has abilities to discover the hidden circumvention services. Ensafi et al.[11] discover that the GFW using the probing mechanisms such as sending the random binary data in every 15 minutes to detect and blocks Tor’s bridges. In recent years, the GFW starts to adopt the HTTPS certificate detection and Server Name Indication (SNI) detection against the HTTPS traffic to the blocked websites, but it has not been used on a large scale[41]. The reason that mechanisms works are because the target server addresses can still be identified inside the messages. Although the GFW can block harmful websites and restrict the spread of violent and criminal information, some profitable and useful sites are also blocked. There are some replacements of these blocked websites, for example, China has its search engine called Baidu, but it is not very accurate at searching the Foreign news, and literature. Therefore the existence of the GFW builds up a barrier for netizens in the censored domain to use the legal service to a certain extent.

1.2 The categories of circumvention systems

There are some censorship circumvention systems aim at helping people inside the censored domain retrieve legal and useful information from the blocked websites. Most systems are client-server based architecture. For instance, the VPN solutions, which works at the network layer, the practical applications including OpenVPN and OpenConnect. Another is the proxies work on the transport layer, the popular

6 applications including the Shadowsocks and V2Ray. The client-server systems have the intuitive, simple structure and easy to deploy and use, but the drawback is obvious, all clients rely on the existence of the servers, once the servers are taken down by the GFW, the solution is to buy and conﬁgure another cloud instance to set up a server. Another disadvantage is that if the server nodes are malicious, privacy and security during the browsing process is hard to guarantee. Another kind of the systems is the anonymous communication systems which make use of the onion routing[33] to build a secure data tunnel in between, e.g., the Tor Project. Compared to the client-server based systems, this kind of systems can avoid the single point of failure, since if the GFW blocks one network circuit, the systems can change to other tunnels. In addition to that, the systems can also prevent the identity and privacy of the request originators, because of the nodes in the circuit act as the trafﬁc forwarders, and has the limited range of knowledge, such as only know the identities of previous and next nodes. The exit nodes, as the last hop of the Tor network, will decrypt the messages and act as the client to build the connection between the target websites. The location and number of exit nodes is the key point of these systems. In order to achieve high performance such as low latency and high throughput, the system needs to balance the number of service consumers and service providers. The bridges and exit nodes of Tor are set up by volunteers, and it does not have the solutions for this problem so far.

1.3 Thesis Structure

The goal of the thesis is to undertake a recent study to measure the behavior of GFW. Furthermore, the threat model of the GFW is created after measuring its actual behaviors, to design, develop and evaluate a systematic approach to evade the censorship. This thesis introduces the MultiProxy, a peer-to-peer based proxy system for privacy web accessing. Compared to the current proxy or VPN client- server based systems, the design concepts of the MultiProxy exploits the resources of a group of nodes. It has three major functionalities. First, it aims at providing the basic circumvention services, and the trafﬁc can be forwarded through different nodes. Second, the system introduces the token economy, which means everyone participates in the network needs to pay or earn tokens according to their identities. Therefore, MultiProxy can balance the number of consumers and circumvention service providers. Compared to Tor’s free use of bridges and exit nodes, the Multi- Proxy can build a robust and healthy environment for users to achieve low latency and high throughput. The system also takes advantage of onion routing for privacy consideration of the request originators. The MultiProxy selects a group of can- didates nodes to build tunnels for transmitting data between the originators and the target websites. This thesis has four major parts. The research questions are given in the Chapter 2, and to have a basic understanding of the censorship techniques, this chapter

7 also aims at giving some background of the GFW and Censorship resistance system (CRS) including the different methods and architectures from the literature. Chapter 3 will give a comprehensive measurement of the GFW and look into how censorship in China works, e.g., the phenomenal and operating principle behind the different blocking methods, and the threat model of the GFW is given. Chapter 4 is to design and implement a novel system called MultiProxy to circumvent the censorship, based on the gained insights. The evaluation and improvement is in the Chapter 5. Finally, the conclusion and future works are described in Chapter 6.

8 Chapter 2

Problem description

Section 2.1 describes five research questions the thesis aims to solve. The primary content blocking techniques and the anti-censorship methods are summarized. Before the experiment steps, a comprehensive literature survey about censorship and anti-censorship methods is conducted. Nearly 60 papers are selected and classified into different categories, and the results are summarized in the section 2.2 to 2.5. The definition of Internet censorship is given in section 2.2. The analysis and blocking mechanisms are discussed in section 2.3. In section 2.4, the different obfuscation methods which are adopted by censorship circumvention systems are presented. The peer-to-peer architecture is discussed in section 2.5.

2.1 Research Questions

The goal of the thesis is to provide an efficient and robust way for people inside the censored domain to retrieve useful legal information. To achieve this, the following five research questions need to be addressed: • What are the current content blocking techniques? • What are the current anti-censorship methods? • How can an effective way for evading censorship be developed? • How can the performance and effectiveness of censorship evasion systems be evaluated? • What are the lessons and recommendations for circumvention? The first two questions aim at investigating the current content blocking techniques and anti-censorship techniques. The following two questions focused on

9 design and evaluate efﬁcient censorship systems. The recommendations for cir- cumventions are given in the last chapter.

2.2 Internet Censorship

In order to solve the first question, the definition of the censorship needs to be clarified. The communication model of client and server is shown in Figure 2.1, Internet censorship can take place in TCP/IP stack of both endpoints as well as in path between them. Thus censorship can be classified into client-side censorship, server-side censorship, in-path censorship and on-path censorship.

Figure 2.1: An overview of censorship system

2.2.1 Client-side censorship

Client-side censorship means users can only retrieve a limited size of resources due to built-in functionalities in the censorship applications, such as the network ﬁlters. These applications(e.g., TOM-Skype, Sina-UC, LINE, Green Dam) can disrupt the normal connections in many ways, for example, by showing wrong results when the user triggers some sensitive words or URLs in the blacklist or disallowing software installation. The general methods to measure client-side censorship include building sensitive keyword lists or reverse engineering the application.

10 2.2.2 Server-side censorship

In the server-side implementation, the rules are run in the remote server, which can be selectively removed, hide or block access to specific content according to regulations. Similar to client-side censorship detection, researchers try to build a list of content as testing samples, send these samples to servers and record whether these contents are blocked. Zhu et al.[47] find that Weibo, a China’s Twitter-like service, delete most sensitive posts within a day by using retrospective keyword- based mechanism. Similarly, Wechat, the dominant chat application in China, also apply keyword and URL filtering in one-to-one chat as well as group chat. Users will receive warning notifications when they trigger sensitive words1.

2.2.3 In-path censorship

Despite client-side and server-side censorship, the censors can also take control over the communication channel, such as control several routers inside the network and inject false routing information so that those routers can discard or forward the packets to wrong places.

2.2.4 On-path censorship

The censor deploys some devices besides the international gateway to monitor or interrupt the network trafﬁc, for research purpose, these devices such as NIDS(Network intrusion detection system) can perform a huge amount of analysis by making copies of the packets within the network communication channel. These systems have capabilities to read inside the as well as inject additional information to packets.

2.3 Analysis and Blocking Mechanisms

Figure 2.2: A general censorship model

1https://phys.org/news/2016-12-app-china-censorship.html

11 The research only focus on the behaviors of adversaries appeared between the client and server, more specifically, the GFW, China’s national level filtering system. The GFW uses various technical methods to disrupt the connections between censored regions and uncensored regions, including filtering, interference, tamper- ing, and surveillance. There are two main categories of censorship, in-path censorship, and on-path censorship. The general censorship model is shown in figure 2.2, the GFW takes network traffic such as IP packets as the input, then analyzes them by a set of previously determined rules, the output of such analysis will be the input of cost function and decision function. Finally, the system decides whether the traffic is blocked or forward to the destination. The model is the most general one that can be applied to any censorship systems, the GFW is more sophisticated, but it is hard to make an assumption since the opaque of censorship infrastructure. One way to solve this is to read the literature or publications written by the GFW’s designers or predefine a set of testing samples to define which kind of methods the GFW use.

2.3.1 In-path censorship

Analysis approach

In-path censorship relies on stream-level analysis[15], which is based on a 3-tuple of source IP address, destination IP address and protocol. It is effective and much simpler compared to ﬂow-level analysis since it only looks into IP headers and checks whether the destination IP address is legitimate.

Decision approach

IP blocking is one of the earliest methods deployed by the GFW. It takes place in the network layer. A trivial solution is to maintain an Access Control List (ACL) of blocked websites on gateway routers. When packets pass through the router, the router first compares the destination IP addresses with ACL, then performs a series of actions, that is, either forwards the packets or silently discards them. Although this solution is simple and straightforward, it is not effective for backbone network which needs to handle the huge amount of network traffic, especially when there is a large number of IP addresses in ACL since this operation takes additional time to match the destination IP address. In addition to that, since routers have relatively small memory size, they are not suitable for storing the huge number of IP addresses. Liu et al.[27] propose a lightweight control method based on routing diffusion for the large-scale network, also called Border Gateway Protocol (BGP) hijacking. In this method, the GFW injects the wrong static routing information such as a manually-configured routing entry to a gateway router, this router then peers with all gateway routers with the wrong routing information by using BGP

12 and Open Shortest Path First (OSPF) redistribution. Consequently, wrong information is propagated to all routers inside the censored domain, which means the GFW hijacks all traffic trying to access blocked websites in Autonomous system (AS), this traffic will be either lost in transit or redirect to traffic analyzers. IP blocking has two limitations. First, the effects of IP address blocking relies on the accuracy of routing information, and it needs to be carefully maintained and updated. The other limitation is that users can easily circumvent the censorship by using proxies outside the censored domain. IP blacklisting can be combined with port blocking, e.g., selectively close the services on the server by checking and filtering out packets with specific ports, such as port 22 for Secure Shell (SSH), 80 for Hypertext Transfer Protocol (HTTP), 443 for Hypertext Transfer Protocol Secure (HTTPS).

2.3.2 On-path censorship

Since IP blocking can be easily solved by using proxy methods, and the maintain- ing of an accurate ACL list costs a lot. Furthermore, the GFW is not capable of discovering or putting all IP addresses into their blacklist. Due to these drawbacks, the designers start to find alternatives to recognize the network flow which is trying to bypassing the censorship. A good solution is to put traffic analyzers into the network and block sensitive flow according to the content in the transport layer and application layer. In-path system is not suitable for performing the heavy analysis. Otherwise, it will lead to traffic delay and congestion. Instead, the GFW starts to use the on-path system which can handle extremely high throughput. The GFW captures all IP packets from network to its side-channel traffic analyzers, then reassemble those packets according to sequence number inside TCP headers to perform DPI in the application layer. The GFW has its implementation of TCP/IP stack to resynchronize the TCP segments for further analysis. By now it can distinguish many popular protocols such as HTTP and Domain Name System (DNS). They have several flow-level traffic analysis[3] mechanisms which based on a 5-tuple with source IP address, source port, destination IP address, destination port, and the protocol.

Analysis approach

• Port-based classification Port-based traffic analysis is to check the port number inside the TCP header (e.g., port 80 means HTTP traffic). This method is very suitable for classifying massive network traffic by just mapping service on well-known port number, but the accuracy can be very low, in order to prevent services or

13 applications from attack, system administrators open their service on a different port number instead of the default well-known port number, some applications use dynamic port allocation. Moore et al.[30] show that by usage of well-known port number classification methods, a large amount of network traffic being unknown while a small amount of network traffic being misclassified.

• Deep packet inspection

Deep packet inspection is a way to inspecting network traffic flows passing through specific checkpoints to make a real-time decision. With this technology, the GFW can wiretap sensitive keywords inside the packet or suspicious network traffic flow. Unlike the traditional network analysis which only checks the structured information in packet headers, such as IP, TCP, UDP headers, DPI looks into the content of packets, namely the application layer. A common way to acquire network packets for DPI is using port mir- roring, also known as span port, and an optical splitter. DPI can distinguish a bunch of application layer protocols, such as Peer-to-Peer (P2P), VoIP, au- dio/video streaming, it can be considered as an excellent way to identify the real network traffic from packet encapsulation. The main approaches of DPI including payload-based classification and pattern-based classification.

• Payload-based classiﬁcation

Traffic patterns can be identified by payload inside transport layer packets. This method can obtain high accuracy whereas the computational complexity is high. Moore et al.[30] show that by combining the port-based classification and payload-based classification can increase the correctly-identified traffic from approximately 70% to almost 79%. The other disadvantages including invasion of privacy and have not to effect on obfuscated or encrypted network traffic.

• Pattern-based classiﬁcation

This method classifies network traffic flow based on the host behaviors in the transport layer. Compared to port-based and payload-based classification, it only uses connection patterns rather than port and payload. Karagian- nis et al.[22] develop a systematic methodology to identify application layer P2P flow by using peer connection patterns without relying on packet payload. Based on this research, they later came up with a new system called “BLINC”[23] to analyze the traffic pattern from social, functional and application level. The evaluation shows that they can classify 80%-90% of the traffic with more than 95% accuracy. The advantage of this approach is that it can identify network traffic when the payload is encrypted. Furthermore, it reduces the computational complexity concerning payload-based classification. However, this approach is still in the experimental stage since the

14 lack of large dataset, e.g., difficult to identify a new protocol or self-invented protocol. • Machine learning classification The methods mentioned before are some simple filter rules applied to filter suspicious network traffic flow, and machine learning is designed for classifying a sizeable real-time amount of traffic. It combines multiple features and applies the learning algorithms including supervised learning, unsuper- vised learning, and semi-supervised learning to achieve high accuracy. Net- work analyzers usually collect a large number of packets, based on the behaviors of network traffic flow and a set of parameters inside the network packets as features or discriminators, then train a network traffic classifier that can distinguish one type of traffic from another. Yuan et al.[46] propose an accurate network traffic classification based on the SVM method, and the experimental result shows the accuracy achieved more than 97.17%. The advantage of machine learning based network traffic classification is that it works for both unencrypted and encrypted data since it does not rely on the payload of packets. Machine learning network classifying can achieve high accuracy when the suitable features are chosen for a large dataset, but the computational complexity is quite considerable for training an accuracy model, it does not immediately work for new protocols or the situation when some bits inside of the packet are changed in some old network protocols. • Active probing In some special cases, the GFW need to confirm that the server is running prohibit protocols. In this situation, the GFW will establish connections with a suspicious proxy server like a regular client. If the server responds correctly and they successfully establish the connection, the GFW will take block action. The research conducted by Ensafi et al.[11] proves that the GFW using active probing to discover Tor bridges.

Decision approach

After sensitive ﬂows are detected in the transport layer and application layer, the GFW applies multiple block mechanisms, typically TCP connection reset and DNS poisoning: • TCP connection reset TCP connection reset is also known as TCP reset attack. It mainly works on the application layer and the transport layer. The GFW capture all IP packets trying to pass through the international gateway, resynchronize them according to the sequence number. Once sensitive content is detected in the application layer, e.g., sensitive keywords appeared in HTTP GET requests,

15 the GFW inject RST(type-1) and RST/ACK(type2) packets to both client and server to force the on-going connection shut down. Wang et al.[39] evaluate the recent behavior of the GFW, after several tests, they found that the GFW creates TCB depends on both SYN and SYN/ACK packets, and the GFW will enter the resynchronization state in some cases. Xu et al.[45] find that filtering occurs in border gateways and many provincial networks. Perform- ing TCP connection reset is costly since it needs to record the connection state in the TCB, also known as Transmission Control Block, this data structure keeps track of different information about each connection, e.g., local and remote port numbers, sender and receiver buffers, protocols, and current segments. • DNS hijacking and poisoning The Domain Name System is a hierarchical decentralized naming system which maintains a directory of domain names and translates them to IP addresses. DNS spoofing and hijacking work in the Application layer, these techniques are used in conjunction with IP blocking, since one domain name could match several IPs servers, which means the GFW can block several addresses at the same time, but if users enter the correct IP address of domain name, they could still access the destinations. The DNS server is normally provided by Internet Service Provider (ISP). It uses cache to remember these translations for a period. Therefore, it can immediately reply DNS queries until the cache expires. When DNS server has received the fake translation in its caches, it returns an incorrect IP address and delivers the traffic to another server. The GFW usually injects false DNS queries to local DNS servers and also performs intrusion detection in port 53. Once the GFW detects a sensitive query, it immediately injects the DNS reply with a fake IP address. Since the fake address returns much earlier than legitimate one, the DNS server ignores the last arrived one and only forward the false answer to users.

Figure 2.3: DNS hijacking and DNS poisoning

2.4 Obfuscation of censorship circumvention systems

The earliest adopted approach of the censors is only blocking the associated Inter- net Protocol (IP) address and port number of the destination. In order to bypass the

16 censorship, one of the most popular countermeasures is to send requests to a proxy node and let this node send blocked information back. The success of proxy-based censorship resistance systems in practice has result in the censors to deploy advanced Deep packet inspection (DPI) mechanisms which can identify the traffic based on information in application layer as well as network flow behaviors between two endpoints. Based on DPI technology, URL- based keyword filtering can be applied to routers where packets pass through. Con- sequently, the censors can analyze and tamper with the network traffic. As the Deep packet inspection technology is widely used in Internet censorship, most mod- ern censorship resistance systems utilize encryption and obfuscation techniques to evade DPI actions. Those approaches can be classified as four major categories described below: encryption, randomizer, mimicry, and tunneling.

2.4.1 Payload encryption

Conventional encryption can be a relatively good obfuscator to prevent network packet from the censors. Encryption, in this case, means the semantic-based encryption, that is, only the payload of the transport layer is encrypted. For example, the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) header is not encrypted while their payload is encrypted. Although encryption can prevent data from reading by the third party, but only encrypting payload does not guarantee the reliable connections in the whole communication, since most encryption protocols indicate the protocol they used for data transmission in plain text header, this gives censor a chance to detect the exploitable fingerprints from network packets easily. The negotiation of such encryption protocols always have some distinct patterns, which are also obvious to censor, it usually transfer specific messages such as encryption methods or server’s certificates, which can be easily used as fingerprints or signatures by the censor. The famous example is that the GFW can detect sensitive HTTPS network flow and perform TCP reset attack.

2.4.2 Randomizer

Different from encryption, one alternative approach is to randomizing payload by applying a stream cipher to every byte. This approach makes identifying fingerprints difficult because there are no characteristic patterns to observe. Winter et al.[43] propose a thin protocol layer above the transport layer called ScrambleSuit, this protocol is used for application data obfuscation, and the entire network traffic can be indistinguishable by using the pseudo-random payload. The same idea also used by Pluggable Tor Transport Obfsproxy including obfs2, obfs3, and obfs4. obfs2 is an obfuscation layer protocol inside the TCP protocol. The design goal is to prevent the specific communication protocol being recognized by

17 a third party. However, It does not provide authentication and data integrity. The protocols have two phases, (1)establish keys and (2)exchange super enciphered traffic. In its later version, obfs3 offers protection against passive Deep Packet Inspection. This method cannot be detected without launching a probing attack against its handshake. Tor then proposes the obfs4 protocol, which is the combination of ScrambleSuit protocol, elligator2 technique, and ntor protocol. Dust[42] proposed by Wiley et al. is designed for resisting censors deep packet inspection which examining the fingerprints as well as packet payload. The protocol makes itself unobservability and indistinguishable from censors by constructing random packet payloads. Although no visible fingerprint can be detected in the randomizer, “no fingerprint” itself becomes a feature, which means censors can abuse the distinction between conventional protocols’ plain text headers and the randomizing obfuscators. As a result, this kind of applications can be easily detected by simple heuristics, e.g., length checks and entropy-based tests.

2.4.3 Mimicry

Mimicry-based censorship resistant systems are trying to make packet payloads look like allowable packets. Moghaddam et al.[29] propose SkypeMorph, a Tor pluggable transport intended to camouflage the network traffic as a Skype video call between two endpoints. Later, Weinberg et al.[40] design StegoTorus, a pluggable Tor transport forks from Obfsproxy. It split Tor streams across multiple connections and embed the traffic flows that look like HTML, JavaScript, or PDF. Wang et al.[38] propose a new framework for censorship-resistant web browsing called CensorSpoofer, it hides the upstream request contents such as URLs inside the instant messages and emails and downloads the web content from target servers by performing IP spoofing. Burnett et al.[6] design Collage, which allows users embedding request messages inside the user-generated content. For example, the photo-sharing sites. Although mimicry applications are trying to make packet payloads look like standard protocols, it does not use the real implementation of the standard protocol, which means the obfuscator is different from the actual protocols it tries to mimic and can be easily detected by the adversary. For example, researchers find that SkypeMorph and StegoTorus fail even against the weakest censor[16]. Houmansadr et al.[16] show that unobservability by imitation is a fundamentally flawed approach, and partial imitation is worse than no imitation at all. They suggest an alternative, using the original protocol instead of imitating protocol.

2.4.4 Tunneling

Tunneling obfuscators encapsulate the hidden data in higher the protocol stack, which means the application run the actual implementation of protocols to transmit

18 secret data.

Houmansadr et al.[17] propose Freewave, which modulates a client’s network traffic into acoustic signals and put it to VoIP connections target to FreeWave server, the server then extracts the hidden traffic and proxies them to a censored Internet. In the latest paper published in 2017, Houmansadr et al.[18] propose a way called SWEET(Serving the Web by Exploiting Email Tunnels) to hide internet traffic inside Email messages such as Yahoo Mail and Gmail. Barradas et al.[9] build a censorship-resistant system, named DeltaShaper, which tries to carry over standard protocols such as FTP, SMTP, or HTTP through Skype video streams. Lee et al.[25] design, implement and evaluate CovertCast, a censorship circumvention system that encapsulates the blocked traffic into live-streaming services.

Decoy routing

Decoy routing is an example of tunneling. In this approach, a client encapsulates its hidden requests over a proper communication channel to non-blocked destinations. Unlike other proxy-based circumvention techniques, in decoy routing, the client does not directly connect to a blocked IP address to provide circumvention. Instead, a friendly “decoy” router acts as a reflector to intercepts this traffic, extracts the hidden data from packets, and transmits it to the target destinations. Traffic shaping is the essential part of decoy routing systems in order to protect against traffic analysis from censors.

The decoy routing idea is also presented by Karlin et al.[24] They show that the client does not need to explicitly connect to the separate server IP which can be easily blocked by the censors. An alternative way is to use the intermediate circumvention devices which are hard to block by censors to proxying the network traffic. One real-world implementation is Telex which is proposed by Wustrow et al.[44], it converts unblocked websites into proxies, with the help of Telex stations deployed on friendly ISPs between censors’ networks and uncensored Inter- net domains. Telex stations would monitor seemingly network traffic flows and transparently deflect them to the forbidden websites or services instead. Another real-world example TapDance which is implemented by Frolov et al.[14] was deployed on four ISP uplinks with 100 Gbps bandwidth. It serves more than 50,000 real-world users over one week. The result shows that TapDance can be practically operated in ISP scale with good performance and reasonable cost. Bocovich et al.[5] suggest secure asymmetric solutions to previously symmetric decoy routing systems. They later[4] propose Slitheen, which is a secure decoy routing system capable of perfectly imitate the traffic patterns of regular client and web server.

19 Domain fronting

Domain fronting is a special form of decoy routing, but unlike decoy routing, domain fronting works at application layers by using HTTPS. It is easy to deploy and does not need further cooperation with ISP. The key idea is to use different destination addresses at different network layers. It shows the allowable address as the front domain which is outside of the HTTPS request, in the DNS query, and Server Name Indication (SNI) when establishing the Transport Layer Security (TLS) connections, but the Host field inside the HTTP header is the real address client want to visit, and this part is invisible to censor. Since the censors cannot distinguish the front address and the real address behind the HTTPS encryption, it will let the traffic pass through unless censor blocks the entire domain which may cause great collateral damage. Domain fronting has now implemented in various practical software, e.g., Meek, which is the domain fronting tor pluggable transport. Fifield et al.[12] deploy various censorship circumvention applications including Tor, Lantern, and Psiphon for several months, and the experience demonstrates that these systems can serve thousands of users with transferring huge amount of data per month. The result shows that domain fronting now becomes a circumvention workhorse.

Challenges

There are two main challenges in tunneling, the first is the semantic mismatch between real protocol and tunneled data, which may cause the drop of the packet while transmitting the hidden data, e.g., tunnel too large packets through the network. The second is that censors can run algorithms like entropy tests to identify the tunneled data from regular data. Researchers in China find the different patterns between normal https traffic and meek traffic by measuring packet interval and packet size distribution. The results show that the anonymous communication system is not unobservable.

2.5 P2P architecture - Build a trust network to overcome censorship

The primary goal of Tor is to ensure anonymity. It uses peer-to-peer proxying to reroute the network traffic by releasing the default bridges inside the tor browser and bridge list file (a configuration file) with all the bridges on it. One disadvantage is that the censors can also join this network and block all those IPs. Fifield et al.[13] examine the average time that censors take to block the Tor bridges. They found the bridges reachability varies and the blocking techniques advance during the measurement.

20 Based on the failure of Tor bridges, a fair proportion of systems aim to leverage a trust network to resist the censors, namely prevent it from Sybil attack, which means such architecture should limit the number of malicious nodes. The practical applications including uProxy and Lantern. A variety of research works propose the peer-to-peer architecture censorship circumvention systems. Sovran et al.[35] design, implement and evaluate the Kal- eidoscope which purposes the limited discovery protocol to prevent the censors from joining the network. The same idea is used in Salmon, presented by Douglas et al.[10], which deﬁnes an algorithm that can quickly identify malicious users from the network. Lee et al.[25] design the OverTorrent, which allows sharing Internet connections between using BitTorrent protocol. Shen et al.[34] propose Freeweb, which relies on a network of widely distributed peer-to-peer (P2P) nodes, and on that basis, they improve the ﬁle access delay and reduce the node overload problem. Previous works are elaborating on the network structures and node cooperation algorithms, and assume that the number of nodes is enough for constructing a P2P network. In the real world, the nodes which are accessible and can provide the circumvention services is crucial for a circumvention system, and the requesters or client nodes cannot access the blocked content without the forwarding of these nodes. To incentivize the number of service providers, this work also focuses on how to build a balanced P2P network by utilizing a blockchain-based economical model.

21 22 Chapter 3

Empirical evaluation of the GFW

In chapter 2, some results from the literature are summarized, but the actual behaviors of the GFW still need to be measured to understand the technical principles behind. This chapter describes the basic situation of the GFW. Section 3.1 introduces the experimental setups of the GFW measurement. Section 3.2 describes how IP blocking methods works. The GFW uses TCP connection reset to disrupt the normal network trafﬁcs to blocked websites, these detecting methods including DNS and HTTP keyword detections are explained in section 3.3. Section 3.4 shows how the GFW intercepts DNS resolution over UDP protocol by using DNS hijacking and DNS poisoning. By measuring the different root causes that make accessing unavailable, the number of websites that are blocked by different mechanisms is counted up. Finally, the measurement results and the threat model of the GFW is given in section 3.5. The contributions of this chapter including:

• A taxonomy of the behaviors of the GFW and build a threat model.

• A categorization of the root causes that make websites unavailable as a guide for circumventing the censorship.

3.1 Experimental Setup

An open source the GFW blacklist hosted on Github1 is chosen for designing a reasonable measurement experiment and constructing a threat model of the GFW. This list contains almost all the blocked websites reported by the netizens, and it is frequently updated and carefully maintained by a group of volunteers since Feb 22, 2009. Due to the opaqueness of the GFW, the ﬁle cannot fully record all blocked domain names but most of them. In general, volunteers manually access

1https://github.com/gfwlist/gfwlist/blob/master/gfwlist.txt

23 websites or using scripts to check availability before creating issues in the reposit- ory. The issues are carefully tested by administrators to ensure correctness. These domain names on the list can be blocked by the GFW using various techniques, e.g., IP blocking or intrusion detection techniques including TCP connection reset and DNS hijacking/DNS cache poisoning. Figure 3.1 shows the measurement pipeline for processing the GFW list. Al- though the latest version which updated on Jun 30, 2018, is used, it may contain some outdated information. For example, some servers may change their address records on DNS server, or the GFW no longer blocking part of domains in the period. In the first step, the list is filtered by URLs, IP addresses and comments, and there are 6170 unique Fully Qualified Domain Name (FQDN) in total. The invalid domain names are removed in the next step. Finally, the 4265 valid domains are used for the categorization. The next step is to find out the behaviors of the GFW and get the distribution of websites affected by IP blocking, TCP connection reset and DNS hijacking/cache poisoning. With regard to estimate IP blocking and TCP connection reset proportion of poisoned domain names, a list of correct IP addresses is derived outside the censored domain, and then they are categorized by a command-line tool curl. Some servers use the name-based virtual host, which means there are multiple domain names on the same IP address. Therefore, the Host field is constructed within the HTTP header to ensure that the client can connect to the website correctly. In order to distinguish all these cases, i.e., the proportion of websites affected by these techniques separately, a bunch of command line tools are used to construct the requests and perform traffic analysis, including curl, dig, traceroute and tcpdump. curl is exploited to construct HTTP/HTTPS requests over TCP protocol in IP blocking and TCP reset measurements. Traceroute is used for sending the Internet Control Message Protocol (ICMP) packets to trace the path between client and server. dig is utilized in DNS experiment in order to get address resolutions of domain names. tcpdump is used for client-side traffic analysis to find patterns of the GFW operating mechanisms.

3.2 IP blocking

IP blocking is one of the earliest methods adopted by the GFW due to its simplicity and directness. It works on the network layer. Once a packet passes through the Internet backbone and is ready to send to the Internet, the in-path blocking system matches the destination IP address in IP header with its blacklist. If it matches, then packets are dropped or filtered. There is no way to evade IP blocking mechanism unless the destination address field is filled with an unblocked IP address.

24 GFWList

Valid domains Invalid domains

dig with TCP

Poisoned domains Correctly resolved doamins

Get real IP addresses

Check curl return code

7 28 56

Server-side failure IP blocked TCP connection reset

Figure 3.1: Experimental pipeline for categorizing different root causes

During the traffic analysis, the application continuously sends the same packets since there is no reply from the other side. For instance, the host sends SYN packets repeatedly since it receives no response in the TCP connection. Figure 3.2 shows the IP blocking mechanism. The reason behind is that IP packets are lost in the middle. Either are dropped or filtered by in-path devices and never get to the server. Therefore, the server will not give a reply to the client. Listing 2 shows the traceroute path between the uncensored domain and one IP address of www.google.com. Listing 1 shows the traceroute result queried from the censored domain. In the first snippet, packets successfully reach the destination, which means the server-side does not block the ICMP packets while from the second res-

Censored Domain Filtered

IP packets

Client GFW Web Server

Figure 3.2: IP blocking

Censored Domain 25 TCP Segment

RST/ACK RST/ACK

Client Keywords Detected Web Server

GFW

Censored Domain

DNS Query

Forged DNS Reply Correct DNS Reply Client Keywords Detected Web Server

GFW

Censored Domain

DNS Query DNS Query

Forged DNS Reply Forged DNS Reply Correct DNS Reply Keywords Detected Client Ali DNS Web Server Poisoned Cache

GFW

Censored Domain

1.DNS Query 2.DNS Query

3.RST/ACK 4.DNS Response Client GFW Google Public DNS

Censored Domain

1.DNS Query 2.DNS Query

3.Wrong Response 4.DNS Response Client GFW Google Public DNS

Censored Domain

1.DNS Query 2.DNS Query 3.DNS Query

4.Wrong Response 3.RST/ACK 5.DNS Response Client Ali DNS GFW Root DNS

Censored Domain

1.DNS Query 2.DNS Query 3.DNS Query

6.Wrong Response 4.Wrong Response 5.DNS Response Client Ali DNS GFW Root DNS ult, packets stop forwarding after they reach the router 119.147.219.241, which belongs to China Telecom from AS4816, one of the Chinese backbone networks.

$ traceroute -n 216.58.211.100 traceroute to 216.58.211.100 (216.58.211.100), 64 hops max, 52 byte packets 1 145.94.160.2 2.483 ms 1.272 ms 7.041 ms 2 10.200.23.58 1.112 ms 1.121 ms 1.156 ms 3 10.200.246.121 1.269 ms 1.160 ms 1.147 ms 4 10.200.246.5 1.439 ms 1.153 ms 1.181 ms 5 10.200.24.5 1.385 ms 1.283 ms 1.287 ms 6 145.145.26.97 2.792 ms 4.937 ms 4.145 ms 7 145.145.166.86 3.026 ms 2.910 ms 2.788 ms 8 108.170.241.161 4.056 ms 108.170.241.129 2.997 ms 108.170.241.161 4.022 ms 9 108.170.237.45 3.070 ms 3.379 ms 2.808 ms 10 216.58.211.100 2.804 ms 3.064 ms 2.965 ms

Listing 1: Traceroute from uncensored domain

$ traceroute -n 216.58.211.100 traceroute to 216.58.211.100 (216.58.211.100), 30 hops max, 60 byte packets 1 *** 2 11.212.252.65 5.862 ms 6.276 ms 6.484 ms 3 11.218.131.97 5.384 ms 11.218.131.173 4.878 ms 11.218.131.149 5.013 ms 4 11.218.131.246 1.081 ms 1.116 ms 11.218.131.234 1.078 ms 5 119.38.212.110 2.434 ms 119.38.212.102 1.416 ms 119.38.212.114 2.260 ms 6 116.251.113.137 1.381 ms 42.120.242.217 2.470 ms 116.251.113.141 1.451 ms 7 183.2.180.229 1.898 ms 183.2.180.93 1.909 ms 183.2.180.217 1.574 ms 8 183.2.182.117 2.552 ms 183.2.182.125 2.157 ms 183.2.182.129 2.589 ms 9 119.147.219.241 5.912 ms 119.147.222.13 10.056 ms 119.147.220.41 12.080 ms 10 *** 11 *** ...

Listing 2: Traceroute from censored domain

The GFW has a list of blocked IP addresses and IP addresses range. It is too large for us to match all IP addresses. Command line tool ping is to test the reachability between two nodes over a network layer, but considering that ping achieves its purpose by constructing ICMP packets, and some firewalls on the server side might block the access of ICMP packets for security reasons. These scripts are designed by the command line tool curl. curl supports a set of application layer protocols, e.g., FTP, HTTP and HTTPS. In the experiment, the packets need to be sent to available ports. Available means ports are opened and not filtered by the firewall on the server side. Explicitly, port 80(HTTP) is allowed by most servers. Therefore, the HTTP protocol is used to trigger the GFW. curl is a convenient tool since it can return both the results and status code, e.g., the status code is 0 if connection success). Checking different status code can detect network connection problems. For example, the status code 7 and 28 indicates that someone in path intercepts the normal traffic. Status code 7 means curl failed to establish TCP connection to the host. The reason can be specified wrong port numbers, wrong hostnames, or firewalls exists in the path. Status code 28 means the connection reaches the specified timeout period. In the script, the maximum time to connect to a website is ten seconds. The way to distinguish several situations in status code 7 is executing the scripts multiple times in clients both inside and outside the censored domain. The result shows that there are 498 valid domains’ IP addresses are blocked by the

26 GFW.

3.3 TCP connection reset

TCP(Transmission Control Protocol) is a reliable communication protocol in the transport layer. It provides multiple mechanisms such as error detection, flow control, congestion control, and retransmission. However, it is not designed for securely transmitting data between two nodes, i.e., TCP protocol does not provide the confidentialityCensored Domain of payload and authenticationFiltered of two nodes’ identities. So TCP connections can be easilyIP intercepted packets or tampered with attackers. There are various approaches to interrupt the TCP connection, e.g., TCP reset attack, SYN flooding attack, and TCP session hijacking attack. A simple way to break the existing con- Client nection between client and server is TCP connectionGFW reset. Two differentWeb Server situations which can trigger TCP connection resets are explored in this section.

Censored Domain

TCP Segment

RST/ACK RST/ACK

Client Keywords Detected Web Server

GFW

Figure 3.3: TCP connection reset

The curl return status code 56 means the domain triggers TCP reset attack. The exit code is 35Censored if there Domain is any TLS/SSL connection error. As for destination website, it is affected by the TCP connection reset with only one IP are used in pattern DNS Query measurement experiment to minimize the impact of Time to Live (TTL) ﬁeld inside the IP header. In the typicalForged situation, DNS Reply a single serverCorrect DNS always Reply communicates with Client Keywords Detected the client with the same TTL value. It can be easily detected ifW theeb Server GFW disrupts the connection since the GFW construct packets with random TTL values.

3.3.1 HTTP keywords detection GFW

According to the traffic analysis in Listing 3, when the client first connects to a blocked website,Censored the Domain connection is intercepted by the GFW after client and server successfully made three-way handshake and client pushes the sensitive request, in this case, mail-archive.comDNS appeared Query in HTTP Host headerDNS Query field. The GFW disrupts the connection by sendingForged DNS oneReply RST packet followedForged by DNS three Reply same RST/ACKCorrect DNS Reply Keywords Detected packets. The trueClient acknowledgment comes later and is ignored by the client. Ali DNS Web Server Poisoned Cache 27

GFW

Censored Domain

1.DNS Query 2.DNS Query

3.RST/ACK 4.DNS Response Client GFW Google Public DNS

Censored Domain

1.DNS Query 2.DNS Query

3.Wrong Response 4.DNS Response Client GFW Google Public DNS

Censored Domain

1.DNS Query 2.DNS Query 3.DNS Query

4.Wrong Response 3.RST/ACK 5.DNS Response Client Ali DNS GFW Root DNS

Censored Domain

1.DNS Query 2.DNS Query 3.DNS Query

6.Wrong Response 4.Wrong Response 5.DNS Response Client Ali DNS GFW Root DNS Listing 4 shows how the GFW works if the client connects to the website again in a certain period of time, after the client sends out the SYN packet, the GFW immediately impersonates itself as the server and sends an SYN/ACK packet, which causes the client to send successive packets to the GFW. The GFW can now send back an RST/ACK packet and an RST packet to notify the client the connection is terminated. The SYN/ACK packet from the real server arrives after the client has already closed the connection. This result shows that the GFW is stateful, since it can remember the connection states of the client and server in a period of time. The time maintains from the 90s to 95s, and when the time expired, the GFW lose the old connection state and sends the reset packet again after the client and blocked websites ﬁnishes three-way handshake.

00:00:00.000000 IP (tos 0x0, ttl 64, id 38830, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.117.49576 > 72.52.77.8.http: Flags [S], cksum 0x5788 (incorrect -> 0xd21f), seq ,→ 2636432921, win 29200, options [mss 1460,sackOK,TS val 898126263 ecr 0,nop,wscale 7], ,→ length 0 00:00:00.167822 IP (tos 0x14, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 60) 72.52.77.8.http > 192.168.1.117.49576: Flags [S.], cksum 0xce77 (correct), seq 2021363056, ack ,→ 2636432922, win 28960, options [mss 1460,sackOK,TS val 4038397413 ecr 898126263,nop,wscale ,→ 7], length 0 00:00:00.167858 IP (tos 0x0, ttl 64, id 38831, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.117.49576 > 72.52.77.8.http: Flags [.], cksum 0x5780 (incorrect -> 0x6cd7), ack 1, ,→ win 229, options [nop,nop,TS val 898126431 ecr 4038397413], length 0 00:00:00.167955 IP (tos 0x0, ttl 64, id 38832, offset 0, flags [DF], proto TCP (6), length 133) 192.168.1.117.49576 > 72.52.77.8.http: Flags [P.], cksum 0x57d1 (incorrect -> 0x3c39), seq ,→ 1:82, ack 1, win 229, options [nop,nop,TS val 898126431 ecr 4038397413], length 81: HTTP, ,→ length: 81 HEAD / HTTP/1.1 User-Agent: curl/7.29.0 Host: mail-archive.com Accept: */*

00:00:00.173402 IP (tos 0x14, ttl 61, id 0, offset 0, flags [none], proto TCP (6), length 40) 72.52.77.8.http > 192.168.1.117.49576: Flags [R], cksum 0x5bff (correct), seq 2021363057, win ,→ 13474, length 0 00:00:00.174417 IP (tos 0x14, ttl 97, id 6299, offset 0, flags [DF], proto TCP (6), length 40) 72.52.77.8.http > 192.168.1.117.49576: Flags [R.], cksum 0x19f9 (correct), seq 1, ack 82, win ,→ 4872, length 0 00:00:00.174436 IP (tos 0x14, ttl 97, id 6299, offset 0, flags [DF], proto TCP (6), length 40) 72.52.77.8.http > 192.168.1.117.49576: Flags [R.], cksum 0x19f9 (correct), seq 1, ack 82, win ,→ 4872, length 0 00:00:00.174458 IP (tos 0x14, ttl 97, id 6299, offset 0, flags [DF], proto TCP (6), length 40) 72.52.77.8.http > 192.168.1.117.49576: Flags [R.], cksum 0x19f9 (correct), seq 1, ack 82, win ,→ 4872, length 0 00:00:00.335710 IP (tos 0x14, ttl 49, id 55300, offset 0, flags [DF], proto TCP (6), length 52) 72.52.77.8.http > 192.168.1.117.49576: Flags [.], cksum 0x6be0 (correct), ack 82, win 227, ,→ options [nop,nop,TS val 4038397581 ecr 898126431], length 0 00:00:00.335734 IP (tos 0x14, ttl 64, id 18607, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.117.49576 > 72.52.77.8.http: Flags [R], cksum 0x32fe (correct), seq 2636433003, win ,→ 0, length 0

This listing shows the GFW sends one RST packet followed by three RST/ACK packets to terminate the connection between client and server after detecting the keywords inside Host ﬁled and URL. The bogus packets send by the GFW is colored in red. Listing 3: Packet capture example of TCP connection reset over HTTP protocol

3.3.2 DNS keywords detection

DNS(Domain Name System) is typically a hierarchical decentralized system that maps domain names to IP addresses. Querying DNS server is the ﬁrst step after users input domain name in the address bar and hit enter. The DNS protocol sup-

28 00:00:03.732147 IP (tos 0x0, ttl 64, id 43057, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.117.48636 > 72.52.77.8.http: Flags [S], cksum 0x5788 (incorrect -> 0xb244), seq ,→ 2201214804, win 29200, options [mss 1460,sackOK,TS val 873953125 ecr 0,nop,wscale 7], ,→ length 0 00:00:03.739782 IP (tos 0x14, ttl 67, id 36317, offset 0, flags [DF], proto TCP (6), length 40) 72.52.77.8.http > 192.168.1.117.48636: Flags [S.], cksum 0x4ef6 (correct), seq 41278637, ack ,→ 2201214805, win 2442, length 0 00:00:03.739808 IP (tos 0x0, ttl 64, id 43058, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.117.48636 > 72.52.77.8.http: Flags [.], cksum 0x5774 (incorrect -> 0xe670), ack 1, ,→ win 29200, length 0 00:00:03.739961 IP (tos 0x0, ttl 64, id 43059, offset 0, flags [DF], proto TCP (6), length 121) 192.168.1.117.48636 > 72.52.77.8.http: Flags [P.], cksum 0x57c5 (incorrect -> 0xb5d2), seq ,→ 1:82, ack 1, win 29200, length 81: HTTP, length: 81 HEAD / HTTP/1.1 User-Agent: curl/7.29.0 Host: mail-archive.com Accept: */*

00:00:03.745413 IP (tos 0x14, ttl 54, id 0, offset 0, flags [none], proto TCP (6), length 40) 72.52.77.8.http > 192.168.1.117.48636: Flags [R], cksum 0x76c0 (correct), seq 41278638, win ,→ 17494, length 0 00:00:03.746091 IP (tos 0x14, ttl 68, id 35307, offset 0, flags [DF], proto TCP (6), length 40) 72.52.77.8.http > 192.168.1.117.48636: Flags [R.], cksum 0x4ef2 (correct), seq 1, ack 1, win ,→ 2443, length 0 00:00:03.893600 IP (tos 0x14, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 60) 72.52.77.8.http > 192.168.1.117.48636: Flags [S.], cksum 0x0e1b (correct), seq 521495779, ack ,→ 2201214805, win 28960, options [mss 1460,sackOK,TS val 4014223819 ecr 873953125,nop,wscale ,→ 7], length 0 00:00:03.893643 IP (tos 0x14, ttl 64, id 45705, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.117.48636 > 72.52.77.8.http: Flags [R], cksum 0x37b1 (correct), seq 2201214805, win ,→ 0, length 0

The GFW will record each TCP connection state between 90 and 95 seconds. During this period, every SYN packet sends by the client is replied to with a fake SYN/ACK packet. The identities can be distinguished from the TTL value inside the IP header. The GFW hijacks the three-way handshake and sends an RST packet followed by an RST/ACK packet to terminate the connection. The SYN/ACK sent by real server arrived later but then ignored by the client. The bogus packets send by the GFW is colored in red. Listing 4: Packet capture example of TCP connection reset over HTTP protocol during a certain period ports communication over both the TCP and UDP protocol, but it does not provide confidentiality in data transmission since the payload is sent in plain text during the transmission. Due to this feature, the GFW also contains a module to trigger TCP connection reset targeting the DNS protocol. Two Virtual Private Server (VPS) in the censored domain and uncensored domain are deployed to test this mechanism. Two DNS servers are chosen including Google Public DNS which is located outside the censored domain and the Ali DNS located inside the censored domain. The packet capturing tool tcpdump is used for monitoring network traffic to port 53, and the DNS lookup tool dig is to construct DNS queries over TCP. The DNS query is sent over the TCP to Google public DNS 8.8.8.8, and the output shows where the connection is reset. The network traffic shows that after the normal three-way handshake, the host issues a DNS query which contains A? www.google.com to the other side, some devices in middle pretends to be 8.8.8.8 and immediately returns three RST/ACK packets to acknowledge that previous data is sent and then notify the host connection is reset, as shown in Listing 5.

29 The TCP connection is closed by the host, which means there is no such process listening on the previous port. The true ACK packets and buffers which contains the correct resolve address came later from 8.8.8.8 were ignored by the operating system, and the host replies that by the RST packets — noted that one way to distinguish from correct DNS server from a fake one is to check the Time to Live (TTL) ﬁeld. In this case, The correct DNS server has TTL value with 39 while the imposter is 157, TTL value with 64 means the packets are sent from the host.

Listing 5 reveals how the GFW performs the reset attack. It is similar to the TCP connection reset for HTTP keywords detection. The difference is that HTTP detection is stateful since the GFW stores the connection state in their database for a period of time. For DNS protocol, instead, if querying the same domain name repeatedly, the GFW will always return three RST/ACK packets to terminate the connection. This shows for DNS over TCP, the GFW will not record the TCP connection state.

00:00:00.000000 IP (tos 0x0, ttl 64, id 15284, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.117.52458 > 8.8.8.8.domain: Flags [S], cksum 0xd25b (incorrect -> 0xfd94), seq ,→ 2016075502, win 29200, options [mss 1460,sackOK,TS val 4237944154 ecr 0,nop,wscale 7], ,→ length 0 00:00:00.023463 IP (tos 0x14, ttl 39, id 10393, offset 0, flags [none], proto TCP (6), length ,→ 60) 8.8.8.8.domain > 192.168.1.117.52458: Flags [S.], cksum 0x6bfc (correct), seq 3781683001, ack ,→ 2016075503, win 60192, options [mss 1380,sackOK,TS val 1040060966 ecr ,→ 4237944154,nop,wscale 8], length 0 00:00:00.023505 IP (tos 0x0, ttl 64, id 15285, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.117.52458 > 8.8.8.8.domain: Flags [.], cksum 0xd253 (incorrect -> 0x849e), ack 1, ,→ win 229, options [nop,nop,TS val 4237944177 ecr 1040060966], length 0 00:00:00.023721 IP (tos 0x0, ttl 64, id 15286, offset 0, flags [DF], proto TCP (6), length 97) 192.168.1.117.52458 > 8.8.8.8.domain: Flags [P.], cksum 0xd280 (incorrect -> 0xa472), seq ,→ 1:46, ack 1, win 229, options [nop,nop,TS val 4237944177 ecr 1040060966], length 4510227+ ,→ [1au] A? www.google.com. (43) 00:00:00.030778 IP (tos 0x14, ttl 157, id 19375, offset 0, flags [DF], proto TCP (6), length 40) 8.8.8.8.domain > 192.168.1.117.52458: Flags [R.], cksum 0xe209 (correct), seq 1, ack 46, win ,→ 3728, length 0 00:00:00.030781 IP (tos 0x14, ttl 157, id 19375, offset 0, flags [DF], proto TCP (6), length 40) 8.8.8.8.domain > 192.168.1.117.52458: Flags [R.], cksum 0xe209 (correct), seq 1, ack 46, win ,→ 3728, length 0 00:00:00.030817 IP (tos 0x14, ttl 157, id 19375, offset 0, flags [DF], proto TCP (6), length 40) 8.8.8.8.domain > 192.168.1.117.52458: Flags [R.], cksum 0xe209 (correct), seq 1, ack 46, win ,→ 3728, length 0 00:00:00.047164 IP (tos 0x14, ttl 39, id 10403, offset 0, flags [none], proto TCP (6), length ,→ 52) 8.8.8.8.domain > 192.168.1.117.52458: Flags [.], cksum 0x8453 (correct), ack 46, win 236, ,→ options [nop,nop,TS val 1040060989 ecr 4237944177], length 0 00:00:00.047196 IP (tos 0x14, ttl 64, id 37215, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.117.52458 > 8.8.8.8.domain: Flags [R], cksum 0xb94c (correct), seq 2016075548, win ,→ 0, length 0 00:00:00.047757 IP (tos 0x14, ttl 39, id 10404, offset 0, flags [none], proto TCP (6), length ,→ 113) 8.8.8.8.domain > 192.168.1.117.52458: Flags [P.], cksum 0x9a74 (correct), seq 1:62, ack 46, ,→ win 236, options [nop,nop,TS val 1040060990 ecr 4237944177], length 6110227 1/0/1 ,→ www.google.com. A 172.217.27.132 (59) 00:00:00.047764 IP (tos 0x14, ttl 64, id 37216, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.117.52458 > 8.8.8.8.domain: Flags [R], cksum 0xb94c (correct), seq 2016075548, win ,→ 0, length 0

The bogus packets send by the GFW is colored in red. Listing 5: Packet capture example over TCP

30 3.3.3 TCP connection reset module

Figure 3.4 presents how a basic TCP connection reset device[28] works. It contains several pluggable modules. The capturing module collects all the TCP packets from real-time network trafﬁc. The update module updates the connection information stored in the database. In the meanwhile, the decision module decides whether to perform intrusion prevention rules and use the blocking module to construct fake packets after computation before sending to targets.

The behavior of the GFW can be applied to this model. The GFW sits in the path of the international gateway and makes a copy of network packets. The TCP packet capturing module is responsible for capture TCP packets after that the GFW collects connection information including source Media access control (MAC), IP address, TCP port as well as destination MAC address, IP address, TCP port. In addition to that, the GFW also collects sequence number and acknowledge number from request/response packet from both sides to construct a valid packet. Once a client connects to the server, the TCP connection information will be collected or updated, then stored in the database for a certain period. The request censored keywords sent by the client can trigger the blocking module, which will send the command to construct a fake packet according to previous updated connection state, e.g., compute SYN and ACK numbers, switch source and destination addresses. The fake RST or RST/ACK packets are sent to both client and server side in order to break the connection on both sides.

Network trafﬁc

TCP connection reset

TCP packet capturing Filter rules Do nothing Not block

Update connection Block state

Connection state Send fake RST Construct packets storage packets Connection info

Figure 3.4: The model of TCP connection reset device

31 3.4 DNS hijacking and DNS cache poisoning

Censored Domain Filtered

3.4.1 How the GFWIP intercepts packets DNS resolution

This section shows the experiment on how the GFW performs DNS hijacking over Client UDP protocol, as well as DNS poisoning,GFW which is the side effectWeb caused Server by DNS hijacking. DNS hijacking takes advantage of the properties of the UDP protocol. It is known that UDP protocol is unreliable, senders send out the packets and do not require acknowledgments.Censored Domain This allows attackers to send forged DNS replies. The client accepts the injected replies since they arrive earlier than legitimate replies. TCP Segment When sending DNS queries over the UDP protocol, the output of dig does not show any error message. Instead,RST/ACK it returns a typeRST/ACK A records with an IPv4 address Client Keywords Detected shown in Listing 6. This address, however, is invalid because itWeb does Server not point to the real website. Trafﬁc analysis shows that after the host sends the DNS query that contains blocked keywords, some device disguises itself as a destination DNS server and immediately sends two packetsGFW with fake resource records. A few mil- liseconds later, the correct response is ignored by dig as it already used the ﬁrst forged answer. Figure 3.5 shows how DNS hijacking works for TCP and UDP protocol.

Censored Domain

DNS Query

Forged DNS Reply Correct DNS Reply Client Keywords Detected Web Server

GFW

Figure 3.5: DNS hijacking

Censored Domain 00:00:00.000000 IP (tos 0x0, ttl 64, id 26525, offset 0, flags [none], proto UDP (17), length ,→ 71) 192.168.1.117.49964 > 8.8.8.8.domain: 14538+ [1au] A? www.google.com. (43) 00:00:00.005060 IP (tos 0x14,DNS ttl Query 44, id 0, offset 0, flags [none],DNS proto Query UDP (17), length 76) 8.8.8.8.domain > 192.168.1.117.49964: 14538 1/0/0 www.google.com. A 31.13.85.16 (48) 00:00:00.008538 IP (tos 0x14,Forged ttl DNS 103, Reply id 29352, offset 0, flagsForged [DF], DNS proto Reply UDP (17), length Correct DNS Reply ,→ 76) 8.8.8.8.domain > 192.168.1.117.49964: 14538 1/0/0 www.google.com. A 31.13.80.17 (48)Keywords Detected Client 00:00:00.022273 IP (tos 0x14, ttl 39, id 29402, offsetAli DNS 0, flags [none], proto UDP (17), length Web Server ,→ 87) Poisoned Cache 8.8.8.8.domain > 192.168.1.117.49964: 14538 1/0/1 www.google.com. A 216.58.197.100 (59)

The bogus packets send by the GFW is colored in red. GFW Listing 6: Packet capture example over UDP

In general, DNS cache poisoning is more efﬁcient than DNS hijacking, since attackers only attack target once and let the fake resource records stored in DNS

Censored Domain

1.DNS Query 2.DNS Query

3.RST/ACK 4.DNS Response Client GFW Google Public DNS

Censored Domain

1.DNS Query 2.DNS Query

3.Wrong Response 4.DNS Response Client GFW Google Public DNS

Censored Domain

1.DNS Query 2.DNS Query 3.DNS Query

4.Wrong Response 3.RST/ACK 5.DNS Response Client Ali DNS GFW Root DNS

Censored Domain

1.DNS Query 2.DNS Query 3.DNS Query

6.Wrong Response 4.Wrong Response 5.DNS Response Client Ali DNS GFW Root DNS Censored Domain Filtered

IP packets

Client GFW Web Server

Censored Domain

TCP Segment

RST/ACK RST/ACK

Client Keywords Detected Web Server cache for one or two days. Regarding DNS poisoning, the DNS server is changed to Ali DNS server(223.5.5.5 and 223.6.6.6) inside the censored domain, and then GFW a DNS query is sent over TCP and UDP. According to the output of tcpdump, the connection was not intercepted by the third party, but both resource records were incorrect. The reason is that when Ali DNS server tries to perform the recursive Censored Domain DNS query(e.g., send a query to a DNS root server), some devices in between intercept the connectionDNS Query and construct fake packets, which result in the invalid resource record storedForged DNS in Reply Ali DNS cache.Correct DNS Reply Since the GFW can read the content of Client Keywords Detected the packets, the attack is easy to perform as the GFWWeb Server does not need to guess the 16- bit id in DNS packets. It copies the ID from the query and uses the destination DNS server’s address as source addressGFW for the forged response, then sends it back to the user. Figure 3.6 illustrates DNS cache poisoning over TCP and UDP protocol.

Censored Domain

DNS Query DNS Query

Forged DNS Reply Forged DNS Reply Correct DNS Reply Keywords Detected Client Ali DNS Web Server Poisoned Cache

GFW

Figure 3.6: DNS cache poisoning

When performing the same experimental steps outside the censored domain, the GFW’s behavior is the same except all the resource record returned are incorrect due to DNSCensored cache Domain poisoning.

1.DNS Query 2.DNS Query

According to the3.RST/ACK test results, the GFW4.DNS Response uses DPI to checks keywords inside DNS Client packets at the application layer.GFW If the packet containsGoogle Public DNS keywords that are blacklisted. The GFW will trigger the specific rules. The GFW has different filtering rules Censored Domain depend on the underlying transport protocol, either send RST/ACK packets to intercept TCP connection1.DNS Query or a fake response2.DNS Query over UDP. Based on the results obtained 3.Wrong Response 4.DNS Response from outsideClient the censored domain, the filtering rules appear to be bidirectional for both inbound and outbound networkGFW traffic. Google Public DNS

The responseCensored Domain constructed by the GFW over UDP protocol is straightforward since regardless of which1.DNS Query type is queried,2.DNS Query e.g., Name Server3.DNS Query (NS), Start of Author- ity (SOA) or Mail4.W exchangerrong Response (MX), the3.RST/ACK resolution result5.DNS is always Response an A type record Client with a forged IP address. TheseAli DNS poisoned domainGFW names are collectedRoot DNS to get the geolocation. Each of them is queried 101 times to Google public DNS server by using the UDPCensored Domain protocol in order to trigger the GFW and see the pattern behind the forged addresses. The1.DNS Query 770 unique fake2.DNS IP Query addresses are collected.3.DNS Query Table 3.1 shows 6.Wrong Response 4.Wrong Response 5.DNS Response AS number,Client company, and occurrence of IP related to these poisoned IP addresses. Most bogus IP addresses areAli coming DNS from IP blockingGFW list. TheRoot results DNS indicate that if users do not take active measures preventing DNS hijacking/poisoning, the effect is the same as IP blocking: packets will not be forwarded to the destination.

33 AS Number Owner Country Example CIDR Range IP Occurrence 31.13.64.0/19 69.63.176.0/20 AS32934 Facebook, Inc. US 173.252.64.0/19 456(41.1%) 66.220.144.0/20 69.171.224.0/20 204.155.144.0/20 AS40824 WZ Communications Inc. US 74.117.176.0/21 116(10.5%) 199.101.132.0/22 174.36.0.0/15 67.15.0.0/16 AS36351 SoftLayer Technologies Inc. US 74.86.0.0/16 67(6.0%) 67.228.0.0/16 208.101.0.0/18 AS19679 Dropbox, Inc. US 108.160.160.0/20 64(5.8%) 199.96.60.0/22 AS13414 Twitter Inc. US 199.16.156.0/22 63(5.7%) 199.59.148.0/22 69.63.176.0/20 AS10753 Level 3 Parent, LLC US 57(5.1%) 66.220.144.0/20 74.125.0.0/16 172.217.0.0/16 AS15169 Google LLC US 39(3.5%) 209.85.128.0/17 216.58.192.0/19 74.86.0.0/16 208.101.0.0/18 AS11172 Alestra, S. de R.L. de C.V. MX 174.36.192.0/18 38(3.4%) 67.228.96.0/19 75.126.112.0/20 74.86.0.0/16 AS22773 Cox Communications Inc. US 174.36.192.0/18 36(3.2%) 67.228.192.0/19 AS22561 CENTURYLINK, INC. US 66.220.144.0/20 30(2.7%) 128.242.0.0/16 AS2914 NTT America, Inc. US 168.143.0.0/16 30(2.7%) 124.40.32.0/19 AS19281 Quad9 US 216.58.192.0/19 13(1.2%) 72.233.0.0/19 AS13767 DataBank Holdings, Ltd. US 7(0.6%) 72.232.168.0/22 72.233.0.0/19 AS22576 DataPipe, Inc. US 7(0.6%) 72.232.168.0/22 AS31815 Media Temple, Inc. US 64.13.192.0/18 7(0.6%)

Table 3.1: Poisoned IP addresses The IP addresses returned in bogus DNS packets sent by the GFW are blocked in the network layer. 34 Poisoned Domains 1435 Correctly Resolved Domains 4265 Invalid Domains 470 Total 6170

Table 3.2: The proportion of poisoned domain names

3.5 Experimental results and summary

3.5.1 Threat model

The experiments reveal that the GFW has both in-path and on-path devices. The in-path devices focus on dropping or filtering the packets while the on-path devices have ability observing the packets on the fly, but do not directly tamper packets. The detection methods including keywords detection, any suspicious network traffic will trigger the rules predefined. These devices will further construct some forged packets to intercept normal connections between client and server. • The GFW does not target on decrypting data between server and client. The goal of the GFW is to intercept, terminate or block the connections. • The GFW can block the packets in the network layer by their in-path devices. • The GFW can monitor the state of connection in the application layer and look inside the packets. • The GFW has multiple intrusion detection modules, and each of them has an intrusion prevention rule module, e.g., detecting keywords in HTTP headers will trigger three RST/ACK packets.

3.5.2 Results and Circumvention suggestions

The measurement results are listed in Table 3.2 and Table 3.3. In general, TCP connection reset accounts for a large part in the GFW list, and there are 139 domains affected by both DNS poisoning and IP blocking while 923 domains are affected by DNS poisoning and TCP connection reset. After comparing results with the Al- exa top 100 global sites, 36 of 100 websites are blocked by IP addresses, and most of them are also affected by DNS poisoning. These websites including popular search engine, e.g., Google, video-sharing websites, e.g., YouTube and Dailymo- tion, social networks, e.g., Facebook and Twitter, as well as cloud storage such as Dropbox. Most unpopular or unknown websites are affected by only DNS poisoning or the TCP connection reset. The result shows that circumventing the GFW by directly attacking its on-path device is less efﬁcient, e.g., desynchronizing the connection state inside the data-

35 Poisoned Domains Correctly Resolved Domains IP Blocking TCP Connection Reset IP Blocking TCP Connection Reset 139 923 498 2219

Table 3.3: The number of domains affected by each blocking mechanism base since most popular websites are blocked at the network layer. The reliable way is to use the IP addresses that cannot be blocked by the GFW to forward the traffic, for instance, using Virtual Private Network (VPN) to encrypt the whole IP payload, or using a proxy outside the censored domain. According to the measurement in TCP connection reset, the GFW will use DPI to detect whether there are keywords inside the packets, for example, the Host field in HTTP headers or Question field in DNS request packets, or whether the pattern is apparent to detect, e.g., the certificate exchange in TLS handshake protocol. These intrusion detection rules indicate that the payload should be meaningless towards the detection from the GFW, one countermeasure can be encryption or randomization as which mentioned in the previous chapter. In addition to that, the handshake phase and data transmission phase cannot contain distinct features. Tunneling the data over other allowable protocols can be a way to solve this.

36 Chapter 4

Circumvention System Design

This chapter introduces a peer-to-peer based proxy system called the MultiProxy. Section 4.1 describes the design goals of the system. Section 4.2 gives a brief overview of the system architecture. It contains three major modules which will be described in the following three sections. The trafﬁc forwarding module is explained in section 4.3 including the SOCKS5 and TCP protocol, which provides the basic trafﬁc forwarding and circumvention service. Next, the threats of the Multi- Proxy system are analyzed in section 4.4. With the token economy implemented by the Trustchain protocol and the Intel SGX technology, a robust network is built with a balanced number of service consumers and providers. In order to provide privacy for request originators, the system also uses anonymous end-to-end communication, and it is explained in section 4.5. Finally, the implementation details of the token economy and anonymous routing are declared in section 4.6.

4.1 Design goals

In recent years, various methods have been developed to circumvent the censorship, such as the VPN and SSH tunnel. Shadowsocks, as an open source encrypted proxy software, has been widely used in mainland China to circumvent Internet censorship. This project has gained 26753 stars and 16626 forks on Github since 2012. The software has been ported to different platforms and operating systems. The idea behind Shadowsocks is to split socks proxy into two parts: the client inside the censored domain, and the server outside the censored domain. Various encryption methods are supported to protect the data on the path between the client and the server, e.g., AES, RC4-MD5, Salsa20, Chacha20, etc. Shadowsocks works efﬁciently for single users because of its lightweight design and good obfuscation. The regular use case is that users use their Shadowsocks clients to connect its own Shadowsocks server outside the censored domain.

37 Asia 117.18.232.200 Europe 152.199.19.160 US 72.21.81.200

Table 4.1: The IP addresses of meek server

However, the system also has some drawbacks. Shadowsocks is based on Client- Server architecture in its current implementation, which means it only supports one or multiple clients sharing the same server. This may cause the server-side single point of failure. Although the encryption method is good enough to ob- fuscate the protocol against the DPI technology of the GFW, the GFW still has some possibilities to integrate advanced methods to detect network traffic, e.g., machine learning[8] and entropy test[36]. Once the special network traffic is detected, Shadowsocks server can be easily discovered or blocked by the GFW. Users have no choices other than set up their new Shadowsocks servers. In addition to that, bandwidth can be limited in this architecture because usually a single user can only make use of the bandwidth of one server in consideration of server-side cost. The Tor project built on a distributed and anonymous network, developed a new pluggable transport meek[12] in 2014. This pluggable utilizes the domain fronting technique as the obfuscation layer to evade the censorship. The forbidden network traffic is relayed to a forwarder called meek server on the unblocked CDN network. Meek is now the only way for tor clients to access blocked websites from China. The figure 4.1 shows a Tor circuit established using meek. The first hop is the bridge with the meek server called “cymrubridge02”. This bridge is shared for all the Tor browsers which use the meek client. Figure 4.2 shows its clients number variation in the last year, and it increased from 5,000 to 10,000. The IP addresses behind the meek server “meek.azureedge.net” are shown in Table 4.1, the results are obtained by the domain name querying on the global scale. Although it is capable of a server to handle up to 10,000 clients at the same time, the server still can be the bottleneck of the performance.

Figure 4.1: A Tor circuit with pluggable transport meek

In order to overcome both drawbacks of the current existing client-server based

38 Figure 4.2: The average connected clients number of cymrubridge02[32] and distributed circumvention systems, a design of a decentralized censorship resistance system called MultiProxy is described in this chapter. MultiProxy relies on the concept of peer-to-peer network and provides a way for users inside the censored domain make use of multiple proxies at one time, it also proposes the token economy as an incentive method to balance the service consumers and providers. The detailed system architecture and components are listed in section 4.2.

4.2 System Architecture

SOCKS5 on edge Token economy Multi-hop Trustchain routing Intel SGX Peer discovery Data encryption

Figure 4.3: Circumvention system architecture

Figure 4.3 describes the main components and protocol stack of the MultiProxy system including SOCKS5 protocol on the edge, the token economy based on the Trustchain protocol and Intel SGX technology, onion routing and peer discovery protocol. All the functionalities are built on top of the peer-to-peer system. The main components will be introduced in the following subsections.

39 Censored Domain TCP/UDP SOCKS5 TCP Multiproxy Internet Multiproxy node node

Application Client Node/ Server Node/ Target Web Server Entrance Node Exit Node

Figure 4.4: Trafﬁc routing path

Figure 4.4 shows the primary traffic routing path of the MultiProxy system. There are two types of proxy nodes that exist in the system, mainly the client proxy node and the server proxy node. The client proxy can be the originator of the requests, and it can also act as the relay node which is used to forward network traffic when the circuits are built in onion routing. The server proxy node, also known as the exit node, is the critical component since it not only acts as the server to receive the data from the client proxy, but also acts as the client to build the connections between the target web servers to provide the circumvention service. A client node will at least find one exit node to build the circuits and get access to target web servers. The essential components of the system are listed in Table 4.2. As a circumvention system, the basic functionality is traffic forwarding, so the client node must forward its traffic to the nodes which provide related circumvention service. It requires the network data forward protocol between multiple applications and Mul- tiProxy system on the same host. In order to transfer data between the nodes, messages should be tunneled and encrypted to evade the various network traffic analysis techniques of the GFW. The second functionality is designed to make better use of multiple nodes. The number of service providers and consumers should be balanced to make the system available and robust. MultiProxy also provides the onion routing as anonymous communication over the network. MultiProxy also makes use of onion routing to protect the identity and privacy of request originators. The messages are encapsu- lated in each node it passes through in a way that the intermediate nodes cannot know the source and destination of the messages. This mechanism requires cryptography key exchanging protocol among the circuit(the path between multiple nodes).

4.3 Trafﬁc forwarding

4.3.1 SOCKS on edges

The basic functionality of MultiProxy is trafﬁc forwarding. This is achieved by adding a proxy layer on top of the traditional client-server architecture as shown

40 Functionality Goal Requirements Trafﬁc forwarding Provide basic circumvention service SOCKS5 protocol Data encryption

Token economy Make the system robust Trustchain protocol Intel SGX, SCONE

Multi-hop messaging Privacy protection for request originators Circuits creation Data tunnelling

Table 4.2: MultiProxy system components

in Figure 4.4. The proxy layer contains two primary components: a client node and a server node. The client node is used to receive the data from original applications, e.g., browsers. This client node can be considered as an extension of the applications since it can modify encrypted data from source applications, or change the destination address of a receiver. In order to forward the application data to MultiProxy, a proper data transmission protocol is needed.

The SOCKS5 is employed as the data transmission protocol between applications and the client node. SOCKS is a message exchange protocol which operates between the application layer and transport layer. It is designed to transparently and securely traverse a firewall. In its latest version five which defined in RFC 1928[26] supports the authentication, IPv6, and transferring data over both TCP and UDP. SOCK5 contains three phases: negotiation, address transmission, and data transmission as shown in Figure 4.5. When the protocol is initiated, the SOCKS5 client and the SOCKS5 server exchange various methods that will be used in the negotiation phase, the client then sends the destination address to the server. The server subsequently notifies the client that the connection is successful by replying with a binding message. The client and the server start to transfer data in the third phase if the connection built successfully.

The reasons why MultiProxy adopts SOCKS5 protocol between the applications and client proxy is because of its ﬂexibility and extensibility. Since SOCKS5 not only support the transport layer protocol like TCP and UDP but also can forward multiple application layer protocols such as HTTP and HTTPS.

In the MultiProxy system design, the server node is located in the uncensored domain and waits for data from the client node through the secure channel to forward to the free Internet. The purpose is to decrypt, reconstruct or modify data before relaying it to the speciﬁed destination address, such as a web server that is blocked by the censorship system. Once the server node receives the data from the remote website, it will forward the trafﬁc back to the client node.

41 SOCKS5 Client SOCKS5 Server

1. Negotiation

VER NMETHOD METHODS

VER METHODS

2. Address Transmission

VER … ATYP DST.ADDR DST.PORT

VER … ATYP BND.ADDR BND.PORT

3. Data Transmission Target Server Request

Response

… …

Figure 4.5: Work ﬂow of the SOCKS5 protocol

4.3.2 Peer-to-peer system

The proxy layer works appropriately only if the GFW does not know the address of the server node, since the server can be blacklisted. In order to make the system more scalable, i.e., the client node can use multiple server nodes to forward its trafﬁc. In this manner, even if some servers are taken down by the GFW which can happen in a traditional Shadowsocks setup, the client node still has other choices. Since Shadowsocks proxies are typically located in the public clouds, the censors cannot block the entire domains since it would lead to tremendous collateral damage. By combining all the SOCKS proxies into a single, shared infrastructure, the system becomes more resilient against the blocking of individual servers than in a unilateral setup. In addition to that, multiple server nodes can improve bandwidth. For these reasons, MultiProxy is built on top of the peer-to-peer network.

The nodes in the peer-to-peer network are unlike the traditional servers which have the ﬁxed and known IP addresses. Similar to the human relationships of the real world, somebody joins the network by the introduction of the member who is already part of the network. The way for a peer join network requires it at least connects to a node that is already in this network. In practice, the status of nodes is dynamically changed so that newly joining node cannot immediately ﬁnd a peer. For this reason, some bootstrapping nodes, which is also known as rendezvous

42 hosts, are set up to provide initial peer-to-peer network configuration such as IP addresses and service identifiers. As shown in Figure 4.6, for peers which do not know any other peers in the network, they will first connect to the trustworthy bootstrap node and register their addresses as well as service identifiers, which is used to specify what kind of service they provide. The bootstrap node sends its config- urations back to both peers. Nodes are allowed to discover and communicate with each other only if they have the same service identifiers. After the introductions, each node in the network maintains its list of known peers. They send ping and pong messages periodically to keep track of the status of other nodes, e.g., update new nodes or remove the off-line nodes.

Service Id 1

Service Id 2

Node

Bootstrapping node

Introduction request/response

Figure 4.6: Bootstrapping of a peer-to-peer system

4.4 Token economy

The unregulated system can only work in practice or reach a stable state if the interests between the parties who provide services and the ones that consume services are balanced. In this case, MultiProxy only works reliably if people in the uncensored domain are willing to share their resources and contribute them to a common circumvention. In MultiProxy, the primary challenge is to balance the number of servers and clients. Nowadays many people already run their Shadowsocks servers in the public clouds. This means a new mechanism to incentivize that people set up their server instances into the MultiProxy system when they want to use it to avoid the problem of free-riders[1]. The free-rider problem is a signiﬁcant threat for peer-to-peer systems in general and has been extensively studied for systems like BitTorrent in which peers only download ﬁles without upload anything, which is unfair for peers who contribute to the network and can have negative effects on the system. The solution for optimizing the download speed in BitTorrent is to use tit-for-tat [7],

43 which originates from the highly effective strategy of game theory. In this strategy, BitTorrent will choke uncooperative peers who do not contribute to upload ﬁles and allocate its limited upload slots to other more cooperative peers. The free-rider problem in MultiProxy system means peers use the circumvention services provided by server nodes without contributing back by providing the bandwidth of its proxy server for other nodes. It can lead to the unbalanced number of proxy servers and clients, namely the number of clients is far greater than the number of servers. To avoid this phenomenon, MultiProxy introduces tokens as a way to create incentives and balance the providing of resources against con- sumption. More speciﬁcally, in MultiProxy system, the client node must pay some tokens before using the circumvention service provided by a server node. In the meanwhile, the server node can earn tokens by providing its circumvention service.

4.4.1 Analysis of threats to the system

In an open environment like the Internet, some nodes might be selfishly and abuse the system for their use. This section describes the threats and challenges that MultiProxy has to confront. There are three main threats that the system will be encountered: the single point of failure, token falsification, and invasion of data privacy. The first two threats can be summarised as where and how to store the tokens. Therefore, MultiProxy focuses on solving two problems of the token economy, namely how to protect tokens and how to protect data and sensitive information transferred in between.

Single point of failure

One of the weaknesses of centralized transaction servers is the single point of failure. The single point of failure (SPOF) can lead the whole token economy system stop working if the centralized transaction servers are compromised or fail, and the trust problem means that the centralized transaction servers have rights to tamper or revise the records, and there is no one in the network can verify its correctness.

Forging tokens

Even with the help of the decentralized accounting system, there are also some threats that exist in the system. The ﬁrst threat is that the malicious server node does not provide equivalent services after taking the number of tokens. In most cases, a server node might earn the token without providing equivalent service. For instance, a malicious server could be located inside the censored domain, for the sole purpose of mining tokens. However, it does not provide the real circumvention service since it lacks the capability of relaying packages to the uncensored

44 Censored Domain Filtered

IP packets

Client GFW Web Server

Censored Domain

TCP Segment

RST/ACK RST/ACK

Client Keywords Detected Web Server

GFW

Censored Domain

DNS Query

Forged DNS Reply Correct DNS Reply Client Keywords Detected Web Server

Censored Domain Filtered

IP packets GFW

Client GFW Web Server

Censored Domain

Censored Domain DNS Query DNS Query

TCP Segment Forged DNS Reply Forged DNS Reply Correct DNS Reply

RST/ACK RST/ACK Keywords Detected Client Web Server Client KeywordsAli DetectedDNS Poisoned Cache Web Server

GFW GFW

Censored Domain

DNS Query

Forged DNS Reply Correct DNS Reply Client Keywords Detected Web Server

GFW

Censored Domain

DNS Query DNS Query

Forged DNS Reply Forged DNS Reply Correct DNS Reply Keywords Detected Client Ali DNS Web Server Poisoned Cache

GFW

Internet. This malicious behavior can be detected by challenge-response authentication as shown in Figure 4.7. If a server node chooses to be a circumventive server,Server-side it must vulnerability complete analysis: the challenge-response authentication, which is used to deﬁne whether the server node acts its role correctly, in this case, send back the contentIf of server some choose speciﬁed to be a circumventive blocked websites. server, then this server must complete challenge response..

Censored Domain

1. Challenge 2. Challenge

4.Wrong Response Client Malicious Server Blocked by the GFW

Figure 4.7: Challenge response mechanism

challenge-response: the method to define whether the server act as the role correctly. The malicious server node can also cheat in mining in order to get more tokens, e.g., in the time-based mining model, a malicious server can adjust system the clockCensored faster. Domain In bandwidth or network traffic model, it is easy forReactions the server of to a malicious server: forge the bandwidth or packetsMessage it relays. 1. Perform traffic analysis ? 2. Drop or modify the message 3. Send wrong response back Client Malicious Server 4. Impersonate the client

DataServer-side privacy vulnerability analysis:

If server choose to be a circumventive server, thenMITM: this server 1. the must reason complete why challenge to use hidden response.. service since they do not know the orignal client, so evil server in this case only know the message/url but do not know who Another threat is that the server node can manipulate dataactually thatcomes send the frommessage the 2,3,4, the reason why to use SGX with trustchain client node. Censored Domain

1. Challenge 2. Challenge Figure 4.8 shows how the malicious server in the uncensored domain violates its roles.Censored First, Domain by4.W knowingrong Response almost information of clientUDP node, for example, the IP Client Evil Server address, port number,SOCKS5 and messages, the server node canBlocked perform by the trafﬁcGFW analysis TCP Proxy Tribler IPv8 IPv8 Proxy so that the client node can loseClient its privacy.Node In additionNetwork to that, the serverNode canServer also launch Man-in-the -middle attack (MITM) in multiple ways, e.g., stop forwarding Application or drop thechallenge-response: message, and the modify method to the deﬁne message whether the in server some act as unencrypted the role correctly. case. Client Node/ Server Node/ Target Web Server Entrance Node Exit Node

Censored Domain Reactions of a malicious Message server: 1. Perform trafﬁc analysis ? 2. Drop or modify the message Censored Domain 3. Send wrong response back Client Malicious Server 4. ImpersonateBehavior the client of an evil client: Message Block those servers return the Figure 4.8: A malicious server node correct response in challenge response MITM: 1. the reason why to use hidden service since they do not know the orignal Evil Client client, so evil server in this case onlyServer know the message/url but do not know who actually send the message 45 2,3,4, the reason why to use SGX with trustchain

Censored Domain UDP Reactions of a malicious Censored DomainSOCKS5 TCP Proxy Tribler IPv8 IPv8 Proxy client: Client MessageNode Network Node Server Block those servers return the Application? correct response in challenge- response authentication Client Node/ Server Node/ Target Web Server Malicious Client Entrance Node ServerExit Node

Censored Domain Behavior of an evil client: Censored Domain Message Block those servers return the correct response in challenge response PT Proxy EvilSOCK5 Client PT Server Network Server Client Server Server

Reﬂector in the Client Node/ front domain Server Node/ Entrance Node Exit Node Censored Domain Reactions of a malicious client: Message Block those servers return the ? correct response in challenge- response authentication Malicious Client Server

Censored Domain

SOCK5 PT PT Proxy Network Server Client Server Server

Reﬂector in the Client Node/ front domain Server Node/ Entrance Node Exit Node 4.4.2 Solutions for threats

Trustchain solutions for single point of failure

Since MultiProxy is a distributed proxy system, it does not use the centralized transaction servers because of the weakness of the centralized systems such as single point of failure, performance bottleneck and trust problem mentioned in section 4.1. The solution for these problems is using the Trustchain protocol[31] as a distributed ledger and record transactions for nodes. This section gives a short introduction to the Trustchain protocol. The Trustchain protocol is an open, distributed ledger which is designed to record transactions and build trust between involved parties. Unlike the Blockchain, in the Trustchain protocol, each node maintains its personal blockchain initialized by a genesis block. Figure 4.9 shows the structure of personal blockchain. Once a node creates a new transaction inside a half block, it firstly signs its half block, then sends the signing request to another node and store the results back if the block is verified and signed by the other peer. It is resistant to data modification by an append-only ordered list. The attestation reports are stored in the Trustchain. Trustchain can cope with attacks, e.g., it can detect the Sybil attack due to its different data structure, i.e., a block is valid only when it signed by both parties. A group of malicious nodes can only form their clusters, and the clusters without the trust from outside can be easily distinguished. Compared to the Blockchain protocol, the Trustchain protocol can better fit in the MultiProxy, because it is not necessary to wait for all nodes in the network reach a global consensus state.

Mining models and transaction methods

The mining models of MultiProxy can be based on many metrics, such as time and throughput. • Time: Earn or spend tokens according to the service running time. • Throughput: Earn or spend tokens according to the throughput during a certain amount of time. From the analysis in section 4.4.1, to prevent tokens from malicious use, the number of tokens is considered as the sensitive data in the MultiProxy system. MultiProxy nodes keep their balance and income in the database and do not exchange tokens directly to each other. Instead, they must complete Intel SGX attestation, which will be introduced in the next section. The goal is to prevent nodes from modifying and cheating the amount of service during the mining processing.

46 Figure 4.9: Trustchain protocol[20]

47 There are two approaches for clients and servers to exchange tokens. The first approach is to let the server proxy checks and verifies the correctness of the transaction record inside the half block. This approach can let the server knows the identities and actual behaviors of the clients. For instance, the server sets timers or bytes counters once the client is connected. The drawbacks are evident since the connection records for clients increase the overhead of the server, especially when the connected clients reach the connection limit. With regard to the client, this approach is not secure considering the privacy issues since the server knows its behaviors. In the second method, instead, the client and server set their timers or byte counters to record its own expense or income. In such cases, the server does not record or track the client activities, so it knows nothing about the client. This not only prevents the privacy of the client but also reduce the server side code complexity and performance overhead. The MultiProxy uses the second approach that each agent records the total amount of tokens it earns or spends inside its blockchain. However, this is not enough to solve the trust problem between the client and server since nodes can lie about the token numbers they have. For instance, a server can modify the source code and claim that it earns 100 euros even if it never forward the network traffics. There- fore, the system needs another mechanism to ensure that nodes cannot forge the number of works.

Keeping the servers honest with Intel SGX remote attestation

In order to solve the trust problem between the client and server, MultiProxy is ex- ecuted under the protection of the Intel Software Guard Extensions (SGX), which means the selected code is running inside the safety zone without any modiﬁca- tions. This subsection gives a short introduction about how Intel SGX prevents the source code from modifying and disclosing by untrusted parties. Intel Software Guard Extensions technology uses a set of special CPU instruc- tions to protect the sensitive data. It requires applications divided into two components: trusted component and untrusted component. Only the code inside the trusted component, which is also known as the enclave, can access to these private data. The remaining part runs in the untrusted component. The code and data in the Enclave are placed in a dedicated area called Enclave Page Cache(EPC), and this area is encrypted by the Memory Encryption Engine(MEE). Only encrypted data can be observed if some processes externally read the main memory. With the protection of the enclave, the code in the same application can be trusted, but these secrets are still vulnerable during transit. In order to verify whether other applications in local machines or remote machines run in the enclave, Intel SGX provides two types of attestation, the local attestation, and the remote attestation. The local attestation runs when multiple enclaves in the local applications

48 need to cooperate on the same task, they use attestation among each other and get the session key for securely transferring and copying data. The remote attestation sends attestation to the third-party server and gets attestations back. The private data in an enclave are encrypted when it enters to the untrusted component. This is also called data sealing. The encryption key can be either enclave identity or sealing identity, depending on the speciﬁc application requirements. Figure 4.10 shows the client establishes an authentication channel by the remote attestation.

Figure 4.10: Intel SGX Remote attestation[19]

In MultiProxy, both client node and server node cooperate by forwarding requests and responses, but in order to prevent cheating, all the nodes need the veri- ﬁcations that the token mining part runs appropriately. Therefore, the code of mining model in MultiProxy is running inside the enclave as the trusted component. This part of the code cannot be modiﬁed by any programs except the untrusted part which creates the enclave. The process ensures the node itself cannot forge the amount of work by modifying the source code or changing the results during the program execution time. In addition to that, the system requires some remote attestation infrastructures to provide a way for attesting the data in transit and building a secure channel between nodes. One limitation of the Intel SGX is the particular hardware requirement: it only runs in sixth or later generation Intel core processor with Intel SGX-enabled BIOS support, which means the MultiProxy does not provide the trust environment for some old devices.

SCONE: trusted execution of containers

SCONE[2] is a Linux container based platform which utilizes the Intel SGX technology. It lets applications run in a secure fashion just as the Intel SGX. For instance, SCONE can prevent malicious nodes from reading the main memory. In addition to that, SCONE has the abilities to prohibit adversaries who have the root privileges to load the main memory, or access by the operating systems, hypervisor

49 Figure 4.11: Intel SGX Remote attestation full work ﬂown[19]

50 and cloud provider, the Intel SGX supports this.

SCONE provides the low-performance overhead by supporting the asynchron- ous calls and user-level threading. The API can transparently encrypt and decrypt the I/O data such as configuration files, environment variables, and command line arguments. It verifies the correct code is running before it passing any config- urations into the application. This is ensured by the local and remote attestation and configuration service, but unlike the Intel SGX, the attestation of SCONE is entirely transparent for the application.

MultiProxy uses SCONE as the running environment for three reasons. In the first place, both Intel SGX and SCONE provide the remote attestation. SCONE has its attestation server called SCONE global Configuration and Attestation Service (CAS). This infrastructure can issue the same SSL certificate to all the end nodes to ensure the token mining code of MultiProxy in the different machines run in the protection of the enclave. Another consideration is implementation complexity. The Intel SGX SDK is based on C/C++ programming language. For instance, figure 4.11 depicts the full work flow of the Intel SGX remote attestation, and this involves numerous message transmission. Considering that MultiProxy is written with Python, it exists some incompatibilities and needs additional efforts to combine these two languages. SCONE supports the most popular and mainstream language such as Java, Rust, Go and Python. Therefore, Switching to SCONE is relatively easy because the source code of the application does not need to be modified. Finally, SCONE can be used on top of the containers such as Docker, and the standardization of Docker makes the MultiProxy easy to build, deploy and test on various platforms. Therefore, SCONE is used for implementing the token economy in MultiProxy, and it can prevent the malicious nodes from modifying the source code.

Solutions for token economy

By combining the Trustchain protocol with SCONE together, the solution for building a distributed trusted token economy without cheating is following: Assuming the most basic situation of two nodes, a client node, and a server node, they both run the program on top of the Intel SGX. In the beginning, they perform remote attestation to ensure both endpoints are running the same, legitimate code inside the enclaves, and they both get the certificate issued by CAS(Configuration and Attestation Service). The certificate will be stored inside every transaction on the blockchain and be sent to its peer in periodical intervals. The peer verifies and signs the transaction only if the global CAS issues the certificate.

51 4.5 Multi-hop messaging

4.5.1 Solutions for data privacy

According to the threat analysis in section 4.4.1, the information of request originator need to be protected to avoid malicious behaviors of the exit node, e.g., trafﬁc analysis. One way to protect privacy is restricting the knowledge of nodes, i.e., there is no node knows the full information of a network. Multi-hop message routing is a countermeasure for privacy protection since it prevents the identities of request originators.

End-to-end anonymous communication

Anonymous communication is used for privacy protection. It can be achieved by building the data transmission circuits, which means nodes arranged in different paths. Onion routing is a way to wrapping and encrypting messages in successive layers through the network which has multiple intermediate nodes. It can well protect the privacy of originator since the messages are encrypted sending in between and no intermediate node inside the circuit can tell the source and ﬁnal destination of the message, except the exit node, can determine itself as the last hop. In the MultiProxy system, messages are protected by the onion routing mechanism. The request originators can specify how many hops they want to build. Then it starts to build circuits between a list of nodes it can be achieved by using asymmetric key cryptography, e.g., Difﬁe-Hellman key exchange algorithm, to negotiate different session keys through the network. The server nodes are declared themselves as the exit nodes and become the last hops to forward the data to the target web server. Once the circuit is built, data will be forwarded inside the circuit. Figure 4.12 shows a 2-hop circuit from the client node to the exit node(server node). In ideal situations, the client node and the relay node should both in the censored domain so that the exit node cannot distinguish which one is the actual request originator.

Censored domain

relay node target server client node exit node First encryption layer Second encryption layer Original message

Figure 4.12: A 2-hop onion routing circuit

52 4.6 Implementation details

MultiProxy1 is built on top of IPv82. IPv8 is a Python implementation library that provides multiple communities to ensure authenticated communication and privacy. Those communities including peer discovery, attestation, DHT, anonym- ization, and the Trustchain. MultiProxy reuses the anonymous messaging and the Trustchain communities as shown in Figure 4.13.

Community

TunnelCommunity TrustchainCommunity

MultiProxy

MultiProxyClient MultiProxyServer

MultiProxyInitiator MultiProxyForwarder

Figure 4.13: The class UML diagram of Multiproxy

4.6.1 Trafﬁc forwarding

HTTP and HTTPS are currently the common World Wide Web data communication protocols based on TCP, and the latest version of IPv8 only has the UDP endpoint implementations. Therefore, a TCP endpoint interface is written to forward the basic web trafﬁc using twisted, which is a Python event-driven networking engine. Different from other client-server based implementation, MultiProxy split the system into three parts: Initiator, Forwarder and Server. Figure 4.13 shows the inheritance relationship between the different components. Both Initiator and Forwarder are inherited from MultiProxyClient because some code can be reused, e.g., serve as the SOCKS5 server.

1https://github.com/nyannko/proxy 2https://github.com/Tribler/py-ipv8

53 The class implementation is illustrated in the Figure 4.14. Each component has two classes, and these two factory classes act as both the server and client to handle the bidirectional connections. MultiPorxyInitiator acts as a SOCKS5 server to receive data sent from the applications, and then pack these data into the self-defined packet which is shown in figure 4.15, and finally send it to the selected node. Mul- tiProxyForwarder only changes the header of the received data and forward to its selected nodes. MultiProxyServer can unpack the true target server address inside the request initiator and build the TCP connection with the target website. The client factory class of each component forwards the data back to the browser.

SOCKS5 SOCKS5Factory TCP ForwarderFactory TCP SserverFactory TCP browser Target web server ClientRemoteFactory ForwarderRemoteFactory ServerRemoteFactory

MultiProxyInitiator MultiProxyForwarder MultiProxyServer

Figure 4.14: Components and work ﬂow of MultiProxy

20 bytes

TCP header

4 bytes 4 bytes 4 bytes

Circuit ID Data length Data type

Message body

Figure 4.15: Packet structure

Since TCP is a stream-oriented protocol, the data from the origin may be broken up to chunks with arbitrary size, and there is no way for the receiver to recognize or determine the original data size. Therefore, the sender should attach the message length inside the header, and the receiver parses the TCP stream and extract the message body.

4.6.2 Token economy

Two token mining models mentioned in section 4.4.2 are implemented in function 1 and 2. The function COUNTTIME creates the transaction by calculate the time intervals. The function COUNTBYTES calculated the sum of bytes length from each connection. Both of functions pack the certiﬁcate issued by SCONE inside the transaction.

54 The function SENDSIGN describes that the sign requester sends its unsigned half block after choosing mining model to calculate the transactions. The SHOULD- SIGN is shown in function 4, and it contains the attestation and verification for SCONE certificate. This verification could be implemented by trying to connect by HTTPS protocol. Currently, the implementation of MultiProxy is run in debug mode without using attestation since SCONE CAS is currently not available.

Algorithm 1: COUNTTIME Input: identity, certiﬁcate, balance, debit, credit Output: A transaction contains the current balance 1 initialization 2 timeStamp ← current time 3 balance ← balance + debit- credit 4 transaction ← createTransaction(timeStamp,identity,balance,certiﬁcate) 5 return transaction

Algorithm 2: COUNTBYTES Input: A client factory that manages connections, identity, SCONE certiﬁcate Output: A transaction contains the size of bytes 1 initialization 2 timeStamp ← current time 3 totalBytes ← 0 4 for connection in clientFactory do 5 totalBytes ← totalBytes + getByteSize(connection)

6 transaction ← createTransaction(timeStamp,identity,totalBytes,certiﬁcate) 7 return transaction

4.6.3 Anonymous messaging

This section introduces the circuit build process of the Tunnel Community. Figure 4.16 shows the basic idea behind the IPv8 circuit creation. Various messages are sent from nodes when they establish a circuit. The request originator, ﬁrst speciﬁes how many hops it wants to build, then it requests the next hop by the “create” message, once hop 1 receives the message, it generates the shared session key and send back a “created” message to the originator. The originator then sends the “extend” message to hop 1 and hop 1 forwards the “create” message to hop 2. When hop 2 receives the message, and generate a new session key. Then it sends back a “created” message to hop 1. Hop 1 sends the “extended” message back to

55 Algorithm 3: SENDSIGN Input: The mining model function, a list of known peers Output: The callback shows succeed or failure 1 initialization 2 randomPeer ← randomly select a peer 3 randomPeerPubKey ← the public key of randomPeer 4 transaction ← miningModel() 5 callBack ← signBlock(randomPeer,randomPeerPubKey,transaction) 6 return callBack

Algorithm 4: SHOULDSIGN Input: The unsigned block Output: A boolean value whether the signer should sign the block 1 initialization 2 certificate ← unpack(transaction) 3 result ← verify(certificate) 4 return result the initiator. The process repeated when it reaches the exit node. Each node in the circuit only knows the current hops and minus one before sends it to the next hop, so each intermediate hop cannot distinguish the source of the messages and final destination since they all receive the same messages during the period of building a circuit. The encrypted data transfers securely with multiple session keys between nodes after they build the circuits.

Figure 4.16: Build a 2-hop circuit[37]

56 Chapter 5

Evaluation

This chapter presents a comprehensive evaluation of MultiProxy. The goal of the evaluation is to examine how well MultiProxy can unblock the Great Firewall and its overall performance compared to other censorship circumvention systems. In the ﬁrst step, the systematic metrics are deﬁned for the evaluation framework, and this is described in section 5.1. Furthermore, the methodologies, as well as the experimental steps, are developed based on the evaluation framework in section 5.2. The measurement results and analysis shows in section 5.3.

5.1 Evaluation framework

In order to measure the performance of MultiProxy, an evaluation framework is developed as shown in Figure 5.1. The overall performance of MultiProxy is broken down into two dimensions: network performance and system performance.

5.1.1 Network performance

The network performance can be considered as the most important part of the evaluation framework. It aims at measuring the service quality of MultiProxy.

Latency Network performance Throughput CPU usage System performance Memory usage

Table 5.1: Evaluation framework

57 Latency

Network latency, which is also known as end-to-end latency, refers to the total time that a packet takes from the source to the destination. The network latency can be inﬂuenced by multiple reasons caused by any transfer object between the start point and end point. For example, the LAN, WAN or path from ISP to host. One intuitive way to measure latency is to compute the transmission time by subtracting the starting time from the arrival time in different nodes. However, since it is a nontrivial problem to synchronize the clocks among different devices, the Round- trip time (RTT) is usually used to measure the latency between two nodes. Round- trip latency means that all time comparisons are made from the same node. Since the network latency changes frequently, one way to get the accurate latency is to repeat the measurement throughput the day in regular time intervals and get the maximum, minimum, average and standard deviation(jitter) of the RTT.

Throughput

The network throughput means the amount of successfully delivered data over the communication channel per unit of time. It is given as bits per second(bps). Throughput can be evaluated by computing the divide the total bytes that one node received by the RTT. However, the actual throughput is usually lower than the the- oretical bandwidth of the medium due to various additional factors, such as the concurrent use of the network, congestion and ﬂow control.

5.1.2 System performance

Although nowadays most computers have powerful CPU processors and large memory capacity, system performance is still an important factor for user experience. CPU usage and memory usage is evaluated during the usage of MultiProxy.

CPU usage

The CPU usage indicates the proportions of the CPU cycles dedicated to running the particular program. The experiment measures the CPU utilization, which is the CPU time divided by the process running time, and expressed as a percentage.

Memory usage

Memory usage refers to how much physical memory that a program used in its running period. The evaluation uses the physical memory that a process occu- pied instead of the ratio between the resident set the size to the machine physical

58 memory since the ratio will close to zero if the machine has a large amount of memory.

5.2 Methodologies and experimental steps

The evaluation framework in section 5.1 is applied to methodologies and experiments. The evaluation of system functionality consists of two parts. In the ﬁrst part, the performance of MultiProxy is measured under different server location setups. In the second part, the effectiveness of MultiProxy is measured by comparing the performance with other representative censorship circumvention systems to get its relative performance. The scalability test in the last subsection declares the performance with multiple concurrent nodes.

5.2.1 System performance

This section describes the detailed experimental steps of measuring pure system performance. The server’s location is considered as the main influence factor of MultiProxy. In order to get both ideal performance and practical performance. MultiProxy is deployed under two different situations: The first case is the over- provisioning case that provides enough capacity for network traffic transmission. Therefore, the network traffic are supposed to have low latency and relatively high throughput with low packet loss rate. The ideal performance of MultiProxy can be measured under the first case, while the second case has more uncertainty factors, e.g., how much resources or buffers that the intermediate routers can hold. The location selection is listed as following: • All nodes are deployed inside the same cluster of DAS5. • The nodes are deployed among the different cloud instances on a global scale. The Distributed ASCI Supercomputer 5 (DAS5) is a six-cluster wide-area distributed- system which provides a common computational infrastructure for parallel and distributed tasks. The head node of each cluster manages tasks by using the SLURM batch queueing system. Each node for experiments has two eight-core Intel Xeon E5 CPUs(2.40GHz) with Intel Hyper-Threading technology which allows the single physical core processors to behave as like two logical processors, so each node has 32 logical processors in total. The memory size is 62GB. For network configura- tions, MultiProxy makes use of InfiniBand network which offers up to 48 Gbit/s to transfer data. Since some user or registered ports are filtered by the firewall, Multi- Proxy runs in the different head nodes cannot directly connect, so the experiment of nodes located in the different clusters cannot be completed, only the performance

59 test of nodes which are located in the same cluster are performed. The operating system is CentOS 7 in DAS5. As for the global service instances selection, the client is the Alibaba cloud instance located in South China. The candidate internal hops and the exit nodes are all Google Cloud instances, which are located in the Netherlands and South Car- olina, USA separately. These cloud instances use the high-performance premium networking tier, and the network topology is shown in Figure 5.1, The client in China is ﬁrst connect to one cloud instance located in the Netherlands, this instance acts as the client and forward the data to the other instance in the Netherlands, and ﬁnally reach the exit node in the USA. Each global cloud instance employed for the test has one single-core Intel Xeon CPU, and the logical processors are also one. The operating systems of these cloud instances are CentOS 7.

Figure 5.1: Premium networking topology of Google Cloud instances[21]

5.2.2 Performance Comparison

Comparable research is conducted to measure the practical performance of Mul- tiProxy. It is compared to the other representative censorship circumvention systems. These systems are divided into three categories according to their protocols and architectures. For each category, the most popular and representative systems are chosen. The first is the proxy solution, which works in the transport layer, including Shadowsocks and V2Ray. The other is the Virtual Private Network (VPN) solutions perform at the network layer, including OpenVPN and OpenConnect. The last is the I2P solution, and its typical application is Tor. The overall performance is measured by using the evaluation framework described in section 5.1. Different CRSes are tested by using different encryption and accessing methods. The Shadowsocks is configured as AES-256-CFB encryption method to protect the data transmitted between the proxy client and server, V2Ray utilizes the self- defined communication protocol called VMess. For VPN solutions, both Open- VPN and OpenConnect make use of AES-256-GCM encryption and LZ4 data compression method based on Datagram Transport Layer Security (DTLS). Tor

60 exploits the meek pluggable transport to discover available bridges, as well as the onion networking to transfer data. All CRS servers including proxy servers and VPN servers are deployed in the US instance and act as the exit node except Tor since Tor use its onion routing settings. For MultiProxy, China instance with US instance composed as a one-hop setup. Two-hop setup consists of China, Neth- erlands and US instances, while three-hop setup including one instance in China, two instances in the Netherlands and one US instances. In order to measure the performance of systems, the command line tool curl is acted as the client to calculate some data, e.g., the data transmission time.

5.3 Results and analysis

This section presents the results and analysis of the evaluation. The ﬁrst section shows the network performance of MultiProxy. The latency and throughput comparison of different censorship circumvention systems reveals in subsection 5.3.2. Subsection 5.3.3 gives the system performance including the CPU and memory usage. The last subsection shows the result of the scalability test.

5.3.1 Network performance

The latency within MultiProxy is measured by calculating the message sending time between arbitrary two nodes. The result shows that RTT achieves 2.815 ms with a standard deviation of 0.5 ms. In the next step, to measure the real network performance of MultiProxy, the top ﬁve blocked websites from Alexa Top 500 Global Sites are selected as the target servers because of its popularity, these websites including Google, Instagram, Twitter, Facebook, and YouTube. The ﬁrst experiment measures the latency in the same DAS5 cluster. Figure 5.2 compares the latency of the same DAS5 cluster when clients visit different target web servers. The point in the middle indicates the mean of the measurement and the vertical line represents the standard deviation of the page download time. Hop zero means the proxy client and server are both runs in the same host. The result shows that the latency inside of the DAS5 same cluster is slightly increased as the hop numbers growth. The latency of Google obtains the least response time, and the latency of Instagram, Twitter, and Facebook following closely, while the latency of YouTube is the highest due to the websites transmit more data compared to others. The latency and standard deviation are increased due to the network situation and proxy processing time. Although the result is slightly increased with the growth of the hop number, in absolute values the difference between using multiple hops and directly connecting to the target servers without using proxies is small and likely outside of what a user can perceive. The result

61 shows that under an ideal environment, the latency of MultiProxy is close to the latency that directly connects to the server while protecting the privacy of the user much better.

Latency with different hop length

1200 1155 1136 1140 1140 1142

Google 1000 Instagram Twitter Facebook 800 YouTube

Latency (ms) 665 669 646 649 652 600 521 501 507 514 518 446 418 427 432 400 397

without proxy 0 1 2 3 Hops

Figure 5.2: Latency with different hop length

In the global latency measurement, the target servers and accessing methods are still the same as the first experiment, and the result shows in Fig 5.3a. The performance among different websites is close to the local latency test, accessing Google with the fastest response while YouTube is slowest. The latency and standard deviation of Tor are relatively high compared to others due to the limited number of domain fronting servers and bridges, or the unbalanced number of the client nodes and exit nodes. It needs 10 to 35 seconds on average to access the homepages while the latency of other competitors is under 4 seconds. Because of the high latency and poor performance of Tor, it makes the graph unreadable concerning other CRS systems. Figure 5.3b omits the Tor results and focused on the other systems. The results indicate that the VPN solutions are slightly slower than regular proxy solutions, that is because VPN works on the network layer and they try to encrypt and compress the whole IP packet transmitted in between while the proxy solutions work on the transport layer, which can categorize different network traffic instead of deal- ing with the whole IP packet, e.g., they only encrypt the body of the TCP stream or UDP datagram. Another reason is that proxies are more flexible than VPN solutions. For example, they can build the blocklist and only encrypt or compress the network traffic when the destination address is blocked. The performance of one-hop MultiProxy shows in the third place on the left is in the middle of proxy solutions and VPN solutions, and the latency increase with more hops due to the

62 different network situations, the one-hop setup is more stable than two hops and three hops. MultiProxy still obtain quick access compared to Tor. One reason mentioned before is that Tor has a small range of domain fronting servers and exit nodes compared to its users or client nodes, and the token economy can solve this in MultiProxy since all exit nodes get paid while providing the circumvention services. The economy system can promote the number of service providers, and this provides a better network environment and performance in the latency and throughput.

Latency under different methods Latency under different methods 4500 Google Google Instagram Instagram 35000 4000 Twitter Twitter Facebook Facebook 3500 30000 YouTube YouTube

3000 25000

2500 20000 2000 Latency(ms) Latency(ms) 15000 1500

10000 1000

5000 500

0 0 Shadowsocks V2Ray MultiProxy OpenVPN OpenConnect Tor Shadowsocks V2Ray MultiProxy OpenVPN OpenConnect

(a) Latency measurement (b) Latency measurement without Tor

Figure 5.3: Latency measurement

Besides the latency tests, the throughput test is also performed to test the download speed. The client downloads the 10 MB speed test ﬁle which is located in the same instance with the server side of CRSes. The result shows in Figure 5.4, it compares the different throughput. Shadowsocks has the fastest download speed with 2745KB per second. The result of Tor 17KB per second is the lowest. It con- ﬁrms the latency test before, because Tor has the highest latency and response time. Both OpenVPN and OpenConnect are slower than proxies. The one-hop setup of MultiProxy obtains a similar throughput as Shadowsocks and V2Ray. The result of MultiProxy two hops and three hops decreased due to the complex network situations.

5.3.2 System performance

This section shows the result of the system performance including CPU usage and memory usage. The experiments are conducted in DAS5. As for the methodologies, the CPU performance of the client, forwarder, and server is measured separately. In the ﬁrst situation, MultiProxy establishes a 2-hop circuit including one client, one forwarder and one server without starting to provide the circumvention

63 Throughput Comparison

Shadowsocks 2745

V2ray 2508

MultiProxy1 2496

MultiProxy2 1776

MultiProxy3 1589

OpenConnect 2038

OpenVPN 2220

Tor 27

0 500 1000 1500 2000 2500 3000 Throughput (KB/s)

Figure 5.4: Throughput measurement

services. Figure 5.5 presents the CPU utilization variations, and Figure 5.5a shows the CPU usage with y-axis range from 0 to 100 percent, which means the CPU consumptions during the whole MultiProxy process is no more than 6%. Figure 5.5b depicts the detailed information with a smaller range of y-axis, The value is around 4.5% at the earliest stage, because of the initialization workload, and stead- ied falling to 0.5% as the time goes on. In the second case, the curl is employed as the request originator, and the starting point of the CPU usage is slightly higher than the ﬁrst case, which is around 5%, and the overhead is increased for all nodes, especially the server and client, and the usage is around 3% to 4% while the performance of the forwarder still stabilized at 0.8%.

The memory test measures the mean value and standard deviation during a period of time before and after MultiProxy providing the circumvention service. The memory here refers to the physical memory. As shown in the bar chart 5.6, the performance is relatively stable without providing the circumvention service, and the memory usage is around 27 MB. In the second case, the overhead for client and server is slightly increased to 29 MB while the forwarder still maintains at the same level as before. This is because the forwarder has a lighter workload compared to the client and server.

64 CPU usage of each component in Multiproxy CPU usage of each component in Multiproxy 100 6 Client Client Forwarder Forwarder Server 5 Server 80 Client (curl) Client (curl) Forwarder (curl) Forwarder (curl) Server (curl) Server (curl) 4 60

CPU usage (%) 40 CPU usage (%) 2

20 1

0 0 0 15 30 45 60 75 90 105 0 15 30 45 60 75 90 105 Time (s) Time (s)

(a) CPU usage with 100 percentage (b) Throughput with different node number

Figure 5.5: CPU usage (%)

Memory usage of each components in MultiProxy

Client Forwarder 30 29.69 29.55 Server 27.49 27.49 27.49 27.49

15 Memory usage (MB)

0 Before circumvention After circumvention

Figure 5.6: Memory usage (MB)

65 5.3.3 Scalability test

This section describes the scalability test. The goal of the scalability test is to measure the system capacity to scale up or scale out. It evaluates the particular metrics with the workloads increment. The latency and throughput in the network performance are chosen as the metrics for evaluating how many nodes the network can hold without remarkable performance degradation. A network with one to one client-server ratio is measured. In this network, every client builds a one-hop circuit by randomly choosing a server as the exit node and then sending the request to Google.com. The scalability experiment is run in DAS5. Up to 50 nodes are hosting and running in each physical node in the cluster. That is feasible since as mentioned in section 5.2, each physical node has 32 logical processors, and MultiProxy does many network I/O operations, so the CPU can schedule the I/O operation waiting time of one thread for other threads. Therefore, every logical processor can run more than one thread at the same time. The experiment measures 500 nodes in total because not all the machines in DAS5 clusters are available at the same time. Figure 5.7 shows the results of the latency and throughput performance of the network. The latency achieves around 0.52 s when the node number is under 150 and has a slight increase between 150 to 300 nodes. From 300 to 500, the latency increase to 0.68 s and the corresponding throughput decrease to 0.5 KB/s.

Latency with different node number Throughput with different node number 1.0 1.0

0.8 0.8

0.6 0.6 Latency (s) 0.4 0.4 Throughput (KB/s)

0.2 0.2

0.0 0.0 1 50 100 150 200 250 300 350 400 450 500 1 50 100 150 200 250 300 350 400 450 500 The number of Nodes The number of Nodes

(a) Latency with different node number (b) Throughput with different node number

Figure 5.7: Scalability test

66 Chapter 6

Conclusions and Future Work

6.1 Conclusions

This chapter gives the conclusions and recommendations for the research on the GFW. Section 6.1.1 concludes the research questions and highlights the main contribution of this thesis. Future work is described in section 6.2

6.1.1 Results for each research questions

RQ1: What are the current content blocking techniques?

There are four categories of Internet censorship, client-side censorship, server-side censorship, in-path censorship, and on-path censorship. This thesis selects one of the famous country-wide censorship monitoring and surveillance systems, the Great Firewall of China as the case study, so it mainly focus on in-path and on- path censorship. The GFW uses multiple modules to check and ﬁlter the undesired network trafﬁc.

The GFW has multiple levels of blocking. The blocking does not take actions in physical layers, since it is the fundamental layer underlying the higher layers and provide the physical connection requirement. In-path censorship works on the network layer, which provides the means of transferring network packets from the source to destination. IP blocking is the primary mean to intercept the traffic. It compares the destination in the packet with the access control list inside the international gateways, and by using the BGP protocol, the undesired network traffic is redirected to some random addresses or discarded. IP blocking is a simple and straight way to blocking the network traffic because the router participate directly in the routing process.

67 The on-path censorship, instead, does not directly involved in the routing path between two endpoints, it makes a copy of all the network trafﬁc, then monit- ors besides the gateways and performs man-in-the-middle attacks. It works in the transport layer which provides the host-to-host application communication. The main protocols in the transport layer are TCP and UDP protocols, the GFW still using the keyword detection for higher application layer to decide whether the trafﬁc should be blocked. For instance, the HTTP/DNS keyword detection. The TCP connection reset is used in decision phrase, that is, the GFW intercept the connections by sending the RST packets to both endpoints after TCP three-way handshake. This kind of man-in-the-middle attack is stateful, and the GFW can remember the state of connections for 90-95 seconds, which means if the client wants to reestablish the connection between the server, the handshake requests are immediately eavesdropped and blocked by the GFW, and the server-side even does not know the existence of the client. In this way, blocking becomes more effective since it only sends RST packets to the client side. The GFW mainly adopt two methods for DNS over UDP protocol: DNS hijacking and DNS poisoning, and DNS poisoning is the side-effect of the former. DNS hijacking happens when client sends requests to DNS servers in the uncensored domain. It works by wiretapping in the middle, constructing the bogus DNS response packet with wrong resolution answer inside. Since the GFW has less routing hops, this wrong address will be accepted by the client, and the correct answer arrives later is dropped by the client-side TCP/IP stack. DNS poisoning obtains the broader negative impact compared to DNS hijacking. It happens when domestic DNS server sends requests recursively, and the GFW performs DNS hijacking and injects the wrong answers into its cache. These wrong answers can stay for several minutes or days. As for DNS over TCP, the GFW uses TCP connection reset. The experiments in chapter 3 shows the proportions of different blocking techniques, although the TCP connections have the most widespread impact, the most popular websites such as Google, Instagram, Twitter, Facebook, and YouTube are IP-blocked by the GFW since they have numerous and consecutive range of IP addresses. For the DNS hijacking, the wrong answers always point to the random addresses of the service providers, such as Facebook and SoftLayer.

RQ2: What are the current anti-censorship methods?

The most prevalent censorship circumvention systems are client-server based architecture, including the VPN solutions and the proxy and the proxy solutions. The VPN works on the network layer. It works by establishing the end-to-end virtual connections through the use of the dedicated circuits, and the IP packets are encrypted through the whole connections. The proxy works on the transport layer. Proxy is weaker than the VPN on the se-

68 curity aspect, but it is more flexible, since it only processes the streams/datagrams in the higher layer and does not need to encrypt the whole IP packet. It can distinguish different network traffic. Through creating the blacklist or white list, it can quickly decide which kind of network traffic should be encrypted or not. Both the VPN and the proxy take measures to protect the messages transfers on the fly. VPN focus more on encryption, such as the authentication messages or certificates exchange. Different VPN protocols have different implementations. They can leak specific network flow features through the transmissions. Although the encryption can easily resist eavesdroppers in the middle, this does not work for the GFW, since the GFW aims at blocking the network traffic but not decrypting it. This is the reason why some VPN protocols are unstable or blocked by the GFW. The proxy use obfuscation methods to evade the monitoring of the GFW, its network traffic is more like the normal network flow between two endpoints. The proxy generally does not encrypt the header of the network layer and transport layer protocols, but only tunnel the obfuscation data inside the protocol message body, they use multiple methods like different algorithms to encrypt or randomize the tunneled messages. Some unusual protocols still can be distinguished such as the SSH protocol. As a result, most proxies use the regular HTTP or HTTPS protocols to tunnel the original requests. These client-server based solutions are easy to deploy and use, and usually obtain the low latency when in personal use, but its drawback is obvious, once it observed by the GFW, the cloud instance is immediately blocked, this will cause some loss to the user, such as service not available and they need to deploy the proxy server again from the beginning. Other applications use a distributed anonymous network, such as Tor. The clients employ some pluggable transports such as meek. This network obtains better privacy protection since the nodes in the network only have a portion of identity messages, and intermediate node only knows the addresses of its previous and next nodes. Although the last hop decapsulates the messages, it does not know the request owner. The distributed network utilizes more resources than standard client-server based architecture. The volunteer-operated servers construct a distributed network. Once the GFW blocks a circuit, the application can switch to another circuit without deploy again, and this avoids the single point failure of the proxy server. Another advantage is that Tor is free, and the usage is also easy. Users can use the Tor network by downloading the browser and use the pluggable transport in the censored domain. The drawback is obvious especially in the censored domain since the pluggable transport has the limited number of the network traffic forwarder, this causes a long waiting time for switching the circuits.

69 RQ3: How can an effective way for evading censorship be developed?

The design goal of the MultiProxy is to combine both advantages of client-server based and distributed architecture and overcome the drawbacks of the client-server based architecture, such as the single point of failure and the lack of resources.

First of all, since most popular websites are IP-blocked by the GFW, the system needs a basic traffic forwarding module, which is to provide the basic circumvention service. The architecture is similar to the client-server based CRSes. It contains a client-side proxy to receive and process messages from the originator applications, and forward these messages to the remote-side proxy. Considering the traffic forwarding protocols, Multiproxy adopts SOCKS version 5 as the protocol between the applications and the client proxy because of it is more flexible and scalable than other protocols such as the HTTP/HTTPS proxy.

Since MultiProxy also provides the privacy for request originators, it can add multiple layers/forwarders/hops in the path between the client proxy and the server proxy. To ensure there are a balanced number of nodes, MultiProxy has a token economy, which uses the Trust chain protocol as a distributed ledger, and Intel SGX prevents nodes from cheating.

RQ4: How can the performance and effectiveness of censorship evasion systems be evaluated?

The evaluation framework is described in chapter 5, and it evaluates the network and system performance of the MultiProxy in the DAS5, which is the ideal environment. The result could be considered as the best performance MultiProxy can achieve. Next, comparable research of circumvention systems is conducted by using the practical and production environment cloud instance. The results show that MultiProxy is able to evade the GFW, and it also shows the performance gaps among different CRSes. Finally, a scalability test shows to what extent the Multi- Proxy can scale up.

RQ5: What are the lessons and recommendations for circumvention?

Since the GFW is aimed at sorting out the suspicious circumvention network traffic instead of decrypting these messages in between. Therefore, some new or self- invented protocols even if they are not encrypted works for the circumvention as long as the GFW does not notice them. However, obfuscation is a better solution, since hiding or tunneling the circumvention network traffic into the standard unblockable protocols such as the domain fronting can increase the regulation dif- ficulties.

70 Concerning the network structure, since the MultiProxy is built on the peer-to- peer network, some methods should be employed to make the network environment stable, in this case, is to maintain the balance between the client and server nodes.

6.1.2 Main contributions

This thesis aims at overcoming both shortcomings of client-server based and distributed circumvention systems, i.e., the single point failure of the server proxy as well as the free-rider problems existed in an unregulated network. The main contribution of this thesis is proposed, built and evaluated a circumvention system based on the peer-to-peer network, with the token economy to balance the number of the nodes inside and outside the censored domain, and the multi-hop messaging to protect the privacy of users.

6.2 Future Work

There are still some issues that need to be addressed. First, the system needs multiple trafﬁc obfuscation methods to evade the GFW. For example, Tor builds its pluggable transport meek. Besides, MultiPorxy will need a user-friendly and con- ﬁgurable GUI interface based on the existed command-line interface.

71 72 Bibliography

[1] Eytan Adar and Bernardo A Huberman. Free riding on gnutella. First monday, 5(10), 2000. [2] Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Chris- tian Priebe, Joshua Lind, Divya Muthukumaran, Dan O’Keeffe, Mark L. Stillwell, David Goltzsche, Dave Eyers, Rudiger¨ Kapitza, Peter Pietzuch, and Christof Fetzer. SCONE: Secure linux containers with intel SGX. In 12th USENIX Symposium on Op- erating Systems Design and Implementation (OSDI 16), pages 689–703, Savannah, GA, 2016. USENIX Association. [3] Chadi Barakat, Patrick Thiran, Gianluca Iannaccone, Christophe Diot, and Philippe Owezarski. Modeling Internet backbone traffic at the flow level. IEEE Trans. Signal Process., 51(8):2111–2124, 2003. [4] Cecylia Bocovich and Ian Goldberg. Slitheen : Perfectly imitated decoy routing through traffic replacement. Ccs, 2016. [5] Cecylia Bocovich and Ian Goldberg. The road not taken: Secure asymmetry and deployability for decoy routing systems. 2016. [6] Sam Burnett, Nick Feamster, and Santosh Vempala. Chipping Away at Censorship Firewalls with User-Generated Content. Computer (Long. Beach. Calif)., pages 29– 29, 2010. [7] Bram Cohen. Incentives build robustness in bittorrent. In Workshop on Economics of Peer-to-Peer systems, volume 6, pages 68–72, 2003. [8] Ziye Deng, Zihan Liu, Zhouguo Chen, and Yubin Guo. The random forest based detection of shadowsock’s traffic. In Intelligent Human-Machine Systems and Cyber- netics (IHMSC), 2017 9th International Conference on, volume 2, pages 75–78. IEEE, 2017. [9] Lu´ıs Rodrigues Diogo Barradas,Nuno Santos. DeltaShaper: Enabling Unobservable Censorship-resistant TCP Tunneling over Videoconferencing Streams. Proc. Priv. Enhancing Technol., 2017(3):1–3, 2017. [10] Frederick Douglas, Rorshach, Weiyang Pan, and Matthew Caesar. Salmon: Robust Proxy Distribution for Censorship Circumvention. Proc. Priv. Enhancing Technol., 2016(4):4–20, 2016. [11] Roya Ensafi, David Fifield, Philipp Winter, Nick Feamster, Nicholas Weaver, and Vern Paxson. Examining how the great firewall discovers hidden circumvention servers. In Proceedings of the 2015 Internet Measurement Conference, pages 445–458. ACM, 2015.

73 [12] David Fifield, Chang Lan, Rod Hynes, Percy Wegmann, and Vern Paxson. Blocking- resistant communication through domain fronting. Proc. Priv. Enhancing Technol., 2015(2):46–64, 2015. [13] David Fifield, Lynn Tsai, and Qi Zhong. Detecting Censor Detection. 2017. [14] Sergey Frolov, Fred Douglas, Will Scott, Allison Mcdonald, Benjamin Vandersloot, Rod Hynes, Adam Kruger, Michalis Kallitsis, David G Robinson, Steve Schultze, Nikita Borisov, J Alex Halderman, and Eric Wustrow. An ISP-Scale Deployment of TapDance. pages 1–7. [15] T. He, H. Zhang, X. Li, and Z. Li. A Methodology for Analyzing Backbone Network Traffic at Stream-Level. Int. Conf. Commun. Technol. Proceedings, ICCT, 1, 2003. [16] Amir Houmansadr, Chad Brubaker, and Vitaly Shmatikov. The parrot is dead: Ob- serving unobservable network communications. Proc. - IEEE Symp. Secur. Priv., pages 65–79, 2013. [17] A Houmansadr, T J Riedl, N Borisov, and A C Singer. I want my voice to be heard: IP over Voice-over-IP for unobservable censorship circumvention. Ndss, 2013. [18] Amir Houmansadr, Wenxuan Zhou, Matthew Caesar, and Nikita Borisov. SWEET: Serving the web by exploiting email tunnels. IEEE/ACM Trans. Netw., 25(3):1517– 1527, 2017. [19] John M. (Intel). Workflow of intel sgx remote attestation, 04.07.2018. https://software.intel.com/en-us/articles/code-sample- intel-software-guard-extensions-remote-attestation-end- to-end-example. [20] Ed. J. Pouwelse. Trustchain protocol, 2018. https://tools.ietf.org/id/ draft-pouwelse-trustchain-01.html. [21] Prajakta Joshi. Premium networking topology of google cloud instances, 2017. https://cloud.google.com/blog/products/gcp/introducing- network-service-tiers-your-cloud-network-your-way. [22] Thomas Karagiannis, Andre Broido, Michalis Faloutsos, and Kc Claffy. Transport layer identification of P2P traffic. IMC ’04 Proc. 4th ACM SIGCOMM Conf. Internet Meas., pages 121–134, 2004. [23] Thomas Karagiannis, Konstantina Papagiannaki, Michalis Faloutsos, Thomas Kara- giannis, Konstantina Papagiannaki, and Michalis Faloutsos. Blinc. Proc. 2005 Conf. Appl. Technol. Archit. Protoc. Comput. Commun. - SIGCOMM ’05, 35(4):229, 2005. [24] Josh Karlin, Daniel Ellard, Alden W. Jackson, Christine E. Jones, Greg Lauer, David P. Mankins, and W. Timothy Strayer. Decoy Routing: Toward Unblockable Internet Communication. USENIX Work. Free Open Commun. Internet, 2011. [25] Yu Ju Lee and Eric Wustrow. OverTorrent: Anticensorship without centralized servers. 2016 14th Annu. Conf. Privacy, Secur. Trust. PST 2016, pages 388–391, 2016. [26] Marcus Leech, Matt Ganis, Y Lee, Ron Kuris, David Koblas, and L Jones. Socks protocol version 5. Technical report, 1996. [27] Gang Liu, Xiaochun Yun, Binxing Fang, and Mingzeng Hu. A control method for large-scale network based on routing diffusion. 2003. [28] Hui Liu, Xi Yao, and Xinpeng Li. A method and device for tcp connection reset. 2003. [29] H Mohajeri Moghaddam and B Li. SkypeMorph: Protocol obfuscation for Tor bridges. Proc. . . . , pages 97–108, 2012.

74 [30] Andrew W Moore and Konstantina Papagiannaki. Toward the accurate identification of network applications. Passiv. Act. Netw. Meas., 3431:41–54, 2005. [31] Johan Pouwelse. Trustchain protocol. Internet-Draft draft-pouwelse-trustchain-01, Internet Engineering Task Force, June 2018. Work in Progress. [32] The Tor project. The average connected clients of cymrubridge02, 2019. Accessed: 2019-03-01 https://metrics.torproject.org/rs.html# details/8F4541EEE3F2306B7B9FEF1795EC302F6B84DAE8. [33] Michael G Reed, Paul F Syverson, and David M Goldschlag. Anonymous connections and onion routing. IEEE Journal on Selected areas in Communications, 16(4):482–494, 1998. [34] Haiying Shen, Alex X. Liu, Guoxin Liu, and Lianyu Zhao. Freeweb: P2P-assisted collaborative censorship-resistant web browsing. IEEE Trans. Parallel Distrib. Syst., 27(11):3226–3241, 2016. [35] Yair Sovran, Jinyang Li, and Lakshminarayanan Subramanian. Unblocking the Inter- net : Social networks foil censors NYU Technical Report TR2008-918. pages 1–19. [36] Qingfeng Tan, Jingqiao Shi, and Bingxing Fang. Towards measuring unobservability in anonymous communication systems. 2015. [37] Tribler. Creating a 2-hop circuit in ipv8, 2018. https://github. com/Tribler/tribler/wiki/Anonymous-Downloading-and- Streaming-specifications. [38] Qiyan Wang, Giang T K Nguyen, and Nikita Borisov. CensorSpoofer : Asymmetric Communication using IP Spoofing for Censorship-Resistant Web Browsing. Proc. 2012 ACM Conf. Comput. Commun. Secur., pages 121–132, 2012. [39] Zhongjie Wang, Yue Cao, Zhiyun Qian, Chengyu Song, and Srikanth V. Krish- namurthy. Your state is not mine. Proc. 2017 Internet Meas. Conf. - IMC ’17, pages 114–127, 2017. [40] Zachary Weinberg, Jeffrey Wang, Vinod Yegneswaran, Linda Briesemeister, Steven Cheung, Frank Wang, and Dan Boneh. StegoTorus : A Camouflage Proxy for the Tor Anonymity System. Proc. 2012 ACM Conf. Comput. Commun. Secur., pages 109–120, 2012. [41] Wikipedia. Great firewall — Wikipedia, the free encyclopedia. [Online; accessed 14-March-2019]. [42] Brandon Wiley. Dust: A Blocking-Resistant Internet Transport Protocol. Defcon, 2013. [43] Philipp Winter, Tobias Pulls, and Juergen Fuss. ScrambleSuit. Proc. 12th ACM Work. Work. Priv. Electron. Soc. - WPES ’13, pages 213–224, 2013. [44] Eric Wustrow. Telex : Anticensorship in the Network Infrastructure. Design, 10(August):1–15, 2011. [45] Xueyang Xu, Z. Morley Mao, and J. Alex Halderman. Internet censorship in China: Where does the filtering occur? Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes Bioinformatics), 6579 LNCS:133–142, 2011. [46] Ruixi Yuan, Zhu Li, Xiaohong Guan, and Li Xu. An svm-based machine learning method for accurate internet traffic classification. Information Systems Frontiers, 12(2):149–156, 2010. [47] Tao Zhu, David Phipps, Adam Pridgen, Jedidiah R. Crandall, and Dan S. Wallach. The Velocity of Censorship: High-Fidelity Detection of Microblog Post Deletions. 2013.

75 76 Acronyms

ACL Access Control List. 12 AS Autonomous system. 13

BGP Border Gateway Protocol. 12

CAS Conﬁguration and Attestation Service. 51 CRS Censorship resistance system. 8

DAS5 The Distributed ASCI Supercomputer 5. 59 DNS Domain Name System. 13 DPI Deep packet inspection. 17 DTLS Datagram Transport Layer Security. 60

FQDN Fully Qualiﬁed Domain Name. 24

GFW Great Firewall of China. v, 1, 5, 12

HTTP Hypertext Transfer Protocol. 13 HTTPS Hypertext Transfer Protocol Secure. 13

ICMP Internet Control Message Protocol. 24 IP Internet Protocol. 16 ISP Internet Service Provider. 16

MAC Media access control. 31 MITM Man-in-the -middle attack. 45

77 MX Mail exchanger. 33

NS Name Server. 33

OSPF Open Shortest Path First. 13

P2P Peer-to-Peer. 1, 14

RTT Round-trip time. 58

SGX Intel Software Guard Extensions. 48 SNI Server Name Indication. 6, 20 SOA Start of Authority. 33 SSH Secure Shell. 13

TCP Transmission Control Protocol. 17 TLS Transport Layer Security. 20 TTL Time to Live. 27, 30

UDP User Datagram Protocol. 17

VPN Virtual Private Network. 36, 60 VPS Virtual Private Server. 29