RFC 9505

A Survey of Worldwide Censorship Techniques ✨

• Stream: Internet Research Task Force (IRTF) 🌈
• Request for Comments: 9505
• Category: Informational
• ISSN: 2070-1721
• Date: November 2023
• Authors: J. L. Hall (Internet Society), M. D. Aaron (CU Boulder), A. Andersdotter, B. Jones, N. Feamster (U Chicago), M. Knodel (Center for Democracy & Technology) 👑
• Obsoletes / Updates: Nothing is listed in the title block for either one 🧚

---

Abstract 💅

Okay bestie, this doc is all about the technical tricks that governments and other regimes around the world use to block or slow down Internet traffic 😭. The whole point is to help designers, implementers, and users of Internet protocols understand which properties get exploited and which mechanisms get used to censor what people can access. It doesn't give any advice on individual protocol considerations. It's purely informational, a reference you can lean on 📚. It was made by the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF 🦋.

Status of This Memo 🎀

This is not an Internet Standards Track specification. It's published for informational purposes, so it's not a standard, just really good research 🤓.

The IRTF publishes the results of Internet-related research and development work, and those results might not be suitable for deployment 🙈. This RFC represents the consensus of the Privacy Enhancements and Assessments Research Group of the IRTF. Documents approved for publication by the IRSG are not candidates for any level of Internet Standard. See Section 2 of RFC 7841 for the details 💜.

If you want the current status, any errata, or a way to send feedback, check out https://www.rfc-editor.org/info/rfc9505 🔗.

Copyright Notice 🌸

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved 🦋.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜.

Table of Contents 🗺️

   1.  Introduction
   2.  Terminology
   3.  Technical Prescription
   4.  Technical Identification
     4.1.  Points of Control
     4.2.  Application Layer
       4.2.1.  HTTP Request Header Identification
       4.2.2.  HTTP Response Header Identification
       4.2.3.  Transport Layer Security (TLS)
       4.2.4.  Instrumenting Content Distributors
       4.2.5.  DPI Identification
     4.3.  Transport Layer
       4.3.1.  Shallow Packet Inspection and Transport Header
               Identification
       4.3.2.  Protocol Identification
     4.4.  Residual Censorship
   5.  Technical Interference
     5.1.  Application Layer
       5.1.1.  DNS Interference
     5.2.  Transport Layer
       5.2.1.  Performance Degradation
       5.2.2.  Packet Dropping
       5.2.3.  RST Packet Injection
     5.3.  Routing Layer
       5.3.1.  Network Disconnection
       5.3.2.  Adversarial Route Announcement
     5.4.  Multi-layer and Non-layer
       5.4.1.  Distributed Denial of Service (DDoS)
       5.4.2.  Censorship in Depth
   6.  Non-technical Interference
     6.1.  Manual Filtering
     6.2.  Self-Censorship
     6.3.  Server Takedown
     6.4.  Notice and Takedown
     6.5.  Domain Name Seizures
   7.  Future Work
   8.  IANA Considerations
   9.  Security Considerations
   10. Informative References
   Acknowledgments
   Authors' Addresses

---

1. Introduction ✨

Censorship is when an entity in a position of power, like a government, an organization, or an individual, suppresses communication it considers objectionable, harmful, sensitive, or inconvenient [WP-Def-2020]. Censors who do this have to go through legal, martial, or other means, but this document focuses mostly on the technical mechanisms used to pull off network censorship 💻🔒.

This document describes the technical mechanisms that censorship regimes around the world use to block or impair Internet traffic. If you want the bigger-picture version, where blocking and filtering are discussed in terms of what they mean for Internet architecture instead of end-user access to content and services, see [RFC7754] 🏛️. There's also a growing field of academic study on censorship circumvention (see the review article of [Tschantz-2016]), and this document wants to bring those results to protocol designers and implementers 🧠💖.

Censorship circumvention also affects how much a censorship measure costs to implement, so we include notes on trade-offs related to those costs alongside each technical method below 💸.

This document has been through a lot of discussion and review in the IRTF Privacy Enhancement and Assessment Research Group (PEARG), and it represents that group's consensus 🫶. It is not an IETF product and it is not a standard 🙅‍♀️.

2. Terminology 📖

There are three elements of Internet censorship: prescription, identification, and interference. This document has three major sections, one for each of those elements 🎀. Prescription is how censors decide what types of material to censor, like labeling pornographic websites as undesirable. Identification is how censors pick out specific traffic or traffic identifiers to block or impair. For example, deciding that webpages with "sex" in an HTTP header, or that accept traffic through the URL "www.sex.example", are likely to be undesirable is identification 👀. Interference is where censors step in and stop people from reaching censored material, by blocking access or slowing down the connection. Think of a technical solution that can spot HTTP headers or URLs and makes them wholly or partially inaccessible 🚫.

3. Technical Prescription 🧁

Prescription is the process of figuring out what censors would like to block [Glanville-2008]. Censors usually gather information "to block" into blocklists, which are databases of image hashes [ekr-2021], or they use real-time heuristic assessment of content [Ding-1999]. Some national networks are designed so they naturally serve as points of control [Leyba-2019]. There are also signs that online censors use probabilistic machine learning techniques [Tang-2016]. Honestly, web crawling and machine learning are a hot research area for finding content that's considered morally or commercially harmful to companies or consumers in some places [SIDN-2020] 🤖🔥.

There are usually a few types of blocklist elements: keyword, domain name, protocol, or IP address 🗂️. Keyword and domain name blocking happen at the application level, like with HTTP. Protocol blocking often uses deep packet inspection (DPI) to spot a forbidden protocol. IP blocking tends to use IP addresses in IPv4/IPv6 headers 🕵️‍♀️. Some censors also use certain keywords to enable more aggressive blocklists [Rambert-2021], or to be more permissive with content [Knockel-2021] 🌀.

Blocklists get built in different ways. Censors can buy "content control" software from private industry, which lets them filter broad categories they want blocked, like gambling or pornography [Knight-2005]. In these cases, the private services try to categorize every semi-questionable website so they can do meta-tag blocking. They also tune their real-time content heuristic systems to map assessments onto categories of objectionable content 💅.

Countries that care a lot about keeping specific political control usually have ministries or organizations that maintain blocklists. Examples include the Ministry of Industry and Information Technology in China, the Ministry of Culture and Islamic Guidance in Iran, and the organizations in France that handle copyright law [HADOPI], plus the consumer protection law organizations across the EU [Reda-2017] 🇪🇺✨.

Content-layer filtering of images and video means institutions or organizations have to store hashes of the images or videos to be blocked in databases. Then content sent, received, or stored through centralized content applications and services can be compared against those hashes, with some degree of tolerance [ekr-2021] 🖼️💜.

4. Technical Identification ✨

Okay so the Internet doesn't just get censored in one spot, bestie. Censorship can happen literally everywhere in the network topology 🦋 It can live in the network itself (like the local loop or backhaul), on the services side (web hosts, cloud providers, CDNs), in the ancillary services crew (DNS or certificate authorities), or on the end-client side, like your phone, laptop, or desktop, or any software running on them 💻 The big thing is that censors need software or hardware to intercept the stuff they care about. Here are the main points of control they can use, and this list isn't the whole list 👀

4.1. Points of Control ✨

Internet censorship takes place in all parts of the network topology. It may be implemented in the network itself (e.g., local loop or backhaul), on the services side of communication (e.g., web hosts, cloud providers, or content delivery networks), in the ancillary services ecosystem (e.g., domain name system (DNS) or certificate authorities (CAs)), or on the end-client side (e.g., in an end-user device, such as a smartphone, laptop, or desktop, or software executed on such devices). An important aspect of pervasive technical interception is the necessity to rely on software or hardware to intercept the content the censor is interested in. There are various logical and physical points of control that censors may use for interception mechanisms, including, though not limited to, the following:

Internet Backbone: Okay, the backbone is giving main character energy 🌐 If a censor controls parts of the Internet's infrastructure, like the international gateways into a region or Internet Exchange Points (IXPs), those choke points can be used to filter undesirable traffic going into and out of the region by packet sniffing and port mirroring. Censorship at gateways is most effective at controlling the flow of information between a region and the rest of the Internet, but it's ineffective at identifying content moving between users within a region, which would have to happen at exchange points or other network aggregation points. Some national network designs naturally serve as more effective choke points and points of control [Leyba-2019] 🧚

Internet Service Providers (ISPs): ISPs are literally so exploited, ngl 😭 They're really easy for a censor to list out, often falling under the jurisdictional or operational control of a censor in a totally undeniable way. Plus, an ISP can see the regional and international traffic of all their users 👀 The censor's filtration mechanisms can be placed on an ISP through governmental mandates, ownership, or voluntary/coercive influence.

Institutions: Schools, corporations, and internet cafes are giving gatekeeper vibes 🎀 Private institutions like these can use filtration mechanisms too. Sometimes that's at the request of a government censor, but it can also be done to hit institutional goals, like fostering a particular moral outlook on life in schoolchildren, independent of broader society or government goals.

Content Distribution Network (CDN): CDNs are so clever 🌸 They try to collapse network topology so content sits closer to the service's users. That cuts content transmission latency and improves QoS. But the CDN's content servers, sitting "close" to the user in a network sense, can be seriously powerful points of control for censors, especially if where the CDN repositories live makes interference easier 💅

CAs for Public Key Infrastructures (PKIs): This one's a big deal 💀 Authorities that issue cryptographically secured resources can be a significant point of control. CAs that issue certificates to domain holders for TLS/HTTPS (the Web PKI), or Regional or Local Internet Registries (RIRs or LIRs) that issue Route Origin Authorizations (ROAs) to BGP operators, can be forced to issue rogue certificates. That may allow compromise, meaning censorship software can do identification and interference where it couldn't before 😱 CAs may also be forced to revoke certificates. This may lead to adversarial traffic routing, TLS interception being allowed, or an otherwise rightful origin or destination point of traffic flows being unable to communicate in a secure way 🫶

Services: Services are basically the new focal point of the censorship drama 🔥 Application service providers can be pressured, coerced, or legally required to censor specific content or data flows. Service providers naturally want to maximize their potential customer base, and potential shutdowns or legal liability from censorship efforts may seem way less attractive than just excluding content, users, or uses of their service. Services have increasingly become focal points of censorship discussions, as well as discussions of moral imperatives to use censorship tools.

Content Sites: On the service side of communications, there are lots of platforms that publish user-generated content and require terms of service compliance with all content and user accounts, so they can avoid intermediary liability for the web hosts. Together, these policies, actions, and remedies are known as content moderation. Content moderation happens above the services or application layer, but these mechanisms are built to filter, sort, and block content and users, which makes them available to censors through direct pressure on the private entity 🍓

Personal Devices: Devices are a whole mood 📱 Censors can mandate that censorship software be installed at the device level. This has many disadvantages in terms of scalability, ease of circumvention, and operating system requirements. (Of course, if a personal device is treated with censorship software before sale and this software is difficult to reconfigure, this may work in favor of those seeking to control information, say, for children, students, customers, or employees 🙈) The emergence of mobile devices has made these feasibility problems even worse. This software can also be mandated by institutional actors acting on non-governmentally mandated moral imperatives.

At all levels of the network hierarchy, the filtration mechanisms used to censor undesirable traffic are essentially the same. A censor either directly identifies undesirable content using the identifiers described below and then uses a blocking or shaping mechanism (such as the ones exemplified below to prevent or impair access), or it requests that an actor ancillary to the censor (such as a private entity) perform these functions. Identification of undesirable traffic can occur at the application, transport, or network layer of the IP stack. Censors often focus on web traffic, so the relevant protocols tend to get filtered in predictable ways (see Sections 4.2.1 and 4.2.2). For example, a subversive image might make it past a keyword filter. However, if the image is later deemed undesirable, a censor may then blocklist the provider site's IP address 🚫

4.2. Application Layer 🎀

The following subsections describe properties and trade-offs of common ways censors filter using application-layer information. Each subsection includes empirical examples describing these common behaviors for further reference 📚

---

4.2.1. HTTP Request Header Identification 🌈

An HTTP header contains a lot of useful information for traffic identification. Although "host" is the only required field in an HTTP request header (for HTTP/1.1 and later), an HTTP method field is necessary to do anything useful. So "method" and "host" are the two fields used most often for ubiquitous censorship 👑 A censor can sniff traffic and identify a specific domain name (host), and usually a page name (for example, GET /page) as well. This identification technique is usually paired with transport header identification (see Section 4.3.1) for a more robust method 💜

Trade-offs: HTTP request header identification is a technically straightforward method that can be easily implemented at the backbone or ISP level. The hardware needed for this is cheap and easy to get, which makes it desirable when budget and scope are a concern 🍓 HTTPS (Hypertext Transport Protocol Secure) encrypts the relevant request and response fields, so pairing with transport identification (see Section 4.3.1) is necessary for HTTPS filtering. However, some countermeasures can trivially defeat simple forms of HTTP request header identification. For example, two cooperating endpoints (an instrumented web server and client) could encrypt or otherwise obfuscate the "host" header in a request, potentially thwarting techniques that match against "host" header values 🦋

Empirical Examples: Studies exploring censorship mechanisms have found evidence of HTTP header and/or URL filtering in many countries, including Bangladesh, Bahrain, China, India, Iran, Malaysia, Pakistan, Russia, Saudi Arabia, South Korea, Thailand, and Turkey [Verkamp-2012] [Nabi-2013] [Aryan-2013]. Commercial technologies are often purchased by censors [Dalek-2013]. These commercial technologies use a combination of HTTP request header identification and transport header identification to filter specific URLs. Dalek et al. and Jones et al. identified the use of these products in the wild [Dalek-2013] [Jones-2014] 🌸

---

4.2.2. HTTP Response Header Identification 💅

While HTTP request header identification relies on the information in the HTTP request from client to server, HTTP response header identification uses information the server sends back to the client to identify undesirable content 🔍

Trade-offs: Just like HTTP request header identification, the techniques used to identify HTTP traffic are well-known, cheap, and relatively easy to implement. However, they're made useless by HTTPS, because HTTPS encrypts the response and its headers 💀

The response fields are also less helpful for identifying content than request fields. "Server" could easily be identified using HTTP request header identification, and "Via" is rarely relevant 🙄 HTTP response censorship mechanisms normally let the first n packets through while the mirrored traffic is being processed. This may allow some content through, and the user may be able to detect that the censor is actively interfering with undesirable content 👀

Empirical Examples: In 2009, Jong Park et al. at the University of New Mexico demonstrated that the Great Firewall of China (GFW) has used this technique [Crandall-2010]. However, Jong Park et al. found that the GFW discontinued this practice during the course of the study. Due to the overlap between HTTP response filtering and keyword filtering (see Section 4.2.4), it is likely that most censors rely on keyword filtering over TCP streams instead of HTTP response filtering 🧚

---

4.2.3. Transport Layer Security (TLS) 🔐

Similar to HTTP, censors have deployed a variety of techniques for censoring TLS (and by extension HTTPS). Most of these techniques relate to the Server Name Indication (SNI) field, including censoring SNI, Encrypted SNI (ESNI), or omitted SNI 🫣 Censors can also censor HTTPS content via server certificates. Note that TLS 1.3 acts as a security component of QUIC ✨

4.2.3.1. Server Name Indication (SNI) 🌸

okay bestie, so with encrypted TLS, one machine can host a bunch of "virtual servers" at the same network address 🏠✨. That means the client has to say which domain it wants in the ClientHello message, so the server knows which TLS certificate to send back. It does that with the SNI TLS extension [RFC6066] 💅. The ClientHello is unencrypted for TCP-based TLS 🫣. With QUIC it's encrypted, but that doesn't really keep it private, because the initial encryption keys are derived from a value that's visible on the wire 😭. SNI is usually sent in the clear, and so are the cert fields sent back in the response. That makes them super useful for censors and filtering software, which can use them to block, filter, or impair connections by dropping traffic to domains that match prohibited content. For example, bad.foo.example might get censored while good.foo.example doesn't 💀 [Shbair-2015].

There's ongoing work in the TLS Working Group to encrypt SNI [RFC8744] [TLS-ESNI] 🔐, and recent research shows promising results for using ESNI against SNI-based filtering in some countries [Chai-2019] 🌈.

Domain fronting has been a popular way to dodge censors [Fifield-2015] 🦋. The trick is that apps put a different domain in the SNI extension than in the host header, and the host header is protected by HTTPS. The SNI shows an unblocked domain, and the blocked domain stays hidden inside the encrypted app header 🫥. Some encrypted messaging services leaned on this to work in countries with SNI-based filtering. They hid their real domain names behind domains where blocking at the domain level would be undesirable 🙈. However, the companies running those popular domains have since reconfigured their software to stop this practice, so that's a no-go now 🚫. It may be possible to get similar results with future options for encrypting SNI.

Trade-offs: some clients don't send the SNI extension, like clients that only support SSL and not TLS. That makes this method useless for them (see Section 4.2.3.3) 🥲. Also, this technique needs deep packet inspection (DPI), which can get really expensive in computing power and infrastructure. It's especially painful with QUIC, since DPI there needs key extraction and decryption of the ClientHello just to read the SNI 💸. Messing up an SNI-based block can cause huge over-blocking, like when a second-level domain such as populardomain.example gets blocked by accident 😬. With ESNI, the pressure to censor can shift to other points of intervention, like content and application providers 🔄.

Empirical Examples: there are lots of security firms that sell SNI-based filtering products [Trustwave-2015] [Sophos-2023] [Shbair-2015] 🛡️. China, Egypt, Iran, Qatar, South Korea, Turkey, Turkmenistan, and the United Arab Emirates all do widespread SNI filtering or blocking [OONI-2018] [OONI-2019] [NA-SK-2019] [CitizenLab-2018] [Gatlan-2019] [Chai-2019] [Grover-2019] [Singh-2019] 🗺️. SNI blocking against QUIC traffic was first spotted in Russia in March 2022 [Elmenhorst-2022] 👀.

4.2.3.2. Encrypted SNI (ESNI) 🧁

Since SNI leaks data, the natural fix is to encrypt it, which is coming in TLS 1.3 with Encrypted Client Hello (ECH) ✨. Until then, the ESNI extension can stop the leak by encrypting only the SNI field 🔒. Unfortunately, censors can target connections that use the ESNI extension specifically. That guarantees over-blocking for the censor, but it can still be worth the cost if ESNI isn't widely deployed in their country yet 😤. ECH is the emerging standard for protecting the entire TLS ClientHello, but it isn't widely deployed yet 🌱.

Trade-offs: censoring ESNI costs a censor way more than censoring SNI, since the censor can't aim at specific domains anymore and over-blocking is guaranteed 💰. In these cases, the censor uses that over-blocking to scare people off ESNI entirely 🫠.

Empirical Examples: in 2020, China started censoring all uses of ESNI [Bock-2020b], even for totally innocent connections 😭. China's ESNI censorship works differently from how it censors SNI-based connections, which suggests new middleboxes were deployed just to target ESNI connections 🕵️‍♀️.

4.2.3.3. Omitted SNI 🫥

Researchers have seen some clients leave out the SNI extension entirely. That limits what a censor can see 👀. Like with ESNI, censors can choose to block connections that omit the SNI, though this also risks over-blocking 🙃.

Trade-offs: censoring every connection that omits the SNI field is guaranteed to over-block, though connections that omit the SNI field should be relatively rare in the wild 🌿.

Empirical Examples: researchers have seen censors in Russia blocking connections that omit the SNI field in the past [Bock-2020b] 🇷🇺.

4.2.3.4. Server Response Certificate 📜

During the TLS handshake, after the ClientHello, the server responds with the TLS certificate. That certificate also contains the domain the client is trying to reach, which gives censors yet another way to censor 🫣. This technique won't work in TLS 1.3, because the certificate will be encrypted 🔐.

Trade-offs: censoring based on the server certificate needs DPI techniques that are more computationally expensive than other methods 🧮. Plus, the certificate shows up later in the TLS handshake than the SNI field does, so the censor has to track the connection for longer 😩.

Empirical Examples: researchers have seen the Reliance Jio ISP in India using certificate response fields to censor connections [Satija-2021] 🇮🇳.

4.2.4. Instrumenting Content Distributors 🎀

Lots of governments pressure content providers to censor themselves, or they set up the legal framework that pushes content distributors to follow the content restriction preferences of outside agents [Boyle-1997] 🏛️. Because this censorship can reach so far, we define "content distributor" as any service that gives users some kind of utility, from websites to storage to locally installed programs 📦✨.

A popular way to instrument content distributors is keyword identification, which detects restricted terms on their platforms 🔍. Governments may provide the terms on these keyword lists. Otherwise, the content provider may be expected to come up with their own list 📝.

A growing method is hash matching, which detects and takes action against images and videos that are known to be restricted, whether by governments, institutions, organizations, or the distributor itself [ekr-2021] 🖼️.

Another method is requiring a distributor to disassociate from certain categories of users. See also Section 6.4 🚫.

Trade-offs: by instrumenting content distributors to find restricted content or content providers, the censor gets new information, but it costs them political capital with the companies they force or encourage to take part 🪙. For example, the censor can learn what encrypted traffic is about by coercing websites to spot restricted content 👁️. Making content distributors regulate users, categories of users, content, and content providers can push users and content providers into self-censorship, which is another win for censors (see Section 6.2) 🤐. How good or bad these trade-offs are depends a lot on the content provider and the help being asked for. A typical worry is that the targeted keywords or user categories are too broad, risk being applied too broadly, or aren't backed by a robust enough legal process before they're mandatorily applied (see page 8 of [EC-2012]) ⚖️.

Empirical Examples: researchers have found keyword identification by content providers on everything from instant messaging apps [Senft-2013] to search engines [Rushe-2014] [Cheng-2010] [Whittaker-2013] [BBC-2013] [Condliffe-2013] 💬. To show how common this is, let's look at search engine censorship 🔎.

Search engine censorship is a clear example of keyword identification by content providers, and it can be regional or worldwide 🌍. It's sometimes voluntary, but it's usually based on the laws and regulations of the country where the search engine operates 📜. The keyword blocklists are most likely maintained by the search engine provider. China is known to require search engine providers to "voluntarily" maintain search term blocklists so they can get and keep an Internet Content Provider (ICP) license [Cheng-2010] 🇨🇳. It's pretty clear each provider maintains its own list, based on the slight differences in the searches that get intercepted [Zhu-2011] [Whittaker-2013] 🧐. The United Kingdom has been pushing search engines to self-censor by threatening litigation if they don't do it themselves. Google and Microsoft agreed to block more than 100,000 queries in the U.K. to help combat abuse [BBC-2013] [Condliffe-2013] 🇬🇧. European Union law, as well as United States law, requires search engine results to be modified in response to copyright, trademark, data protection, or defamation concerns [EC-2012] ⚖️.

Depending on the output, search engine keyword identification can be easy or hard to detect. In some cases, specialized or blank results give a trivial way to enumerate the blocked terms, but more subtle censorship is tough to spot 🕵️. In February 2015, Microsoft's search engine, Bing, was accused of censoring Chinese content outside of China [Rushe-2014], because Bing returned different results for censored terms in Chinese and English 😳. However, it's possible that censorship of China, the largest base of Chinese search users, biased Bing's results so the more popular results in China (the uncensored ones) were also more popular for Chinese speakers outside of China 🤔.

Disassociation by content distributors from certain categories of users has happened in Spain, for instance, because of the conflict between the Catalan independence movement and the Spanish legal presumption of a unitary state [Lomas-2019] 🇪🇸. E-sport event organizers have also cut ties with top players who shared political opinions about the 2019 Hong Kong protests [Victor-2019] 🎮. See also Section 5.3.1 💜.

4.2.5. DPI Identification 🔍

Okay bestie, so DPI (deep packet inspection) technically means any packet analysis that goes beyond IP addresses and port numbers. It only became computationally feasible as a censorship tool pretty recently [Wagner-2009] 😭. Unlike the other techniques, DPI reassembles network flows so it can look at the application "data" section, not just the headers. That's why it's so often used for keyword identification 👀. DPI is also next level because it can use extra packet and flow characteristics, like packet sizes and timings, to figure out what content it's looking at ✨. To avoid big QoS impacts, DPI usually analyzes a copy of the data while the original packets keep getting routed 🧚. Typically the traffic gets split with a mirror switch or fiber splitter, then analyzed on a cluster of machines running Intrusion Detection Systems (IDSs) that are configured for censorship 💅.

Trade-offs: DPI is one of the most expensive identification mechanisms and can have a large QoS impact [Porter-2005] 💸. When it's used as a keyword filter for TCP flows, DPI systems can also cause major over-blocking problems 🙈. Like the other techniques, DPI is less useful against encrypted data. BUT it can still pick up unencrypted bits of an encrypted flow, like the Server Name Indication (SNI) that gets sent in the clear for TLS, or metadata about the flow, like packet sizes (video and text flows look different, iykyk) 🎀. See Section 4.2.3.1 for more information about SNI-based filtration mechanisms.

Other stuff can be inferred by comparing certain unencrypted elements exchanged during TLS handshakes to similar data points from known sources. This is called "TLS fingerprinting", and it lets a censor make a probabilistic guess about a party's operating system, browser, or application 🕵️‍♀️. It works by comparing the specific combos of TLS version, ciphersuites, compression options, etc., sent in the ClientHello message to similar signatures found in unencrypted traffic [Husak-2016]. Lowkey spooky, but iconic 🦋.

Despite all of this, DPI is the most powerful identification method and it's widely used in practice 👑. The Great Firewall of China (GFW), the largest censorship system in the world, uses DPI to identify restricted content over HTTP and DNS. It then injects TCP RSTs and bad DNS responses into connections, respectively [Crandall-2010] [Clayton-2006] [Anonymous-2014]. Not okay, but very well engineered 💀.

Empirical Examples: Several studies have found evidence of censors using DPI to censor content and tools 🌸. Clayton et al., Crandal et al., Anonymous, and Khattak et al. all explored the GFW [Crandall-2010] [Clayton-2006] [Anonymous-2014]. Khattak et al. even probed the firewall to figure out implementation details, like how much state it stores 🔎 [Khattak-2013]. The Tor project claims that China, Iran, Ethiopia, and others must have used DPI to block the obfs2 protocol [Wilde-2012]. Malaysia has been accused of using targeted DPI, paired with DDoS, to identify and then attack pro-opposition material [Wagstaff-2013]. It also seems likely that organizations that aren't so worried about blocking content in real time could use DPI to sort and categorically search gathered traffic, using technologies like high-speed packet processing [Hepting-2011] 🍓.

---

4.3. Transport Layer 🚚

4.3.1. Shallow Packet Inspection and Transport Header Identification

Of all the shallow packet inspection methods, transport header identification is the most pervasive, reliable, and predictable type of identification 💖. Transport headers hold a few invaluable pieces of info that must be transparent for traffic to be routed successfully: destination and source IP address and port. The destination and source IP are doubly useful! Not only do they let a censor block unwanted content through IP blocklisting, they also let a censor identify the IP of the user making the request and the IP address of the destination being visited. In most cases, that can be used to infer the domain being visited [Patil-2019] 🕵️‍♀️. The port is useful for allowlisting certain applications 🌈.

By combining the IP address, port, and protocol info found in the transport header, shallow packet inspection can be used by a censor to identify specific TCP or UDP endpoints 🎯. UDP endpoint blocking has been observed in the context of QUIC blocking [Elmenhorst-2021].

Trade-offs: Header identification is popular because it's simple, available, and robust 🫶.

Header identification is trivial to implement in some routers, but it's difficult to implement at scale in backbone or ISP routers. That's why it's typically implemented with DPI 🧠. Blocklisting an IP is equivalent to installing a specific route on a router, like a /32 route for IPv4 addresses or a /128 route for IPv6 addresses. The catch? Due to limited flow table space, this can't scale beyond a few thousand IPs at most 😬. IP blocking is also pretty crude. It often leads to over-blocking, and it can't deal with services like Content Distribution Networks (CDNs) that host content at hundreds or thousands of IP addresses. Despite these limitations, IP blocking is extremely effective, because the user needs to proxy their traffic through another destination to get around this type of identification 🔥. On top of that, IP blocking is effective against all protocols above IP, e.g., TCP and QUIC.

Port blocking is generally not very useful, because lots of types of content share the same port, and censored applications can just change their port 🙃. For example, most HTTP traffic goes over port 80, so the censor can't tell restricted web content apart from allowed web content just by looking at the port. HTTPS goes over port 443, with similar consequences for the censor, except that only partial metadata may be available to them now 🔐. Port allowlisting is occasionally used, where a censor limits communication to approved ports (such as 80 for HTTP traffic). It works best when combined with other identification mechanisms. For example, a censor could block the default HTTPS port (443), which forces most users to fall back to HTTP 🧩. A counterexample is port 25 (SMTP). It has long been blocked on residential ISP networks to reduce the risk of email spam, but doing that also stops residential ISP customers from running their own email servers 📧.

4.3.2. Protocol Identification

Censors sometimes identify entire protocols to block, using a variety of traffic characteristics 🕶️. For example, Iran impairs the performance of HTTPS traffic (a protocol that prevents further analysis) to encourage users to switch to HTTP (a protocol they can analyze) [Aryan-2013]. A simple protocol identification would be to recognize all TCP traffic over port 443 as HTTPS. A more sophisticated analysis of the statistical properties of payload data and flow behavior would be more effective, though, even when port 443 isn't used [Hjelmvik-2010] [Sandvine-2015].

If censors can detect circumvention tools, they can block them. So censors like China are extremely interested in identifying the protocols used by censorship circumvention tools 🥷. In recent years this has turned into a competition between censors and circumvention tool developers 🏁. As part of that competition, China developed an extremely effective protocol identification technique that researchers call "active probing" or "active scanning" 🧪.

In active probing, the censor figures out whether hosts are running a circumvention protocol by trying to start communicating using that protocol. If the host and the censor successfully negotiate a connection, then the censor conclusively knows the host is running a circumvention tool 😱. China has used active scanning to great effect to block Tor [Winter-2012].

Trade-offs: Protocol identification only tells you about the way information is traveling, not the information itself 📦.

Protocol identification is useful for detecting and blocking circumvention tools (like Tor), or traffic that's difficult to analyze (like Voice over IP (VoIP) or SSL), because the censor can assume that this traffic should be blocked. However, this can lead to over-blocking when used with popular protocols 🙈. These methods are expensive, both computationally and financially, since they use statistical analysis, and they can be ineffective because they're so imprecise 💸.

Censors have also used protocol identification in an "allowlist" filtering capacity. For example, they only allow specific, pre-vetted protocols and block any unrecognized ones [Bock-2020] 🛂. These protocol filtering approaches can also lead to over-blocking if the allowed lists are too small or incomplete, but they can be cheap to implement, since many standard "allowed" protocols are simple to identify (HTTP is a classic example) ✅.

Empirical Examples: Protocol identification can be easy to detect if it's conducted in real time and only one particular protocol is blocked 👀. Some types of protocol identification, like active scanning, are much harder to detect 🫥. Iran has used protocol identification to identify and throttle Secure Shell (SSH) traffic, making it unusable [Van-der-Sar-2007]. China has used it to identify and block Tor relays [Winter-2012]. Protocol identification has also been used for traffic management. In the 2007 case, Comcast in the United States used RST injection (injecting a TCP RST packet into the stream) to interrupt BitTorrent traffic [Winter-2012] 🚫. In 2020, Iran deployed an allowlist protocol filter that only allowed three protocols (DNS, TLS, and HTTP) on specific ports, and it censored any connection it couldn't identify [Bock-2020]. In 2022, Russia seemed to have used protocol identification to block most HTTP/3 connections [Elmenhorst-2022] 🥀.

4.4. Residual Censorship 🎀

Okay so residual censorship is the petty ex of censorship 💀. A censor blocks your forbidden connection, and then it keeps messing with your later connections, even totally innocent ones [Bock-2021]. It can take lots of forms, and it often uses the technical interference methods from the next section 🫶.

The big question is what the censor keeps blocking after it first kicks in. An adversary has three common choices: a 2-tuple (client IP, server IP), a 3-tuple (client IP, server IP, server port), or a 4-tuple (client IP, client port, server IP, server port). Any future connection that matches whatever tuple the censor recorded gets disrupted [Bock-2021] 😤.

Residual censorship can be super hard to spot, and it can really complicate censorship measurement 😭.

Trade-offs: The impact of residual censorship is to give users extra discouragement from trying to access forbidden content, though it is not clear how successful it is at doing that 🙈.

Empirical Examples: China has used 3-tuple residual censorship alongside its HTTP censorship for years, and researchers have reported seeing similar residual censorship for HTTPS. China seems to use a mix of 3-tuple and 4-tuple residual censorship for its censorship of HTTPS with ESNI. Some censors that perform censorship via packet dropping often accidentally implement 4-tuple residual censorship, including Iran and Kazakhstan [Bock-2021] 🌈.

---

5. Technical Interference 💅

5.1. Application Layer 🌸

5.1.1. DNS Interference 🧚

There are a variety of ways censors can block or filter access to content by altering DNS responses [AFNIC-2013] [ICANN-SSAC-2012], including blocking the response, replying with an error message, or responding with an incorrect address. Note that there are now encrypted transports for DNS queries, like DNS over HTTPS [RFC8484] and DNS over TLS [RFC7858], that can mitigate interference with DNS queries between the stub and the resolver 🔐✨.

Responding to a DNS query with an incorrect address can be achieved with on-path interception, off-path cache poisoning, or lying by the name server 👀.

"DNS mangling" is a network-level technique of on-path interception where an incorrect IP address is returned in response to a DNS query for a censored destination. Some Chinese networks, for example, do this. (We are not aware of any other wide-scale uses of mangling.) On those Chinese networks, each DNS request in transit is examined (presumably by network inspection technologies such as DPI), and if it matches a censored domain, a false response is injected. End users can see this in action by simply sending DNS requests to any unused IP address in China (see example below). If it is not a censored name, there will be no response. If it is censored, a forged response will be returned. For example, using the command-line dig utility to query an unused IP address in China of 192.0.2.2 for the name "www.uncensored.example" compared with "www.censored.example" (censored at the time of writing), we get a forged IP address "198.51.100.0" as a response:

% dig +short +nodnssec @192.0.2.2 A www.uncensored.example
;; connection timed out; no servers could be reached

% dig +short +nodnssec @192.0.2.2 A www.censored.example
198.51.100.0

DNS cache poisoning happens off-path. It refers to a mechanism where a censor interferes with the response sent by an authoritative DNS name server to a recursive resolver by responding more quickly than the authoritative name server can, with an alternative IP address [Halley-2008] 🏃‍♀️💨. Cache poisoning occurs after the requested site's name servers resolve the request and attempt to forward the true IP back to the requesting device. On the return route, the resolved IP is recursively cached by each DNS server that initially forwarded the request. During this caching process, if an undesirable keyword is recognized, the resolved IP is "poisoned", and an alternative IP (or NXDOMAIN error) is returned more quickly than the upstream resolver can respond. That causes a forged IP address to be cached (and potentially recursively so). The alternative IPs usually direct to a nonsense domain or a warning page. Alternatively, Iranian censorship appears to prevent the communication en route, so a response is never sent at all [Aryan-2013] 🚫.

There are also cases of what is colloquially called "DNS lying," where a censor mandates that the DNS responses provided by an operator of a recursive resolver, such as an Internet Access Provider, be different from what an authoritative name server would provide [Bortzmeyer-2015] 🤥.

Trade-offs: These forms of DNS interference require the censor to force a user to traverse a controlled DNS hierarchy (or an intervening network on which the censor serves as an active pervasive attacker [RFC7624] to rewrite DNS responses) for the mechanism to be effective. DNS interference can be circumvented by using alternative DNS resolvers (such as any of the public DNS resolvers) that may fall outside of the jurisdictional control of the censor, or by using Virtual Private Network (VPN) technology. DNS mangling and cache poisoning also imply returning an incorrect IP to those attempting to resolve a domain name, but in some cases the destination may be technically accessible. For example, over HTTP, the user may have another method of obtaining the IP address of the desired site, and may be able to access it if the site is configured to be the default server listening at this IP address. Target blocking has also been a problem, as occasionally users outside of the censor's region will be directed through DNS servers or DNS-rewriting network equipment controlled by a censor, causing the request to fail. The ease of circumvention paired with the large risk of content blocking and target blocking make DNS interference a partial, difficult, and less-than-ideal censorship mechanism 😬.

Additionally, the above mechanisms rely on DNSSEC not being deployed, or on DNSSEC validation not being active on the client or recursive resolver. Neither of those is hard to imagine, given limited deployment of DNSSEC and limited client support for DNSSEC validation 🥱. Note that an adversary seeking to merely block resolution can serve a DNSSEC record that doesn't validate correctly, assuming of course that the client or recursive resolver validates 🧐.

Previously, techniques relied on DNS requests being passed in cleartext over port 53 [SSAC-109-2020]. With the deployment of encrypted DNS (e.g., DNS over HTTPS [RFC8484]), these requests are now increasingly passed on port 443 with other HTTPS traffic, or, in the case of DNS over TLS [RFC7858], they are no longer passed in the clear (see also Section 4.3.1) 🔒💖.

Empirical Examples: DNS interference, when properly implemented, is easy to identify based on the shortcomings identified above. Turkey relied on DNS interference for its country-wide block of websites, including Twitter and YouTube, for almost a week in March of 2014. The ease of circumvention resulted in an increase in the popularity of Twitter until Turkish ISPs implemented an IP blocklist to achieve the governmental mandate [Zmijewski-2014]. Ultimately, Turkish ISPs started hijacking all requests to Google and Level 3's international DNS resolvers [Zmijewski-2014]. DNS interference, when incorrectly implemented, has resulted in some of the largest censorship disasters 💀. In January 2014, China started directing all requests passing through the Great Fire Wall to a single domain, "dongtaiwang.com", due to an improperly configured DNS poisoning attempt. This incident is thought to be the largest Internet service outage in history [AFP-2014] [Anon-SIGCOMM12] 😱. Countries such as China, Turkey, and the United States have discussed blocking entire Top-Level Domains (TLDs) as well [Albert-2011] 🌍. DNS blocking is commonly deployed in European countries to deal with undesirable content, such as:

• child abuse content (Norway, United Kingdom, Belgium, Denmark, Finland, France, Germany, Ireland, Italy, Malta, the Netherlands, Poland, Spain, and Sweden [Wright-2013] [Eneman-2010]),
• online gambling (Belgium, Bulgaria, Czech Republic, Cyprus, Denmark, Estonia, France, Greece, Hungary, Italy, Latvia, Lithuania, Poland, Portugal, Romania, Slovakia, Slovenia, and Spain (see Section 6.3.2 of [EC-gambling-2012], [EC-gambling-2019])),
• copyright infringement (all European Economic Area countries),
• hate speech and extremism (France [Hertel-2015]), and
• terrorism content (France [Hertel-2015]).

5.2. Transport Layer 🦋

5.2.1. Performance Degradation 🐢

While other interference techniques outlined in this section mostly focus on blocking or preventing access to content, it can be an effective censorship strategy in some cases to not entirely block access to a given destination or service, but instead to degrade the performance of the relevant network connection. The resulting user experience for a site or service under performance degradation can be so bad that users opt for a different site, service, or method of communication, or they may not engage in communication at all if there are no alternatives 😩. Traffic-shaping techniques that rate-limit the bandwidth available to certain types of traffic are one example of performance degradation 🚦.

Trade-offs: While implementing a performance degradation will not always eliminate people's ability to access a desired resource, it may force them to use other means of communication where censorship (or surveillance) is more easily accomplished 👻.

Empirical Examples: Iran has been known to shape the bandwidth available to HTTPS traffic to encourage unencrypted HTTP traffic [Aryan-2013] 🫠.

5.2.2. Packet Dropping ✨

okay so packet dropping is simple but lowkey iconic 💅. The censor spots the undesirable traffic and just doesn't properly forward any packets it sees that are tied to that traffic, instead of following a normal routing protocol 🙅‍♀️. This can be stacked with any of the mechanisms we already covered, as long as the censor knows the user has to route traffic through a controlled router 🎯.

Trade-offs: packet dropping slays most when every packet passing through has transparent info linked to undesirable content, like a destination IP 👀. The downside is that the censor has to block all content from otherwise allowable IPs because of one sus subdomain 😭. Blogging services and GitHub repositories are perfect examples. China famously dropped all GitHub packets for three days because of a single repository hosting undesirable content [Anonymous-2013] 💀. And inspecting every packet in almost real time makes packet dropping kinda challenging from a QoS perspective 🥲.

Empirical Examples: packet dropping is a super common form of technical interference, and it's easy to detect because of the unique timeout requests it leaves behind in its wake 🔍. The Great Firewall of China has been observed using packet dropping as one of its primary technical censorship mechanisms [Ensafi-2013] 🇨🇳. Iran has also used packet dropping as the mechanism for throttling SSH [Aryan-2013]. These are just two examples of a ubiquitous censorship practice 🌍. Notably, packet dropping during the handshake or working connection is the only interference technique observed for QUIC traffic to date (e.g., in India, Iran, Russia, and Uganda [Elmenhorst-2021] [Elmenhorst-2022]) 🦋.

5.2.3. RST Packet Injection 💫

Packet injection, generally, is a machine-in-the-middle (MITM) network interference technique that spoofs packets in an established traffic stream 🕵️‍♀️. RST packets are normally used to let one side of a TCP connection know the other side has stopped sending information and that the receiver should close the connection 👋. RST packet injection is a specific type of packet injection attack used to interrupt an established stream by sending RST packets to both sides of a TCP connection. Since each receiver thinks the other has dropped the connection, the session gets terminated 💔.

QUIC is not vulnerable to these types of injection attacks once the connection has been set up 🛡️. While QUIC implements a stateless reset mechanism, such a reset is only accepted by a peer if the packet ends in a previously issued (stateless reset) token, which is difficult to guess 🔐. During the handshake, QUIC only provides effective protection against off-path attackers but is vulnerable to injection attacks by attackers that have parsed prior packets. (See [RFC9000] for more details.)

Trade-offs: although ineffective against non-TCP protocols (QUIC, IPsec), RST packet injection has a few advantages that make it extremely popular as a censorship technique 🔥. It's an out-of-band interference mechanism, which avoids the QoS bottleneck you can hit with inline techniques like packet dropping 🏃‍♀️. This out-of-band property lets a censor inspect a copy of the information, usually mirrored by an optical splitter, making it an ideal pairing for DPI and protocol identification [Weaver-2009]. (This asynchronous version of a MITM is often called a machine-on-the-side (MOTS).) RST packet injection also only requires one of the two endpoints to accept the spoofed packet for the connection to be interrupted 🎀.

The difficult part is spoofing "enough" correct information to make one endpoint accept a RST packet as legitimate. This generally implies a correct IP, port, and TCP sequence number 🧩. The sequence number is the hardest to get right, since [RFC9293] specifies that a RST packet should be in sequence to be accepted, although that RFC also recommends allowing in-window packets 🤔. This in-window recommendation is a big deal. If it's implemented, it allows for successful Blind RST Injection attacks [Netsec-2011] 😳. When in-window sequencing is allowed, it's trivial to conduct a Blind RST Injection. While the term "blind" implies the censor doesn't know any sensitive sequencing info about the TCP stream they're injecting into, they can simply enumerate all ~70000 possible windows 🙃. This is particularly useful for interrupting encrypted/obfuscated protocols such as SSH or Tor [Gilad]. Some censorship evasion systems work by trying to confuse the censor into tracking incorrect information, rendering their RST packet injection useless [Khattak-2013] [Wang-2017] [Li-2017] [Bock-2019] [Wang-2020] 🥷.

RST packet injection relies on a stateful network, making it useless against UDP connections 🙅. It's among the most popular censorship techniques used today, given its versatile nature and effectiveness against all types of TCP traffic 👑. Recent research shows that a TCP RST packet injection attack can even work in the case of an off-path attacker [Cao-2016] 🫣.

Empirical Examples: RST packet injection, as mentioned above, is most often paired with identification techniques that require splitting, such as DPI or protocol identification 📦. In 2007, Comcast was accused of using RST packet injection to interrupt traffic it identified as BitTorrent [Schoen-2007], which subsequently led to a US Federal Communications Commission ruling against Comcast [VonLohmann-2008] 📜. China has also been known to use RST packet injection for censorship purposes. This interference is especially evident in the interruption of encrypted/obfuscated protocols, such as those used by Tor [Winter-2012] 🧅.

---

5.3. Routing Layer 🗺️

5.3.1. Network Disconnection 📴

While it's perhaps the crudest of all censorship techniques, there's no more effective way of making sure undesirable information isn't allowed to propagate on the web than shutting off the network 🫥. The network can be logically cut off in a region when a censoring entity withdraws all of the Border Gateway Protocol (BGP) prefixes routing through the censor's country 🚫.

Trade-offs: the impact of a network disconnection in a region is huge and absolute. The censor pays for absolute control over digital information by losing the benefits a globally accessible Internet brings 💸. Network disconnections are also politically expensive, since citizens accustomed to accessing Internet platforms and services see such disconnections as a loss of civil liberty 😤. Network disconnection is rarely a long-term solution for any censor and is normally only used as a last resort in times of substantial civil unrest 🫠.

Empirical Examples: network disconnections tend to only happen in times of substantial unrest, largely due to the huge social, political, and economic impact such a move has 📉. One of the first, highly covered occurrences was when the junta in Myanmar employed network disconnection to help junta forces quash a rebellion in 2007 [Dobie-2007]. China disconnected the network in the Xinjiang region during unrest in 2009 in an effort to prevent the protests from spreading to other regions [Heacock-2009]. The Arab Spring saw the most frequent usage of network disconnection, with events in Egypt and Libya in 2011 [Cowie-2011] and Syria in 2012 [Thomson-2012] 🌍. Russia indicated that it would attempt to disconnect all Russian networks from the global Internet in April 2019 as part of a test of the nation's network independence. Reports also indicate that, as part of the test disconnect, Russian telecommunications firms must now route all traffic to state-operated monitoring points [Cimpanu-2019] 👀. India saw the largest number of Internet shutdowns per year in 2016 and 2017 [Dada-2017] 🇮🇳.

5.3.2. Adversarial Route Announcement 📡

More fine-grained and potentially wide-spread censorship can be achieved with BGP hijacking, which adversarially re-routes BGP IP prefixes incorrectly within a region and beyond 🎯. This restricts and effectively censors the correctly known location of information that flows into or out of a jurisdiction, and it will similarly prevent people from outside your jurisdiction from viewing content generated outside that jurisdiction as the adversarial route announcement propagates 🚧. The first can be achieved by an adversarial BGP announcement of incorrect routes that are not intended to leak beyond a jurisdiction, whereas the latter attacks traffic by deliberately introducing bogus BGP announcements that reach the global Internet 💥.

Trade-offs: a global leak of a misrouted website can overwhelm an ISP if the website gets a lot of traffic 😵. It is not a permanent solution, because incorrect BGP routes that leak globally can be fixed, but leaks within a jurisdiction can only be corrected by an ISP/IXP for local users 🛠️.

Empirical Examples: In 2008, Pakistan Telecom censored YouTube at the request of the Pakistan government by changing its BGP routes for the website. The new routes were announced to the ISP's upstream providers and beyond. The entire Internet began directing YouTube routes to Pakistan Telecom and continued doing so for many hours 😱. In 2018, nearly all Google services and Google Cloud customers, like Spotify, all lost more than one hour of service after Google lost control of several million of its IP addresses. Those IP prefixes were being misdirected to China Telecom, a Chinese government-owned ISP [Google-2018], in a manner similar to the BGP hijacking of US government and military websites by China Telecom in 2010 🥹. ISPs in both Russia (2022) and Myanmar (2021) have tried to hijack the same Twitter prefix more than once [Siddiqui-2022] 🐦.

5.4. Multi-layer and Non-layer 🧩

5.4.1. Distributed Denial of Service (DDoS) 💥

Okay bestie, DDoS is the go-to move for "hacktivists" and sketchy hackers 😭, and censors have used it too, for all kinds of reasons 🫠. There's a whole wild variety of DDoS attacks [Wikip-DoS] ✨, but at a high level, two impacts usually show up. A flood attack makes the service unusable because all the resources are getting burned on flooding it 🌊. A crash attack tries to crash the service so resources can be reallocated elsewhere without "releasing" the service 💀.

Trade-offs: DDoS is super appealing when a censor wants to block all access (not just regional access) to undesirable content for a limited time ⏳. Temporary is honestly the only uniquely good thing it has going for it as a censorship technique 💅. Pulling off a successful DDoS against major targets is computationally expensive and usually means renting or owning a malicious distributed platform like a botnet 🤖, and it's pretty imprecise too. DDoS is an incredibly crude censorship technique 🙈. It seems to be mostly used as a quick, easy-to-access way to block undesirable content for a limited period.

Empirical Examples: In 2012, the U.K.'s signals intelligence organization, the Government Communications Headquarters (GCHQ), used DDoS to temporarily shut down Internet Relay Chat (IRC) chat rooms frequented by members of Anonymous. They used the Syn Flood DDoS method 😳. Syn Flood exploits the handshake used by TCP to overload the victim server with so many requests that legitimate traffic becomes slow or impossible [NBC-2014] [CERT-2000]. Dissenting opinion websites are frequently DDoS victims around politically sensitive events, like the DDoS in Burma [Villeneuve-2011] 🎀. Controlling parties in Russia [Kravtsova-2012], Zimbabwe [Orion-2013], and Malaysia [Muncaster-2013] have been accused of using DDoS to interrupt opposition support and access during elections 🗳️. And in 2015, China launched a DDoS attack using a true MITM system (dubbed "Great Cannon"), collocated with the Great Firewall. It could inject JavaScript code into web visits to a Chinese search engine, and it commandeered those user agents to send DDoS traffic to various sites [Marczak-2015]. The main character energy of that one is unmatched 😭🔥.

5.4.2. Censorship in Depth 🧅

Censors often stack multiple techniques together, which is called "censorship in depth" 🧅. It can look like a bunch of different things. Some censors block the same content with multiple techniques at once, like blocking a domain by DNS, IP blocking, and HTTP all together 🔒. Some deploy parallel systems to make censorship more reliable, like using several different censorship systems to block the same domain 🛡️. And others use complementary systems to limit evasion, like blocking unwanted protocols entirely so users have to fall back on other filtered protocols 🚫.

Trade-offs: Censorship in depth is attractive for censors to deploy, because it offers extra guarantees: even if someone evades one type of censorship, they may still get blocked by another 🥲. The main downside is the cost of the initial deployment, since the system has to deploy multiple censorship systems in tandem 💸.

Empirical Examples: Censorship in depth is present in many large censoring nation states today 🌍. Researchers have observed that China has deployed significant censorship in depth, often censoring the same resource across multiple protocols [Chai-2019] [Bock-2020b], or deploying additional censorship systems to censor the same content and protocol [Bock-2021b]. Iran has also deployed a complementary protocol filter to limit which protocols can be used on certain ports. That forces users to rely on protocols their censorship system can filter [Bock-2020] 🙃.

---

6. Non-technical Interference 🌸

6.1. Manual Filtering 🗂️

As the name implies, sometimes manual labor is the easiest way to figure out what to block 👀. Manual filtering is different from the common tactic of building up blocklists, because it doesn't necessarily target a specific IP or DNS. Instead, it removes or flags content. Automatic filtering is pretty imprecise, so manually sorting through content and flagging dissenting websites, blogs, articles, and other media for filtration can be super effective on its own 🧐. It can also be combined with other automated detection techniques, followed by an action that requires manual confirmation ✅. This filtration can happen at the backbone or ISP level. China's army of monitors is a good example [BBC-2013b] 🫡, but more commonly, manual filtering happens at an institutional level 🏢. ICPs, like Google or Weibo, need a business license to operate in China 📜. One of the prerequisites for that license is agreeing to sign a "voluntary pledge" known as the "Public Pledge on Self-discipline for the Chinese Internet Industry" ✍️. If an ICP fails to "energetically uphold" the pledged values, the Chinese government can hold it liable for the offending content [BBC-2013b] 😬.

6.2. Self-Censorship 🤐

Self-censorship is hard to document, because it shows up mainly as a lack of undesirable content 👻. Tools that encourage self-censorship may lead a prospective speaker to believe that speaking up increases the risk of unfavorable outcomes for them (technical monitoring, identification requirements, etc.) 😰. Reporters Without Borders show off methods of imposing self-censorship in their annual World Press Freedom Index reports [RWB-2020] 📰.

6.3. Server Takedown 🖥️

As mentioned in passing by [Murdoch-2008], servers have to have a physical location somewhere in the world 🌏. If undesirable content is hosted in the censoring country, the servers can be physically seized. Or, if a server is virtualized in a cloud infrastructure where it may not have a fixed physical location, the hosting provider can be required to prevent access ☁️.

6.4. Notice and Takedown 📬

In many countries, there are legal mechanisms where an individual or other content provider can issue a legal request to a content host that requires the host to take content down 📨. Examples include the systems companies like Google use to comply with "Right to be Forgotten" policies in the European Union [Google-RTBF], intermediary liability rules for electronic platform providers [EC-2012], or the copyright-oriented notice and takedown regime of the United States Digital Millennium Copyright Act (DMCA) Section 512 [DMLP-512] ⚖️.

6.5. Domain Name Seizures 🌐

Domain names are catalogued in name servers operated by legal entities called registries 📚. These registries can be made to cede control over a domain name to someone other than the entity that registered it, through a legal procedure grounded in either private contracts or public law 🧾. Domain name seizure is increasingly used by both public authorities and private entities to deal with undesired content dissemination [ICANN-2012] [EFF-2017] 💀.

7. Future Work 🔮

In addition to establishing a thorough resource for describing censorship techniques, this document points out critical areas for future work 💜.

Taken as a whole, the apparent costs of implementing censorship techniques show we need better classification of censorship regimes as they evolve and mature 📈, and better specification of censorship circumvention techniques themselves 🛠️. Censor maturity refers to the technical maturity a censor needs to perform a specific censorship technique. Future work might classify techniques by how hard a censor has to work, including what infrastructure is required, to successfully censor content, users, or services 🧠.

On circumvention: the increase in protocols leveraging encryption is an effective countermeasure against some forms of censorship described in this document 🔐. But thorough research on circumvention and encryption is left for another document 📎. Also, the censorship circumvention community has developed an area of research on "pluggable transports." These collect, document, and make agile methods for obfuscating the on-path traffic of censorship circumvention tools, so it appears indistinguishable from other kinds of traffic [Tor-2019] 🦋. Those methods would benefit from future work in the Internet standards community, too 🙌.

Lastly, the empirical examples show that censorship techniques can evolve quickly, and experience shows this document can only be a point-in-time statement ⏰. Future work might extend this document with updates and new techniques described using a comparable methodology 🌱.

8. IANA Considerations 🦄

This document has no IANA actions ✨.

9. Security Considerations 🚨

This document is a survey of existing literature on network censorship techniques. As such, it does not introduce any new security considerations to be taken into account beyond what is already discussed in each paper surveyed 🛡️. Stay alert, these papers hold the real drama! 😤

10. Informative References 📚

[AFNIC-2013]
              AFNIC, "Report of the AFNIC Scientific Council:
              Consequences of DNS-based Internet filtering", January
              2013,
              <http://www.afnic.fr/medias/documents/conseilscientifique/
              SC-consequences-of-DNS-based-Internet-filtering.pdf>.

[AFP-2014] AFP, "China Has Massive Internet Breakdown Reportedly
              Caused By Their Own Censoring Tools", January 2014,
              <http://www.businessinsider.com/chinas-internet-breakdown-
              reportedly-caused-by-censoring-tools-2014-1>.

[Albert-2011]
              Albert, K., "DNS Tampering and the new ICANN gTLD Rules",
              June 2011, <https://opennet.net/blog/2011/06/dns-
              tampering-and-new-icann-gtld-rules>.

[Anon-SIGCOMM12]
              Anonymous, "The Collateral Damage of Internet Censorship
              by DNS Injection", July 2012,
              <http://www.sigcomm.org/sites/default/files/ccr/
              papers/2012/July/2317307-2317311.pdf>.

[Anonymous-2013]
              Anonymous, "GitHub blocked in China - how it happened, how
              to get around it, and where it will take us", January
              2013, <https://en.greatfire.org/blog/2013/jan/github-
              blocked-china-how-it-happened-how-get-around-it-and-where-
              it-will-take-us>.

[Anonymous-2014]
              Anonymous, "Towards a Comprehensive Picture of the Great
              Firewall's DNS Censorship", August 2014,
              <https://www.usenix.org/system/files/conference/foci14/
              foci14-anonymous.pdf>.

[Aryan-2013]
              Aryan, S., Aryan, H., and J. A. Halderman, "Internet
              Censorship in Iran: A First Look", 2012,
              <https://jhalderm.com/pub/papers/iran-foci13.pdf>.

[BBC-2013] BBC News, "Google and Microsoft agree steps to block abuse
              images", November 2013,
              <http://www.bbc.com/news/uk-24980765>.

[BBC-2013b]
              BBC, "China employs two million microblog monitors state
              media say", 2013,
              <https://www.bbc.com/news/world-asia-china-24396957>.

[Bock-2019]
              Bock, K., Hughey, G., Qiang, X., and D. Levin, "Geneva:
              Evolving Censorship Evasion Strategies",
              DOI 10.1145/3319535.3363189, November 2019,
              <https://geneva.cs.umd.edu/papers/geneva_ccs19.pdf>.

Okay bestie, here come the last of the sources, and yes, the citations stay exactly as written. 🫶📚

• [Bock-2020] Bock, K., Fax, Y., Reese, K., Singh, J., and D. Levin, "Detecting and Evading Censorship-in-Depth: A Case Study of Iran's Protocol Filter", January 2020, https://geneva.cs.umd.edu/papers/evading-censorship-in-depth.pdf. 🔍
• [Bock-2020b] Bock, K., iyouport, Anonymous, Merino, L-H., Fifield, D., Houmansadr, A., and D. Levin, "Exposing and Circumventing China's Censorship of ESNI", August 2020, https://geneva.cs.umd.edu/posts/china-censors-esni/esni/. 🇨🇳
• [Bock-2021] Bock, K., Bharadwaj, P., Singh, J., and D. Levin, "Your Censor is My Censor: Weaponizing Censorship Infrastructure for Availability Attacks", DOI 10.1109/SPW53761.2021.00059, May 2021, https://geneva.cs.umd.edu/papers/woot21-weaponizing-availability.pdf. ⚔️
• [Bock-2021b] Bock, K., Naval, G., Reese, K., and D. Levin, "Even Censors Have a Backup: Examining China's Double HTTPS Censorship Middleboxes", FOCI '21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 1-7, DOI 10.1145/3473604.3474559, August 2021, https://geneva.cs.umd.edu/papers/foci21.pdf. 🎀
• [Bortzmeyer-2015] Bortzmeyer, S., "DNS Censorship (DNS Lies) As Seen By RIPE Atlas", December 2015, https://labs.ripe.net/Members/stephane_bortzmeyer/dns-censorship-dns-lies-seen-by-atlas-probes. 🌐
• [Boyle-1997] Boyle, J., "Foucault in Cyberspace: Surveillance, Sovereignty, and Hardwired Censors", 66 University of Cincinnati Law Review 177-205, 1997, https://scholarship.law.duke.edu/faculty_scholarship/619/. 📜
• [Cao-2016] Cao, Y., Qian, Z., Wang, Z., Dao, T., Krishnamurthy, S., and L. Marvel, "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous", August 2016, https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf. 💥
• [CERT-2000] CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks", 2000, https://vuls.cert.org/confluence/display/historical/CERT+Advisory+CA-1996-21+TCP+SYN+Flooding+and+IP+Spoofing+Attacks. 🚨
• [Chai-2019] Chai, Z., Ghafari, A., and A. Houmansadr, "On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention", 2019, https://www.usenix.org/system/files/foci19-paper_chai_update.pdf. 🔐
• [Cheng-2010] Cheng, J., "Google stops Hong Kong auto-redirect as China plays hardball", June 2010, http://arstechnica.com/tech-policy/2010/06/google-tweaks-china-to-hong-kong-redirect-same-results/. 🤼
• [Cimpanu-2019] Cimpanu, C., "Russia to disconnect from the internet as part of a planned test", February 2019, https://www.zdnet.com/article/russia-to-disconnect-from-the-internet-as-part-of-a-planned-test/. 🔌
• [CitizenLab-2018] Marczak, B., Dalek, J., McKune, S., Senft, A., Scott-Railton, J., and R. Deibert, "Bad Traffic: Sandvine's PacketLogic Devices Used to Deploy Government Spyware in Turkey and Redirect Egyptian Users to Affiliate Ads?", March 2018, https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/. 🕵️‍♀️
• [Clayton-2006] Clayton, R., Murdoch, S.J., and R.N.M. Watson, "Ignoring the Great Firewall of China", Lecture Notes in Computer Science, Volume 4258, DOI 10.1007/11957454_2, 2006, https://link.springer.com/chapter/10.1007/11957454_2. 🧱
• [Condliffe-2013] Condliffe, J., "Google Announces Massive New Restrictions on Child Abuse Search Terms", November 2013, http://gizmodo.com/google-announces-massive-new-restrictions-on-child-abus-1466539163. 🔎
• [Cowie-2011] Cowie, J., "Egypt Leaves The Internet", NANOG 51, February 2011, https://archive.nanog.org/meetings/nanog51/presentations/Tuesday/LT-Cowie-Egypt%20Leaves%20The%20Internet.pdf. 🇪🇬
• [Crandall-2010] Park, J.C. and J. Crandall, "Empirical Study of a National-Scale Distributed Intrusion Detection System: Backbone-Level Filtering of HTML Responses in China", June 2010, http://www.cs.unm.edu/~crandall/icdcs2010.pdf. 📊
• [Dada-2017] Dada, T. and P. Micek, "Launching STOP: the #KeepItOn internet shutdown tracker", September 2017, https://www.accessnow.org/keepiton-shutdown-tracker/. 📈
• [Dalek-2013] Dalek, J., Haselton, B., Noman, H., Senft, A., Crete-Nishihata, M., Gill, P., and R. J. Deibert, "A Method for Identifying and Confirming the Use of URL Filtering Products for Censorship", IMC '13: Proceedings of the 2013 conference on Internet measurement conference, Pages 23-30, DOI 10.1145/2504730.2504763, October 2013, http://conferences.sigcomm.org/imc/2013/papers/imc112s-dalekA.pdf. 🧪
• [Ding-1999] Ding, C., Chi, C. H., Deng, J., and C. L. Dong, "Centralized Content-Based Web Filtering and Blocking: How Far Can It Go?", IEEE SMC'99 Conference Proceedings, DOI 10.1109/ICSMC.1999.825218, October 1999, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.132.3302&rep=rep1&type=pdf. 🗂️
• [DMLP-512] Digital Media Law Project, "Protecting Yourself Against Copyright Claims Based on User Content", May 2012, https://www.dmlp.org/legal-guide/protecting-yourself-against-copyright-claims-based-user-content. ⚖️
• [Dobie-2007] Dobie, M., "Junta tightens media screw", BBC News, September 2007, http://news.bbc.co.uk/2/hi/asia-pacific/7016238.stm. 📰
• [EC-2012] European Commission, "Summary of the results of the Public Consultation on the future of electronic commerce in the Internal Market and the implementation of the Directive on electronic commerce (2000/31/EC)", January 2012, https://ec.europa.eu/information_society/newsroom/image/document/2017-4/consultation_summary_report_en_2010_42070.pdf. 🇪🇺
• [EC-gambling-2012] European Commission, "Online gambling in the Internal Market Accompanying the document Communication from the Commission to the European Parliament, the Council, the Economic and Social Committee and the Committee of the Regions Towards a comprehensive framework for online gambling", 2012, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52012SC0345. 🎲
• [EC-gambling-2019] European Commission, "Evaluation of regulatory tools for enforcing online gambling rules and channelling demand towards controlled offers", January 2019, https://ec.europa.eu/growth/content/evaluation-regulatory-tools-enforcing-online-gambling-rules-and-channelling-demand-towards-1_en. 🃏
• [EFF-2017] Malcom, J., Rossi, G., and M. Stoltz, "Which Internet registries offer the best protection for domain owners?", Electronic Frontier Foundation, July 2017, https://www.eff.org/files/2017/08/02/domain_registry_whitepaper.pdf. 🛡️
• [ekr-2021] Rescorla, E., "Overview of Apple's Client-side CSAM Scanning", August 2021, https://educatedguesswork.org/posts/apple-csam-intro/. 🍎
• [Elmenhorst-2021] Elmenhorst, K., Schuetz, B., Aschenbruck, N., and S. Basso, "Web Censorship Measurements of HTTP/3 over QUIC", IMC '21: Proceedings of the 21st ACM Internet Measurement Conference, Pages 276-282, DOI 10.1145/3487552.3487836, November 2021, https://dl.acm.org/doi/pdf/10.1145/3487552.3487836. 🚀
• [Elmenhorst-2022] Elmenhorst, K., "A Quick Look at QUIC Censorship", April 2022, https://www.opentech.fund/news/a-quick-look-at-quic/. 👀
• [Eneman-2010] Eneman, M., "Internet service provider (ISP) filtering of child-abusive material: A critical reflection of its effectiveness", DOI 10.1080/13552601003760014, June 2010, https://www.tandfonline.com/doi/abs/10.1080/13552601003760014. 🧐
• [Ensafi-2013] Ensafi, R., Knockel, J., Alexander, G., and J.R. Crandall, "Detecting Intentional Packet Drops on the Internet via TCP/IP Side Channels: Extended Version", DOI 10.48550/arXiv.1312.5739, December 2013, http://arxiv.org/pdf/1312.5739v1.pdf. 🕳️
• [Fifield-2015] Fifield, D., Lan, C., Hynes, R., Wegmann, P., and V. Paxson, "Blocking-resistant communication through domain fronting", DOI 10.1515/popets-2015-0009, May 2015, https://petsymposium.org/2015/papers/03_Fifield.pdf. 🦋
• [Gatlan-2019] Gatlan, S., "South Korea is Censoring the Internet by Snooping on SNI Traffic", February 2019, https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/. 🇰🇷
• [Gilad] Gilad, Y. and A. Herzberg, "Off-Path TCP Injection Attacks", ACM Transactions on Information and System Security, Volume 16, Issue 4, Article No.: 13, pp. 1-32, DOI 10.1145/2597173, April 2014, https://doi.org/10.1145/2597173. 💉
• [Glanville-2008] Glanville, J., "The big business of net censorship", The Guardian, November 2008, http://www.theguardian.com/commentisfree/2008/nov/17/censorship-internet. 💸
• [Google-2018] "Google Cloud Networking Incident #18018", November 2018, https://status.cloud.google.com/incident/cloud-networking/18018. ☁️
• [Google-RTBF] Google, Inc., "Search removal request under data protection law in Europe", 2015, https://support.google.com/legal/contact/lr_eudpa?product=websearch. 🧹
• [Grover-2019] Grover, G., Singh, K., and E. Hickok, Ed., "Reliance Jio is using SNI inspection to block websites", November 2019, https://cis-india.org/internet-governance/blog/reliance-jio-is-using-sni-inspection-to-block-websites. 🇮🇳
• [HADOPI] Hadopi, "Hadopi | Haute Autorité pour la diffusion des oeuvres et la protection des droits sur internet", https://www.hadopi.fr/. 🇫🇷
• [Halley-2008] Halley, B., "How DNS cache poisoning works", October 2008, https://www.networkworld.com/article/2277316/tech-primers/tech-primers-how-dns-cache-poisoning-works.html. 🧃

okay the receipts keep coming 📚💅 these are the sources, no cap

[Heacock-2009] Heacock, R., "China shuts down Internet in Xinjiang region after riots", OpenNet Initiative, July 2009, https://opennet.net/blog/2009/07/china-shuts-down-internet-xinjiang-region-after-riots.

[Hepting-2011] Wikipedia, "Hepting v. AT&T", September 2023, https://en.wikipedia.org/wiki/Hepting_v._AT%26T&oldid=1175143505.

[Hertel-2015] Hertel, O., "Comment les autorités peuvent bloquer un site Internet" [How authorities can block a website], March 2015, https://www.sciencesetavenir.fr/high-tech/comment-les-autorites-peuvent-bloquer-un-site-internet_35828.

[Hjelmvik-2010] Hjelmvik, E. and W. John, "Breaking and Improving Protocol Obfuscation", Technical Report No. 2010-05, ISSN 1652-926X, July 2010, https://www.iis.se/docs/hjelmvik_breaking.pdf.

[Husak-2016] Husák, M., Čermák, M., Jirsík, T., and P. Čeleda, "HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting", DOI 10.1186/s13635-016-0030-7, February 2016, https://link.springer.com/article/10.1186/s13635-016-0030-7.

[ICANN-2012] ICANN Security and Stability Advisory Committee, "Guidance for Preparing Domain Name Orders, Seizures & Takedowns", January 2012, https://www.icann.org/en/system/files/files/guidance-domain-seizures-07mar12-en.pdf.

[ICANN-SSAC-2012] ICANN Security and Stability Advisory Committee (SSAC), "SAC 056: SSAC Advisory on Impacts of Content Blocking via the Domain Name System", October 2012, https://www.icann.org/en/system/files/files/sac-056-en.pdf.

[Jones-2014] Jones, B., Lee, T-W., Feamster, N., and P. Gill, "Automated Detection and Fingerprinting of Censorship Block Pages", IMC '14: Proceedings of the 2014 Conference on Internet Measurement Conference, Pages 299-304, DOI 10.1145/2663716.2663722, November 2014, http://conferences2.sigcomm.org/imc/2014/papers/p299.pdf.

[Khattak-2013] Khattak, S., Javed, M., Anderson, P.D., and V. Paxson, "Towards Illuminating a Censorship Monitor's Model to Facilitate Evasion", August 2013, http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/12389-foci13-khattak.pdf.

[Knight-2005] Knight, W., "Iranian net censorship powered by US technology", June 2005, https://www.newscientist.com/article/dn7589-iranian-net-censorship-powered-by-us-technology/.

[Knockel-2021] Knockel, J. and L. Ruan, "Measuring QQMail's automated email censorship in China", FOCI '21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 8-15, DOI 10.1145/3473604.3474560, April 2021, https://dl.acm.org/doi/10.1145/3473604.3474560.

[Kravtsova-2012] Kravtsova, Y., "Cyberattacks Disrupt Opposition's Election", The Moscow Times, October 2012, http://www.themoscowtimes.com/news/article/cyberattacks-disrupt-oppositions-election/470119.html.

[Leyba-2019] Leyba, K., Edwards, B., Freeman, C., Crandall, J., and S. Forrest, "Borders and gateways: measuring and analyzing national as chokepoints", COMPASS '19: Proceedings of the 2nd ACM SIGCAS Conference on Computing and Sustainable Societies, pages 184-194, DOI 10.1145/3314344.3332502, July 2019, https://doi.org/10.1145/3314344.3332502.

[Li-2017] Li, F., Razaghpanah, A., Molavi Kakhki, A., Akhavan Niaki, A., Choffnes, D., Gill, P., and A. Mislove, "lib•erate, (n): a library for exposing (traffic-classification) rules and avoiding them efficiently", DOI 10.1145/3131365.3131376, November 2017, https://david.choffnes.com/pubs/liberate-imc17.pdf.

[Lomas-2019] Lomas, N., "Github removes Tsunami Democràtic's APK after a takedown order from Spain", October 2019, https://techcrunch.com/2019/10/30/github-removes-tsunami-democratics-apk-after-a-takedown-order-from-spain/.

[Marczak-2015] Marczak, B., Weaver, N., Dalek, J., Ensafi, R., Fifield, D., McKune, S., Rey, A., Scott-Railton, J., Deibert, R., and V. Paxson, "An Analysis of China's "Great Cannon"", August 2015, https://www.usenix.org/system/files/conference/foci15/foci15-paper-marczak.pdf.

[Muncaster-2013] Muncaster, P., "Malaysian election sparks web blocking/DDoS claims", The Register, May 2013, http://www.theregister.co.uk/2013/05/09/malaysia_fraud_elections_ddos_web_blocking/.

[Murdoch-2008] Murdoch, S. J. and R. Anderson, "Tools and Technology of Internet Filtering" in "Access Denied: The Practice and Policy of Global Internet Filtering", DOI 10.7551/mitpress/7617.003.0006, 2008, https://doi.org/10.7551/mitpress/7617.003.0006.

[NA-SK-2019] Morgus, R., Sherman, J., and S. Nam, "Analysis: South Korea's New Tool for Filtering Illegal Internet Content", March 2019, https://www.newamerica.org/cybersecurity-initiative/c2b/c2b-log/analysis-south-koreas-sni-monitoring/.

[Nabi-2013] Nabi, Z., "The Anatomy of Web Censorship in Pakistan", August 2013, http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/12387-foci13-nabi.pdf.

[NBC-2014] NBC News, "Exclusive: Snowden Docs Show UK Spies Attacked Anonymous, Hackers", February 2014, http://www.nbcnews.com/feature/edward-snowden-interview/exclusive-snowden-docs-show-uk-spies-attacked-anonymous-hackers-n21361.

[Netsec-2011] n3t2.3c, "TCP-RST Injection", October 2011, https://nets.ec/TCP-RST_Injection.

[OONI-2018] Evdokimov, L., "Iran Protests: DPI blocking of Instagram (Part 2)", February 2018, https://ooni.org/post/2018-iran-protests-pt2/.

[OONI-2019] Singh, S., Filastò, A., and M. Xynou, "China is now blocking all language editions of Wikipedia", May 2019, https://ooni.org/post/2019-china-wikipedia-blocking/.

[Orion-2013] Orion, E., "Zimbabwe election hit by hacking and DDoS attacks", Wayback Machine archive, August 2013, https://web.archive.org/web/20130825010947/http://www.theinquirer.net/inquirer/news/2287433/zimbabwe-election-hit-by-hacking-and-ddos-attacks.

[Patil-2019] Patil, S. and N. Borisov, "What can you learn from an IP?", Proceedings of the Applied Networking Research Workshop, Pages 45-51, DOI 10.1145/3340301.3341133, July 2019, https://irtf.org/anrw/2019/anrw2019-final44-acmpaginated.pdf.

[Porter-2005] Porter, T., "The Perils of Deep Packet Inspection", 2010, http://www.symantec.com/connect/articles/perils-deep-packet-inspection.

[Rambert-2021] Rampert, R., Weinberg, Z., Barradas, D., and N. Christin, "Chinese Wall or Swiss Cheese? Keyword filtering in the Great Firewall of China", DOI 10.1145/3442381.3450076, April 2021, https://www.andrew.cmu.edu/user/nicolasc/publications/Rambert-WWW21.pdf.

[Reda-2017] Reda, F., "New EU law prescribes website blocking in the name of "consumer protection"", November 2017, https://felixreda.eu/2017/11/eu-website-blocking/.

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, https://www.rfc-editor.org/info/rfc6066.

[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, https://www.rfc-editor.org/info/rfc7624.

[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, "Technical Considerations for Internet Service Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, March 2016, https://www.rfc-editor.org/info/rfc7754.

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, https://www.rfc-editor.org/info/rfc7858.

[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, https://www.rfc-editor.org/info/rfc8484.

[RFC8744] Huitema, C., "Issues and Requirements for Server Name Identification (SNI) Encryption in TLS", RFC 8744, DOI 10.17487/RFC8744, July 2020, https://www.rfc-editor.org/info/rfc8744.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.

[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, https://www.rfc-editor.org/info/rfc9293.

[Rushe-2014] Rushe, D., "Bing censoring Chinese language search results for users in the US", The Guardian, February 2014, http://www.theguardian.com/technology/2014/feb/11/bing-censors-chinese-language-search-results.

[RWB-2020] Reporters Without Borders (RSF), "2020 World Press Freedom Index: 'Entering a decisive decade for journalism, exacerbated by coronavirus'", April 2020, https://rsf.org/en/2020-world-press-freedom-index-entering-decisive-decade-journalism-exacerbated-coronavirus.

[Sandvine-2015] Sandvine, "Internet Traffic Classification: A Sandvine Technology Showcase", 2015, https://www.researchgate.net/profile/Nirmala-Svsg/post/Anybody-working-on-Internet-traffic-classification/attachment/59d63a5779197b807799782d/AS%3A405810988503040%401473764287142/download/traffic-classification-identifying-and-measuring-internet-traffic.pdf.

Here's the rest of the reference list, all the way through Zmijewski-2014 📚✨

   [Satija-2021]
              Satija, S. and R. Chatterjee, "BlindTLS: Circumventing
              TLS-based HTTPS censorship", FOCI '21: Proceedings of the
              ACM SIGCOMM 2021 Workshop on Free and Open Communications
              on the Internet, Pages 43-49, DOI 10.1145/3473604.3474564,
              August 2021,
              <https://sambhav.info/files/blindtls-foci21.pdf>.

   [Schoen-2007]
              Schoen, S., "EFF tests agree with AP: Comcast is forging
              packets to interfere with user traffic", October 2007,
              <https://www.eff.org/deeplinks/2007/10/eff-tests-agree-ap-
              comcast-forging-packets-to-interfere>.

   [Senft-2013]
              , Crete-Nishihata, M., Dalek, J., Hardy, S., Hilts, A.,
              Kleemola, K., Ng, J., Poetranto, I., Senft, A., Sinpeng,
              A., Sonne, B., and G. Wiseman, "Asia Chats: Analyzing
              Information Controls and Privacy in Asian Messaging
              Applications", November 2013,
              <https://citizenlab.org/2013/11/asia-chats-analyzing-
              information-controls-privacy-asian-messaging-
              applications/>.

   [Shbair-2015]
              Shbair, W. M., Cholez, T., Goichot, A., and I. Chrisment,
              "Efficiently Bypassing SNI-based HTTPS Filtering", May
              2015, <https://hal.inria.fr/hal-01202712/document>.

   [Siddiqui-2022]
              Siddiqui, A., "Lesson Learned: Twitter Shored Up Its
              Routing Security", March 2022,
              <https://www.manrs.org/2022/03/lesson-learned-twitter-
              shored-up-its-routing-security/>.

   [SIDN-2020]
              Moura, G., "Detecting and Taking Down Fraudulent Webshops
              at the .nl ccTLD", February 2020,
              <https://labs.ripe.net/Members/giovane_moura/detecting-
              and-taking-down-fraudulent-webshops-at-a-cctld>.

   [Singh-2019]
              Singh, K., Grover, G., and V. Bansal, "How India Censors
              the Web", DOI 10.48550/arXiv.1912.08590, December 2019,
              <https://arxiv.org/abs/1912.08590>.

   [Sophos-2023]
              Sophos, "Sophos Firewall: Web filtering basics", 2023,
              <https://support.sophos.com/support/s/article/KB-
              000036518?language=en_US>.

   [SSAC-109-2020]
              ICANN Security and Stability Advisory Committee (SSAC),
              "SAC109: The Implications of DNS over HTTPS and DNS over
              TLS", March 2020,
              <https://www.icann.org/en/system/files/files/sac-
              109-en.pdf>.

   [Tang-2016]
              Tang, C., "In-depth analysis of the Great Firewall of
              China", December 2016,
              <https://www.cs.tufts.edu/comp/116/archive/fall2016/
              ctang.pdf>.

   [Thomson-2012]
              Thomson, I., "Syria cuts off internet and mobile
              communication", The Register, November 2012,
              <http://www.theregister.co.uk/2012/11/29/
              syria_internet_blackout/>.

   [TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", Work in Progress, Internet-Draft,
              draft-ietf-tls-esni-17, 9 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              esni-17>.

   [Tor-2019] Tor, "Tor: Pluggable Transports", 2019,
              <https://2019.www.torproject.org/docs/pluggable-
              transports.html.en>.

   [Trustwave-2015]
              Trustwave, "Filter : SNI extension feature and HTTPS
              blocking", 2015,
              <https://www3.trustwave.com/software/8e6/hlp/r3000/
              files/1system_filter.html>.

   [Tschantz-2016]
              Tschantz, M., Afroz, S., Anonymous, and V. Paxson, "SoK:
              Towards Grounding Censorship Circumvention in Empiricism",
              DOI 10.1109/SP.2016.59, May 2016,
              <https://oaklandsok.github.io/papers/tschantz2016.pdf>.

   [Van-der-Sar-2007]
              Van der Sar, E., "How To Bypass Comcast's BitTorrent
              Throttling", October 2012, <https://torrentfreak.com/how-
              to-bypass-comcast-bittorrent-throttling-071021>.

   [Verkamp-2012]
              Verkamp, J. P. and M. Gupta, "Inferring Mechanics of Web
              Censorship Around the World", August 2012,
              <https://www.usenix.org/system/files/conference/foci12/
              foci12-final1.pdf>.

   [Victor-2019]
              Victor, D., "Blizzard Sets Off Backlash for Penalizing
              Hearthstone Gamer in Hong Kong", The New York Times,
              October 2019,
              <https://www.nytimes.com/2019/10/09/world/asia/blizzard-
              hearthstone-hong-kong.html>.

   [Villeneuve-2011]
              Villeneuve, N. and M. Crete-Nishihata, "Open Access:
              Chapter 8, Control and Resistance, Attacks on Burmese
              Opposition Media", January 2011,
              <http://access.opennet.net/wp-content/uploads/2011/12/
              accesscontested-chapter-08.pdf>.

   [VonLohmann-2008]
              VonLohmann, F., "FCC Rules Against Comcast for BitTorrent
              Blocking", August 2008,
              <https://www.eff.org/deeplinks/2008/08/fcc-rules-against-
              comcast-bit-torrent-blocking>.

   [Wagner-2009]
              Wagner, B., "Deep Packet Inspection and Internet
              Censorship: International Convergence on an 'Integrated
              Technology of Control'", Global Voices Advocacy, 2009,
              <http://advocacy.globalvoicesonline.org/wp-
              content/uploads/2009/06/deeppacketinspectionandinternet-
              censorship2.pdf>.

   [Wagstaff-2013]
              Wagstaff, J., "In Malaysia, online election battles take a
              nasty turn", NBC News, May 2013,
              <https://www.nbcnews.com/tech/tech-news/malaysia-online-
              election-battles-take-nasty-turn-flna6c9783842>.

   [Wang-2017]
              Wang, Z., Cao, Y., Qian, Z., Song, C., and S.V.
              Krishnamurthy, "Your State is Not Mine: A Closer Look at
              Evading Stateful Internet Censorship",
              DOI 10.1145/3131365.3131374, November 2017,
              <https://www.cs.ucr.edu/~zhiyunq/pub/
              imc17_censorship_tcp.pdf>.

   [Wang-2020]
              Wang, Z., Zhu, S., Cao, Y., Qian, Z., Song, C.,
              Krishnamurthy, S.V., Chan, K.S., and T.D. Braun, "SYMTCP:
              Eluding Stateful Deep Packet Inspection with Automated
              Discrepancy Discovery", DOI 10.14722/ndss.2020.24083,
              February 2020,
              <https://www.cs.ucr.edu/~zhiyunq/pub/ndss20_symtcp.pdf>.

   [Weaver-2009]
              Weaver, N., Sommer, R., and V. Paxson, "Detecting Forged
              TCP Reset Packets", September 2009,
              <http://www.icir.org/vern/papers/reset-
              injection.ndss09.pdf>.

   [Whittaker-2013]
              Whittaker, Z., "1,168 keywords Skype uses to censor,
              monitor its Chinese users", March 2013,
              <http://www.zdnet.com/1168-keywords-skype-uses-to-censor-
              monitor-its-chinese-users-7000012328/>.

   [Wikip-DoS]
              Wikipedia, "Denial-of-service attack", March 2016,
              <https://en.wikipedia.org/w/index.php?title=Denial-of-
              service_attack&oldid=710558258>.

   [Wilde-2012]
              Wilde, T., "Knock Knock Knockin' on Bridges Doors", The
              Tor Project, July 2012, <https://blog.torproject.org/blog/
              knock-knock-knockin-bridges-doors>.

   [Winter-2012]
              Winter, P. and S. Lindskog, "How China Is Blocking Tor",
              April 2012, <http://arxiv.org/pdf/1204.0447v1.pdf>.

   [WP-Def-2020]
              Wikipedia, "Censorship", March 2020,
              <https://en.wikipedia.org/w/
              index.php?title=Censorship&oldid=943938595>.

   [Wright-2013]
              Wright, J. and Y. Breindl, "Internet filtering trends in
              liberal democracies: French and German regulatory
              debates", DOI 10.14763/2013.2.122, April 2013,
              <https://policyreview.info/articles/analysis/internet-
              filtering-trends-liberal-democracies-french-and-german-
              regulatory-debates>.

   [Zhu-2011] Zhu, T., Bronk, C., and D.S. Wallach, "An Analysis of
              Chinese Search Engine Filtering",
              DOI 10.48550/arXiv.1107.3794, July 2011,
              <http://arxiv.org/ftp/arxiv/papers/1107/1107.3794.pdf>.

   [Zmijewski-2014]
              Zmijewski, E., "Turkish Internet Censorship Takes a New
              Turn", Wayback Machine archive, March 2014,
              <http://web.archive.org/web/20200726222723/
              https://blogs.oracle.com/internetintelligence/turkish-
              internet-censorship-takes-a-new-turn>.

---

Acknowledgments 🫶

Big thank-yous to David Belson, Stéphane Bortzmeyer, Vinicius Fortuna, Gurshabad Grover, Andrew McConachie, Martin Nilsson, Michael Richardson, Patrick Vacek, and Chris Wood. These folks helped this document along with their discussions and input, and they're literally the reason it's as good as it is 💜

Coauthor Hall did some of the work on this document before he joined the Internet Society 🎀 The affiliation listed in this document is only there for identification purposes.

---

Authors' Addresses 📮

Joseph Lorenzo Hall 🌸 Internet Society Email: hall@isoc.org

Michael D. Aaron 🦋 CU Boulder Email: michael.drew.aaron@gmail.com

Amelia Andersdotter 🧚 Email: amelia.ietf@andersdotter.cc

Ben Jones 🍓 Email: ben.jones.irtf@gmail.com

Nick Feamster 💅 U Chicago Email: feamster@uchicago.edu

Mallory Knodel 👑 Center for Democracy & Technology Email: mknodel@cdt.org

And that's the whole RFC, bestie! 🌈✨ Thank you for reading all the way to the end 🥹💖