[要約] RFC 9505 - 世界中の検閲技術に関する調査は、インターネット上での情報の流れを制限するために使用される様々な技術的手法を概観しています。この文書の目的は、検閲の実践とその回避方法についての理解を深めることにあります。主に政府機関、技術者、研究者が利用することを想定しています。

Internet Research Task Force (IRTF)                           J. L. Hall
Request for Comments: 9505                              Internet Society
Category: Informational                                      M. D. Aaron
ISSN: 2070-1721                                               CU Boulder
                                                         A. Andersdotter
                                                                        
                                                                B. Jones
                                                                        
                                                             N. Feamster
                                                               U Chicago
                                                               M. Knodel
                                       Center for Democracy & Technology
                                                           November 2023
        
A Survey of Worldwide Censorship Techniques
世界中の検閲技術に関する調査
Abstract
概要

This document describes technical mechanisms employed in network censorship that regimes around the world use for blocking or impairing Internet traffic. It aims to make designers, implementers, and users of Internet protocols aware of the properties exploited and mechanisms used for censoring end-user access to information. This document makes no suggestions on individual protocol considerations, and is purely informational, intended as a reference. This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF.

この文書は、世界中の政権がインターネットトラフィックを遮断または妨害するために使用するネットワーク検閲において使用される技術的メカニズムについて説明しています。これは、インターネットプロトコルの設計者、実装者、およびユーザーが、情報へのエンドユーザーアクセスを検閲するために利用される特性とメカニズムについて認識することを目的としています。この文書は個々のプロトコルに関する提案を行うものではなく、純粋に情報提供を目的としており、参照資料として利用されることを意図しています。この文書は、IRTFのPrivacy Enhancement and Assessment Research Group(PEARG)の製品です。

Status of This Memo
本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

この文書はインターネット標準トラック仕様ではありません。情報提供のために公開されています。

This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Privacy Enhancements and Assessments Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

この文書はInternet Research Task Force(IRTF)の製品です。IRTFはインターネット関連の研究開発活動の結果を公表しています。これらの結果は展開に適していない可能性があります。このRFCは、Internet Research Task Force(IRTF)のPrivacy Enhancements and Assessments Research Groupの合意を表しています。IRSGによって公表が承認された文書は、インターネット標準のいかなるレベルの候補にもなりません。RFC 7841のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9505.

このドキュメントの現在の状況、誤り訂正、およびフィードバックの方法に関する情報は、https://www.rfc-editor.org/info/rfc9505 で入手できます。

著作権表示

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

著作権(c)2023 IETF Trustおよび文書の著者として特定された人々。全著作権所有。

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 of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、この文書の公開日に有効なBCP 78およびIETF文書に関連するIETF信託の法的規定(https://trustee.ietf.org/license-info)の対象となります。これらの文書を注意深く確認してください。これらは、この文書に関するあなたの権利と制限を説明しています。

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
1. はじめに

Censorship is where an entity in a position of power -- such as a government, organization, or individual -- suppresses communication that it considers objectionable, harmful, sensitive, or inconvenient [WP-Def-2020]. Although censors that engage in censorship must do so through legal, martial, or other means, this document focuses largely on technical mechanisms used to achieve network censorship.

検閲は、政府、組織、または個人などの権力を持つ実体が、不適切、有害、機密、または不都合と考えるコミュニケーションを抑制することです。検閲を行う検閲者は、法的、軍事的、またはその他の手段を通じて行わなければなりませんが、この文書は主にネットワーク検閲を実現するために使用される技術的なメカニズムに焦点を当てています。

This document describes technical mechanisms that censorship regimes around the world use for blocking or impairing Internet traffic. See [RFC7754] for a discussion of Internet blocking and filtering in terms of implications for Internet architecture rather than end-user access to content and services. There is also a growing field of academic study of censorship circumvention (see the review article of [Tschantz-2016]), results from which we seek to make relevant here for protocol designers and implementers.

この文書は、世界中の検閲体制がインターネットトラフィックをブロックまたは妨害するために使用する技術的メカニズムについて説明しています。インターネットのブロックやフィルタリングに関する議論については、エンドユーザーがコンテンツやサービスにアクセスすることよりもインターネットアーキテクチャへの影響に焦点を当てた[RFC7754]を参照してください。また、検閲回避の学術研究分野も拡大しており([Tschantz-2016]のレビュー記事を参照)、その結果をプロトコル設計者や実装者にとって関連性のあるものとしてここで取り上げたいと考えています。

Censorship circumvention also impacts the cost of implementation of a censorship measure, and we include mentions of trade-offs in relation to such costs in conjunction with each technical method identified below.

検閲回避は検閲措置の実施コストにも影響を与えます。以下で特定された各技術方法に関連するコストとのトレードオフについても言及しています。

This document has seen extensive discussion and review in the IRTF Privacy Enhancement and Assessment Research Group (PEARG) and represents the consensus of that group. It is not an IETF product and is not a standard.

この文書は、IRTFプライバシー強化および評価研究グループ(PEARG)で広範な議論とレビューを受け、そのグループの合意を表しています。これはIETFの製品ではなく、標準ではありません。

2. Terminology
2. 用語

We describe three elements of Internet censorship: prescription, identification, and interference. This document contains three major sections, each corresponding to one of these elements. Prescription is the process by which censors determine what types of material they should censor, e.g., classifying pornographic websites as undesirable. Identification is the process by which censors classify specific traffic or traffic identifiers to be blocked or impaired, e.g., deciding that webpages containing "sex" in an HTTP header or that accept traffic through the URL "www.sex.example" are likely to be undesirable. Interference is the process by which censors intercede in communication and prevent access to censored materials by blocking access or impairing the connection, e.g., implementing a technical solution capable of identifying HTTP headers or URLs and ensuring they are rendered wholly or partially inaccessible.

インターネット検閲の3つの要素を説明します:指示、識別、干渉。この文書には、それぞれがこれらの要素の1つに対応する3つの主要セクションが含まれています。指示は、検閲者がどの種類の資料を検閲すべきかを決定するプロセスであり、例えば、ポルノサイトを望ましくないと分類することです。識別は、検閲者が特定のトラフィックやトラフィック識別子をブロックまたは妨害するためのプロセスであり、例えば、HTTPヘッダーに「sex」を含むウェブページやURL「www.sex.example」を通じてトラフィックを受け入れることが望ましくないと判断することです。干渉は、検閲者が通信に介入し、アクセスをブロックしたり接続を妨害したりして検閲された資料へのアクセスを防ぐプロセスであり、例えば、HTTPヘッダーやURLを識別し、それらが完全または部分的にアクセスできないようにする技術的なソリューションを実装することです。

3. Technical Prescription
3. 技術的な処方箋

Prescription is the process of figuring out what censors would like to block [Glanville-2008]. Generally, censors aggregate information "to block" in blocklists, databases of image hashes [ekr-2021], or use real-time heuristic assessment of content [Ding-1999]. Some national networks are designed to more naturally serve as points of control [Leyba-2019]. There are also indications that online censors use probabilistic machine learning techniques [Tang-2016]. Indeed, web crawling and machine learning techniques are an active research area in the effort to identify content deemed as morally or commercially harmful to companies or consumers in some jurisdictions [SIDN-2020].

処方箋は、何を検知したいかを見極めるプロセスです。一般的に、検知者は画像のハッシュのブロックリスト、データベース、またはコンテンツのリアルタイムなヒューリスティック評価を使用して情報を「ブロック」します。一部の国家ネットワークは、より自然に制御ポイントとして機能するよう設計されています。オンライン検閲者が確率的機械学習技術を使用しているという指摘もあります。実際、ウェブクローリングと機械学習技術は、一部の管轄区域で企業や消費者にとって道徳的または商業的に有害と見なされるコンテンツを特定する取り組みの活発な研究分野です。

There are typically a few types of blocklist elements: keyword, domain name, protocol, or IP address. Keyword and domain name blocking take place at the application level, e.g., HTTP; protocol blocking often occurs using deep packet inspection (DPI) to identify a forbidden protocol; IP blocking tends to take place using IP addresses in IPv4/IPv6 headers. Some censors also use the presence of certain keywords to enable more aggressive blocklists [Rambert-2021] or to be more permissive with content [Knockel-2021].

通常、ブロックリスト要素にはいくつかのタイプがあります:キーワード、ドメイン名、プロトコル、またはIPアドレス。 キーワードとドメイン名のブロックはアプリケーションレベルで行われ、例えばHTTPです。 プロトコルのブロックは、しばしば深いパケット検査(DPI)を使用して禁止されたプロトコルを特定します。 IPブロックは、IPv4 / IPv6ヘッダーのIPアドレスを使用して行われる傾向があります。 一部の検閲者は、特定のキーワードの存在を使用して、より積極的なブロックリストを有効にすることもあります[Rambert-2021]、またはコンテンツに対してより寛容になることもあります[Knockel-2021]。

The mechanisms for building up these blocklists vary. Censors can purchase from private industry "content control" software, which lets censors filter traffic from broad categories they would like to block, such as gambling or pornography [Knight-2005]. In these cases, these private services attempt to categorize every semi-questionable website to allow for meta-tag blocking. Similarly, they tune real-time content heuristic systems to map their assessments onto categories of objectionable content.

これらのブロックリストを構築するメカニズムは異なります。検閲者は、賭博やポルノなどの広範なカテゴリからトラフィックをフィルタリングしたいと考えている場合に使用することができる「コンテンツ制御」ソフトウェアを、民間業界から購入することができます[Knight-2005]。これらの場合、これらの民間サービスは、メタタグのブロックを可能にするために、ほぼ疑問の余地のあるすべてのウェブサイトをカテゴリ分けしようとします。同様に、彼らはリアルタイムのコンテンツヒューリスティックシステムを調整して、彼らの評価を問題のあるコンテンツのカテゴリにマッピングします。

Countries that are more interested in retaining specific political control typically 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 specific to copyright law in France [HADOPI] and consumer protection law across the EU [Reda-2017].

特定の政治的コントロールを維持することに関心を持っている国々は、通常、ブロックリストを維持する省庁や組織を持っています。例として、中国の工業情報化省、イランの文化・イスラム指導省、フランスの著作権法に特化した組織(HADOPI)、EU全体の消費者保護法に関する組織(Reda-2017)があります。

Content-layer filtering of images and video requires institutions or organizations to store hashes of images or videos to be blocked in databases, which can then be compared, with some degree of tolerance, to content that is sent, received, or stored using centralized content applications and services [ekr-2021].

画像や動画のコンテンツレイヤーフィルタリングを行うには、機関や組織がブロックする画像や動画のハッシュをデータベースに保存する必要があります。その後、中央集権的なコンテンツアプリケーションやサービスを使用して送信、受信、または保存されるコンテンツと、ある程度の許容範囲で比較することができます。

4. Technical Identification
4. 技術的な識別
4.1. Points of Control
4.1. 制御ポイント

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:

インターネット検閲はネットワークの全ての部分で行われます。ネットワーク自体(たとえば、ローカルループやバックホール)、通信のサービス側(たとえば、ウェブホスト、クラウドプロバイダ、またはコンテンツ配信ネットワーク)、付随サービスエコシステム(たとえば、ドメイン名システム(DNS)や証明書機関(CAs))、またはエンドクライアント側(たとえば、スマートフォン、ラップトップ、デスクトップなどのエンドユーザデバイス、またはそのようなデバイスで実行されるソフトウェア)で実装される可能性があります。普及した技術的な傍受の重要な側面は、検閲者が興味を持つコンテンツを傍受するためにソフトウェアやハードウェアに依存する必要があることです。検閲者が傍受メカニズムに使用できる論理的および物理的な制御ポイントは、次のようなものに限定されないが含まれます。

Internet Backbone:

インターネットバックボーン:

If a censor controls elements of Internet network infrastructure, such as the international gateways into a region or Internet Exchange Points (IXPs), those choke points can be used to filter undesirable traffic that is traveling 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 is ineffective at identifying content traveling between the users within a region, which would have to be accomplished 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].

もし検閲者がインターネットネットワークインフラの要素を制御する場合、例えば地域への国際ゲートウェイやインターネットエクスチェンジポイント(IXP)など、その制約点はパケットスニッフィングやポートミラーリングによって、その地域へ出入りする望ましくないトラフィックをフィルタリングするために使用される可能性があります。ゲートウェイでの検閲は、その地域とインターネットの他の部分との間の情報の流れを制御するのに最も効果的ですが、その地域内のユーザー間を移動するコンテンツを特定するのには効果がありません。これはエクスチェンジポイントや他のネットワーク集約ポイントで達成する必要があります。一部の国家のネットワーク設計は、より効果的な制約点や制御ポイントとして自然に機能します[Leyba-2019]。

Internet Service Providers (ISPs):

インターネットサービスプロバイダー(ISP):

ISPs are frequently exploited points of control. They have the benefit of being easily enumerable by a censor -- often falling under the jurisdictional or operational control of a censor in an indisputable way -- with the additional feature that an ISP can identify the regional and international traffic of all their users. The censor's filtration mechanisms can be placed on an ISP via governmental mandates, ownership, or voluntary/coercive influence.

ISPは頻繁に悪用される制御ポイントです。検閲者によって簡単に列挙される利点があります。検閲者の管轄権または運用上の制御下にあることが多く、ISPはすべてのユーザーの地域および国際トラフィックを識別できる追加機能を持っています。検閲者のフィルタリングメカニズムは、政府の命令、所有権、または自発的/強制的な影響を通じてISPに配置されることがあります。

Institutions:

機関

Private institutions such as corporations, schools, and Internet cafes can use filtration mechanisms. These mechanisms are occasionally at the request of a government censor but can also be implemented to help achieve institutional goals, such as fostering a particular moral outlook on life by schoolchildren, independent of broader society or government goals.

民間機関、例えば企業、学校、インターネットカフェなどは、フィルタリングメカニズムを使用することができます。これらのメカニズムは時折政府の検閲官の要請によるものですが、学校児童に特定の道徳的見地を育むなど、広範な社会や政府の目標とは独立して機関の目標を達成するために実施されることもあります。

Content Distribution Network (CDN):

コンテンツ配信ネットワーク(CDN):

CDNs seek to collapse network topology in order to better locate content closer to the service's users. This reduces content transmission latency and improves QoS. The CDN service's content servers, located "close" to the user in a network sense, can be powerful points of control for censors, especially if the location of CDN repositories allows for easier interference.

CDNsはネットワークのトポロジーを縮小して、サービスのユーザーにコンテンツをより近い場所に配置することを目指しています。これによりコンテンツの伝送遅延が減少し、QoSが向上します。CDNサービスのコンテンツサーバーは、ネットワーク的にユーザーに「近い」場所に配置されており、CDNリポジトリの場所が干渉を容易にする場合、特に検閲者にとって強力な制御ポイントとなり得ます。

CAs for Public Key Infrastructures (PKIs):

公開鍵インフラストラクチャ(PKI)に関して:

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, i.e., by allowing censorship software to engage in identification and interference where it may not have been possible 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.

暗号化されたリソースを発行する機関は重要な制御ポイントとなり得ます。TLS/HTTPS(Web PKI)のドメイン所有者に証明書を発行するCAや、BGPオペレーターにRoute Origin Authorizations(ROAs)を発行する地域または地域インターネット登録機関(RIRまたはLIR)などが、不正な証明書を発行するよう強制される可能性があります。これにより、検閲ソフトウェアが以前には不可能だった識別や干渉を行うことが可能になる可能性があります。CAは証明書を取り消すよう強制されることもあります。これにより、敵対的なトラフィックルーティング、TLSインターセプションの許可、またはそれ以外の正当なトラフィックフローの発信元や宛先が安全な方法で通信できなくなる可能性があります。

Services:

サービス:

Application service providers can be pressured, coerced, or legally required to censor specific content or data flows. Service providers naturally face incentives to maximize their potential customer base, and potential service shutdowns or legal liability due to censorship efforts may seem much less attractive than potentially 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 lie many platforms that publish user-generated content and require terms of service compliance with all content and user accounts in order to avoid intermediary liability for the web hosts. In aggregate, 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, thus making them available to censors through direct pressure on the private entity.

通信のサービス側には、ユーザーが生成したコンテンツを公開する多くのプラットフォームがあり、ウェブホストに対する中間責任を回避するために、すべてのコンテンツとユーザーアカウントに対する利用規約の遵守が求められます。これらの方針、行動、および対策を総称してコンテンツモデレーションと呼びます。コンテンツモデレーションは、サービスやアプリケーション層の上で行われますが、これらのメカニズムはコンテンツやユーザーをフィルタリング、ソート、ブロックするために構築されており、私的な実体に直接圧力をかけることで検閲者に利用可能になります。

Personal Devices:

個人用デバイス:

Censors can mandate censorship software be installed on 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 exacerbated these feasibility problems. 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 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 be 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 later the image is deemed undesirable, a censor may then blocklist the provider site's IP address.

ネットワーク階層のすべてのレベルで、望ましくないトラフィックを検閲するために使用されるフィルタリングメカニズムは基本的に同じです。検閲者は、以下で説明される識別子を使用して直接望ましくないコンテンツを特定し、その後ブロッキングや整形のメカニズム(以下に例示されるもの)を使用してアクセスを防止または妨害するか、検閲者に付随するアクター(プライベートエンティティなど)にこれらの機能を実行するよう要求します。望ましくないトラフィックの識別は、IPスタックのアプリケーション、トランスポート、またはネットワークレイヤーで発生することがあります。検閲者はしばしばWebトラフィックに焦点を当てるため、関連するプロトコルは予測可能な方法でフィルタリングされる傾向があります(4.2.1節および4.2.2節を参照)。たとえば、過激な画像がキーワードフィルタを通過することがあるかもしれません。しかし、後でその画像が望ましくないと判断された場合、検閲者はプロバイダーサイトのIPアドレスをブロックリストに登録するかもしれません。

4.2. Application Layer
4.2. アプリケーション層

The following subsections describe properties and trade-offs of common ways in which 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
4.2.1. HTTPリクエストヘッダーの識別

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. As such, "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.

HTTPヘッダーには、トラフィック識別のための多くの有用な情報が含まれています。HTTPリクエストヘッダーでは、"host"が唯一必須のフィールドです(HTTP/1.1以降)。しかし、有用な処理を行うためにはHTTPメソッドフィールドが必要です。そのため、"method"と"host"は、普遍的な検閲に最も頻繁に使用される2つのフィールドです。検閲者はトラフィックを嗅ぎ、特定のドメイン名(host)と通常はページ名(例:GET /page)を特定することができます。この識別技術は、より堅牢な方法のために輸送ヘッダー識別(セクション4.3.1を参照)と通常ペアになります。

Trade-offs: HTTP request header identification is a technically straightforward identification method that can be easily implemented at the backbone or ISP level. The hardware needed for this sort of identification is cheap and easy to acquire, making it desirable when budget and scope are a concern. HTTPS (Hypertext Transport Protocol Secure) will encrypt 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.

トレードオフ:HTTPリクエストヘッダー識別は、バックボーンやISPレベルで簡単に実装できる技術的に直接的な識別方法です。この種の識別に必要なハードウェアは安価で入手しやすいため、予算や範囲が懸念される場合に望ましいです。HTTPS(Hypertext Transport Protocol Secure)は関連するリクエストとレスポンスフィールドを暗号化しますので、HTTPSフィルタリングにはトランスポート識別(セクション4.3.1を参照)とのペアリングが必要です。ただし、いくつかの対策は、単純な形式のHTTPリクエストヘッダー識別を簡単に無効にすることができます。たとえば、計測されたWebサーバーとクライアントとの2つの協力するエンドポイントは、リクエストの「ホスト」ヘッダーを暗号化したり他の方法で曖昧化したりすることができ、可能性として「ホスト」ヘッダーの値に一致する技術を妨げることができます。

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].

実証的な例:検閲メカニズムを探る研究では、バングラデシュ、バーレーン、中国、インド、イラン、マレーシア、パキスタン、ロシア、サウジアラビア、韓国、タイ、トルコなど多くの国で、HTTPヘッダーやURLのフィルタリングの証拠が見つかっています[Verkamp-2012] [Nabi-2013] [Aryan-2013]。検閲当局は、商用技術をしばしば購入します[Dalek-2013]。これらの商用技術は、特定のURLをフィルタリングするために、HTTPリクエストヘッダーの識別とトランスポートヘッダーの識別の組み合わせを使用します。DalekらやJonesらは、野外でこれらの製品の使用を特定しました[Dalek-2013] [Jones-2014]。

4.2.2. HTTP Response Header Identification
4.2.2. HTTPレスポンスヘッダーの識別

While HTTP request header identification relies on the information contained in the HTTP request from client to server, HTTP response header identification uses information sent in response by the server to client to identify undesirable content.

HTTPリクエストヘッダーの識別は、クライアントからサーバーへのHTTPリクエストに含まれる情報に依存しますが、HTTPレスポンスヘッダーの識別は、サーバーからクライアントへの応答で送信される情報を使用して望ましくないコンテンツを識別します。

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

トレードオフ:HTTPリクエストヘッダーの識別と同様に、HTTPトラフィックを識別するために使用される技術はよく知られており、安価で比較的簡単に実装できます。ただし、HTTPSによって応答とそのヘッダーが暗号化されるため、これらの技術は無効になります。

The response fields are also less helpful for identifying content than request fields, as "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.

レスポンスフィールドはリクエストフィールドよりもコンテンツを特定するのに役立ちません。"Server" は HTTP リクエストヘッダの識別を使用して簡単に特定でき、"Via" はほとんど関係ありません。HTTP レスポンスの検閲メカニズムは通常、ミラーリングされたトラフィックが処理されている間に最初の n パケットを通過させます。これにより一部のコンテンツが通過する可能性があり、ユーザーは検閲が望ましくないコンテンツに積極的に干渉していることを検出できるかもしれません。

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 in 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.

2009年、ニューメキシコ大学のJong Parkらは、中国のグレートファイアウォール(GFW)がこの技術を使用していることを実証しました[Crandall-2010]。しかし、Jong Parkらは、研究の過程でGFWがこの実践を中止したことを発見しました。HTTPレスポンスフィルタリングとキーワードフィルタリングの重複があるため(セクション4.2.4を参照)、ほとんどの検閲者はHTTPレスポンスフィルタリングではなくTCPストリーム上のキーワードフィルタリングに依存している可能性が高いです。

4.2.3. Transport Layer Security (TLS)
4.2.3. Transport Layer Security (TLS)

Similar to HTTP, censors have deployed a variety of techniques towards 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.

HTTPと同様に、検閲者はTLS(およびそれに関連するHTTPS)を検閲するためにさまざまな技術を展開しています。これらの技術のほとんどは、Server Name Indication(SNI)フィールドに関連しており、SNI、暗号化されたSNI(ESNI)、または省略されたSNIを検閲することが含まれます。検閲者はまた、サーバー証明書を介してHTTPSコンテンツを検閲することもできます。TLS 1.3はQUICのセキュリティコンポーネントとして機能します。

4.2.3.1. Server Name Indication (SNI)
4.2.3.1. サーバー名指定(SNI)

In encrypted connections using TLS, there may be servers that host multiple "virtual servers" at a given network address, and the client will need to specify in the ClientHello message which domain name it seeks to connect to (so that the server can respond with the appropriate TLS certificate) using, the SNI TLS extension [RFC6066]. The ClientHello message is unencrypted for TCP-based TLS. When using QUIC, the ClientHello message is encrypted, but its confidentiality is not effectively protected because the initial encryption keys are derived using a value that is visible on the wire. Since SNI is often sent in the clear (as are the cert fields sent in response), censors and filtering software can use it (and response cert fields) as a basis for blocking, filtering, or impairment by dropping connections to domains that match prohibited content (e.g., "bad.foo.example" may be censored while "good.foo.example" is not) [Shbair-2015]. There are ongoing standardization efforts in the TLS Working Group to encrypt SNI [RFC8744] [TLS-ESNI], and recent research shows promising results in the use of ESNI in the face of SNI-based filtering [Chai-2019] in some countries.

TLSを使用した暗号化された接続では、特定のネットワークアドレスで複数の「仮想サーバー」をホストするサーバーが存在する可能性があり、クライアントはClientHelloメッセージで接続先のドメイン名を指定する必要があります(サーバーが適切なTLS証明書で応答できるようにするため)、SNI TLS拡張[RFC6066]を使用しています。ClientHelloメッセージはTCPベースのTLSでは暗号化されていません。QUICを使用する場合、ClientHelloメッセージは暗号化されていますが、初期の暗号化キーはワイヤー上で見える値を使用して導出されるため、その機密性は効果的に保護されていません。SNIはしばしば平文で送信されるため(応答で送信される証明書フィールドも同様)、検閲やフィルタリングソフトウェアはそれを使用して(および応答の証明書フィールドを使用して)禁止されたコンテンツに一致するドメインへの接続をブロック、フィルタリング、または接続の中断を行う基準として使用できます(たとえば、「bad.foo.example」は検閲される可能性があり、「good.foo.example」はされない可能性があります)[Shbair-2015]。TLS Working Groupでは、SNIを暗号化するための標準化作業が進行中であり[RFC8744][TLS-ESNI]、最近の研究では、一部の国でのSNIベースのフィルタリングに対するESNIの使用において有望な結果が示されています[Chai-2019]。

Domain fronting has been one popular way to avoid identification by censors [Fifield-2015]. To avoid identification by censors, applications using domain fronting put a different domain name in the SNI extension than in the "host" header, which is protected by HTTPS. The visible SNI would indicate an unblocked domain, while the blocked domain remains hidden in the encrypted application header. Some encrypted messaging services relied on domain fronting to enable their provision in countries employing SNI-based filtering. These services used the cover provided by domains for which blocking at the domain level would be undesirable to hide their true domain names. However, the companies holding the most popular domains have since reconfigured their software to prevent this practice. It may be possible to achieve similar results using potential future options to encrypt SNI.

ドメインフロンティングは、検閲者による特定を回避するための人気のある方法の1つでした[Fifield-2015]。検閲者による特定を回避するために、ドメインフロンティングを使用するアプリケーションは、SNI拡張子に異なるドメイン名を配置し、「ホスト」ヘッダーにはHTTPSで保護されたドメイン名を配置します。表示されるSNIはブロックされていないドメインを示し、一方、ブロックされたドメインは暗号化されたアプリケーションヘッダーに隠されます。一部の暗号化メッセージングサービスは、SNIベースのフィルタリングを採用している国での提供を可能にするために、ドメインフロンティングに依存していました。これらのサービスは、ドメインレベルでのブロックが望ましくないドメインが提供するカバーを使用して、自身の真のドメイン名を隠していました。ただし、最も人気のあるドメインを保有する企業は、その後、この慣行を防止するためにソフトウェアを再構成しました。将来のSNIを暗号化するための潜在的なオプションを使用して、同様の結果を達成することが可能かもしれません。

Trade-offs: Some clients do not send the SNI extension (e.g., clients that only support versions of SSL and not TLS), rendering this method ineffective (see Section 4.2.3.3). In addition, this technique requires deep packet inspection (DPI) techniques that can be expensive in terms of computational complexity and infrastructure, especially when applied to QUIC where DPI requires key extraction and decryption of the ClientHello in order to read the SNI. Improper configuration of an SNI-based block can result in significant over-blocking, e.g., when a second-level domain like "populardomain.example" is inadvertently blocked. In the case of ESNI, pressure to censor may transfer to other points of intervention, such as content and application providers.

トレードオフ:一部のクライアントはSNI拡張を送信しない場合があります(たとえば、SSLのバージョンのみをサポートし、TLSをサポートしていないクライアントなど)、この方法は無効になります(セクション4.2.3.3を参照)。さらに、この技術には、特にQUICに適用する場合、DPI(Deep Packet Inspection)技術が必要であり、DPIにはSNIを読むためにClientHelloのキー抽出と復号化が必要であるため、計算複雑性やインフラの面で高額になる可能性があります。SNIベースのブロックの不適切な構成は、意図せずに"populardomain.example"のようなセカンドレベルドメインがブロックされるなど、過度なブロックを引き起こす可能性があります。ESNIの場合、検閲の圧力はコンテンツやアプリケーションプロバイダーなど、他の介入ポイントに移る可能性があります。

Empirical Examples: There are many examples of security firms that offer SNI-based filtering products [Trustwave-2015] [Sophos-2023] [Shbair-2015]. The governments of 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 observed in Russia in March 2022 [Elmenhorst-2022].

Empirical Examples: There are many examples of security firms that offer SNI-based filtering products [Trustwave-2015] [Sophos-2023] [Shbair-2015]. The governments of 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 observed in Russia in March 2022 [Elmenhorst-2022].

4.2.3.2. Encrypted SNI (ESNI)
4.2.3.2. 暗号化されたSNI(ESNI)

With the data leakage present with the SNI field, a natural response is to encrypt it, which is forthcoming in TLS 1.3 with Encrypted Client Hello (ECH). Prior to ECH, the ESNI extension is available to prevent the data leakage caused by SNI, which encrypts only the SNI field. Unfortunately, censors can target connections that use the ESNI extension specifically for censorship. This guarantees over-blocking for the censor but can be worth the cost if ESNI is not yet widely deployed within the country. ECH is the emerging standard for protecting the entire TLS ClientHello, but it is not yet widely deployed.

SNIフィールドに存在するデータ漏洩に対処するための自然な対応策は、それを暗号化することです。これはTLS 1.3でEncrypted Client Hello (ECH)として提供されます。ECHの前に、SNIによって引き起こされるデータ漏洩を防ぐために利用可能なESNI拡張機能があります。ESNIはSNIフィールドのみを暗号化します。残念ながら、検閲者は検閲のためにESNI拡張機能を使用する接続を標的にすることができます。これにより、検閲者にとっては過剰なブロックが保証されますが、ESNIがまだ国内で広く展開されていない場合にはそのコストに値するかもしれません。ECHはTLS ClientHello全体を保護するための新興の標準ですが、まだ広く展開されていません。

Trade-offs: The cost to censoring ESNI is significantly higher than SNI to a censor, as the censor can no longer target censorship to specific domains and guarantees over-blocking. In these cases, the censor uses the over-blocking to discourage the use of ESNI entirely.

トレードオフ:ESNIの検閲コストはSNIよりもはるかに高くなります。検閲者は特定のドメインに対する検閲を行うことができなくなり、過剰ブロッキングが保証されます。これらの場合、検閲者は過剰ブロッキングを利用してESNIの使用を抑制します。

Empirical Examples: In 2020, China began censoring all uses of ESNI [Bock-2020b], even for innocuous connections. The censorship mechanism for China's ESNI censorship differs from how China censors SNI-based connections, suggesting that new middleboxes were deployed specifically to target ESNI connections.

実証例:2020年、中国はESNIの使用をすべて検閲し始めました[Bock-2020b]。たとえ無害な接続であってもです。中国のESNI検閲のメカニズムは、中国がSNIベースの接続を検閲する方法とは異なります。これは、新しいミドルボックスが特にESNI接続を対象に展開されたことを示唆しています。

4.2.3.3. Omitted SNI
4.2.3.3. 省略されたSNI

Researchers have observed that some clients omit the SNI extension entirely. This omitted-SNI approach limits the information available to a censor. Like with ESNI, censors can choose to block connections that omit the SNI, though this too risks over-blocking.

研究者は、一部のクライアントがSNI拡張機能を完全に省略することを観察しています。この省略されたSNIアプローチは、検閲者が利用できる情報を制限します。ESNIと同様に、検閲者はSNIを省略する接続をブロックすることを選択できますが、これも過剰ブロックのリスクを伴います。

Trade-offs: The approach of censoring all connections that omit the SNI field is guaranteed to over-block, though connections that omit the SNI field should be relatively rare in the wild.

トレードオフ:SNIフィールドを省略するすべての接続を検閲するアプローチは、過剰にブロックされることが保証されていますが、野生でSNIフィールドを省略する接続は比較的まれであるはずです。

Empirical Examples: In the past, researchers have observed censors in Russia blocking connections that omit the SNI field [Bock-2020b].

過去に、研究者はロシアの検閲官がSNIフィールドを省略した接続をブロックしているのを観察してきました。

4.2.3.4. Server Response Certificate
4.2.3.4. サーバー応答証明書

During the TLS handshake after the TLS ClientHello, the server will respond with the TLS certificate. This certificate also contains the domain the client is trying to access, creating another avenue that censors can use to perform censorship. This technique will not work in TLS 1.3, as the certificate will be encrypted.

TLSハンドシェイク中のTLS ClientHelloの後、サーバーはTLS証明書で応答します。この証明書には、クライアントがアクセスしようとしているドメインも含まれており、検閲者が検閲を行うために使用できる別の手段が作成されます。この技術はTLS 1.3では機能しません。証明書は暗号化されるためです。

Trade-offs: Censoring based on the server certificate requires DPI techniques that can be more computationally expensive compared to other methods. Additionally, the certificate is sent later in the TLS handshake compared to the SNI field, forcing the censor to track the connection longer.

トレードオフ:サーバー証明書に基づく検閲は、他の方法と比較してより計算量が多いDPI技術を必要とします。さらに、証明書はSNIフィールドよりもTLSハンドシェイクの後に送信されるため、検閲者は接続をより長く追跡する必要があります。

Empirical Examples: Researchers have observed the Reliance Jio ISP in India using certificate response fields to censor connections [Satija-2021].

Empirical Examples: Researchers have observed the Reliance Jio ISP in India using certificate response fields to censor connections [Satija-2021].

4.2.4. Instrumenting Content Distributors
4.2.4. コンテンツ配信業者の計測

Many governments pressure content providers to censor themselves, or provide the legal framework, within which content distributors are incentivized to follow the content restriction preferences of agents external to the content distributor [Boyle-1997]. Due to the extensive reach of such censorship, we define "content distributor" as any service that provides utility to users, including everything from websites to storage to locally installed programs.

多くの政府は、コンテンツプロバイダーに自主規制を求めたり、コンテンツ配信業者が外部のエージェントのコンテンツ制限の要望に従うようにインセンティブを与える法的枠組みを提供したりしています[Boyle-1997]。そのような検閲の広範な影響を考慮して、私たちは「コンテンツ配信業者」を、ウェブサイトからストレージ、ローカルにインストールされたプログラムまで、ユーザーに有用性を提供するすべてのサービスと定義しています。

A commonly used method of instrumenting content distributors consists of keyword identification to detect restricted terms on their platforms. Governments may provide the terms on such keyword lists. Alternatively, the content provider may be expected to come up with their own list.

コンテンツ配信業者を計測するために一般的に使用される方法は、制限された用語を検出するためのキーワード識別です。政府はそのようなキーワードリストに用語を提供することがあります。別の方法として、コンテンツ提供業者が独自のリストを作成することが期待される場合もあります。

An increasingly common method of instrumenting content distribution consists of hash matching to detect and take action against images and videos known to be restricted either by governments, institutions, organizations or the distributor themselves [ekr-2021].

コンテンツ配信をインストゥルメント化する、ますます一般的な方法は、ハッシュマッチングを使用して、政府、機関、組織、または配信業者自身によって制限されていると知られている画像や動画を検出し、対処することです。

A different method of instrumenting content distributors consists of requiring a distributor to disassociate with some categories of users. See also Section 6.4.

コンテンツ配信業者を計測する別の方法は、配信業者に特定のユーザーカテゴリとの関係を解消することを要求することです。セクション6.4も参照してください。

Trade-offs: By instrumenting content distributors to identify restricted content or content providers, the censor can gain new information at the cost of political capital with the companies it forces or encourages to participate in censorship. For example, the censor can gain insight about the content of encrypted traffic by coercing websites to identify restricted content. Coercing content distributors to regulate users, categories of users, content, and content providers may encourage users and content providers to exhibit self-censorship, an additional advantage for censors (see Section 6.2). The trade-offs for instrumenting content distributors are highly dependent on the content provider and the requested assistance. A typical concern is that the targeted keywords or categories of users are too broad, risk being too broadly applied, or are not subjected to a sufficiently robust legal process prior to their mandatory application (see page 8 of [EC-2012]).

取引のオフ: コンテンツ配信業者に計器を取り付けて、制限されたコンテンツやコンテンツプロバイダーを特定することで、検閲者は新しい情報を得ることができますが、強制または参加を促す企業との政治的資本のコストがかかります。例えば、検閲者は、ウェブサイトに制限されたコンテンツを特定するよう強制することで、暗号化されたトラフィックの内容について洞察を得ることができます。コンテンツ配信業者にユーザー、ユーザーのカテゴリ、コンテンツ、およびコンテンツプロバイダーを規制するよう強制することで、ユーザーやコンテンツプロバイダーが自己検閲を行うことを促すことができ、これは検閲者にとって追加の利点となります(セクション6.2を参照)。コンテンツ配信業者に計器を取り付ける際の取引のオフは、コンテンツプロバイダーと要求される支援に大きく依存しています。典型的な懸念事項は、対象となるキーワードやユーザーのカテゴリが広すぎる、広く適用されすぎるリスクがある、または強制適用前に十分に堅固な法的手続きに従っていない可能性があることです([EC-2012]の8ページを参照)。

Empirical Examples: Researchers discovered keyword identification by content providers on platforms ranging from instant messaging applications [Senft-2013] to search engines [Rushe-2014] [Cheng-2010] [Whittaker-2013] [BBC-2013] [Condliffe-2013]. To demonstrate the prevalence of this type of keyword identification, we look to search engine censorship.

実証例:研究者は、インスタントメッセージングアプリケーション[Senft-2013]から検索エンジン[Rushe-2014] [Cheng-2010] [Whittaker-2013] [BBC-2013] [Condliffe-2013]までのプラットフォームでのコンテンツプロバイダーによるキーワード識別を発見しました。この種のキーワード識別の普及を示すために、検索エンジンの検閲を見てみましょう。

Search engine censorship demonstrates keyword identification by content providers and can be regional or worldwide. Implementation is occasionally voluntary, but normally it is based on laws and regulations of the country a search engine is operating in. 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 to acquire and keep an Internet Content Provider (ICP) license [Cheng-2010]. It is clear these blocklists are maintained by each search engine provider based on the slight variations in the intercepted searches [Zhu-2011] [Whittaker-2013]. The United Kingdom has been pushing search engines to self-censor with the threat of litigation if they do not do it themselves: Google and Microsoft have 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 modification of search engine results in response to either copyright, trademark, data protection, or defamation concerns [EC-2012].

検索エンジンの検閲は、コンテンツプロバイダーによるキーワードの特定を示し、地域または世界的なものである可能性があります。実装は時折自発的ですが、通常は検索エンジンが運営している国の法律と規制に基づいています。キーワードのブロックリストは、おそらく検索エンジンプロバイダーによって管理されています。中国は、検索エンジンプロバイダーに対して「自発的に」検索用語のブロックリストを維持することを求め、インターネットコンテンツプロバイダー(ICP)ライセンスを取得および維持することが知られています。イギリスは、訴訟の脅威を背景に、検索エンジンに自主的な検閲を促しています。GoogleとMicrosoftは、悪用を防ぐためにイギリスで10万以上のクエリをブロックすることに同意しました。欧州連合法および米国法は、著作権、商標、データ保護、名誉毀損の懸念に対応して、検索エンジンの検索結果を修正することを要求しています。

Depending on the output, search engine keyword identification may be difficult or easy to detect. In some cases, specialized or blank results provide a trivial enumeration mechanism, but more subtle censorship can be difficult to detect. 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 is possible that censorship of the largest base of Chinese search users, China, biased Bing's results so that the more popular results in China (the uncensored results) were also more popular for Chinese speakers outside of China.

出力によって、検索エンジンのキーワード識別は検出が難しいか簡単かが異なります。いくつかの場合、専門的または空白の結果は取るに足らない列挙メカニズムを提供しますが、より微妙な検閲は検出が難しいかもしれません。2015年2月、マイクロソフトの検索エンジンであるBingは、中国外の中国語コンテンツを検閲していると非難されました[Rushe-2014]。なぜなら、Bingは中国語と英語の検閲された用語に対して異なる結果を返していたからです。ただし、中国の最大の検索ユーザーである中国の検閲がBingの結果に偏っている可能性があり、その結果、中国でより人気のある結果(検閲されていない結果)が中国外の中国語話者にとってもより人気があったかもしれません。

Disassociation by content distributors from certain categories of users has happened for instance in Spain, as a result 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 disassociated themselves from top players who expressed political opinions in relation to the 2019 Hong Kong protests [Victor-2019]. See also Section 5.3.1.

コンテンツ配信業者が特定のユーザーカテゴリから離れることが、例えばスペインでは、カタルーニャ独立運動とスペインの法的な統一国家の前提との間の対立の結果として起こりました[Lomas-2019]。Eスポーツイベントの主催者も、2019年の香港抗議運動に関連した政治的意見を表明したトッププレイヤーから距離を置いています[Victor-2019]。また、5.3.1節も参照してください。

4.2.5. DPI Identification
4.2.5. DPI識別

DPI technically is any kind of packet analysis beyond IP address and port number and has become computationally feasible as a component of censorship mechanisms in recent years [Wagner-2009]. Unlike other techniques, DPI reassembles network flows to examine the application "data" section, as opposed to only headers, and is therefore often used for keyword identification. DPI also differs from other identification technologies because it can leverage additional packet and flow characteristics, e.g., packet sizes and timings, when identifying content. To prevent substantial QoS impacts, DPI normally analyzes a copy of data while the original packets continue to be routed. Typically, the traffic is split using either a mirror switch or fiber splitter and analyzed on a cluster of machines running Intrusion Detection Systems (IDSs) configured for censorship.

DPI(Deep Packet Inspection)は、IPアドレスやポート番号を超えたパケット解析の一種であり、近年、検閲メカニズムの一部として計算上実現可能になってきました[Wagner-2009]。他の技術とは異なり、DPIはネットワークフローを再構築してアプリケーションの「データ」セクションを調査します。そのため、通常はヘッダーだけでなく、キーワードの識別に使用されます。DPIは、コンテンツの識別時にパケットサイズやタイミングなどの追加のパケットやフローの特性を活用できるため、他の識別技術とは異なります。重大なQoS(Quality of Service)への影響を防ぐため、DPIは通常、元のパケットがルーティングされ続ける間にデータのコピーを解析します。通常、トラフィックはミラースイッチまたはファイバースプリッターを使用して分割され、検閲用に構成されたIntrusion Detection Systems(IDS)を実行するマシンのクラスターで分析されます。

Trade-offs: DPI is one of the most expensive identification mechanisms and can have a large QoS impact [Porter-2005]. When used as a keyword filter for TCP flows, DPI systems can cause also major over-blocking problems. Like other techniques, DPI is less useful against encrypted data, though DPI can leverage unencrypted elements of an encrypted data flow (e.g., the Server Name Indication (SNI) sent in the clear for TLS) or metadata about an encrypted flow (e.g., packet sizes, which differ across video and textual flows) to identify traffic. See Section 4.2.3.1 for more information about SNI-based filtration mechanisms.

トレードオフ:DPIは最も高価な識別メカニズムの1つであり、大きなQoSへの影響を与える可能性があります[Porter-2005]。 DPIシステムはTCPフローのキーワードフィルターとして使用されると、主要な過剰ブロッキングの問題も引き起こす可能性があります。他の技術と同様に、DPIは暗号化されたデータに対してはあまり有用ではありませんが、DPIは暗号化されたデータフローの暗号化されていない要素(例:TLSのためにクリアで送信されるServer Name Indication(SNI))や暗号化されたフローに関するメタデータ(例:ビデオとテキストのフロー間で異なるパケットサイズ)を利用してトラフィックを識別することができます。SNIベースのフィルタリングメカニズムに関する詳細はセクション4.2.3.1を参照してください。

Other kinds of information can be inferred by comparing certain unencrypted elements exchanged during TLS handshakes to similar data points from known sources. This practice, called "TLS fingerprinting", allows a probabilistic identification of a party's operating system, browser, or application, based on a comparison of the specific combinations of TLS version, ciphersuites, compression options, etc., sent in the ClientHello message to similar signatures found in unencrypted traffic [Husak-2016].

他の種類の情報は、TLSハンドシェイク中に交換される特定の暗号化されていない要素を既知のソースからの類似データポイントと比較することで推測することができます。この実践は、「TLSフィンガープリンティング」と呼ばれ、ClientHelloメッセージで送信されるTLSバージョン、暗号スイート、圧縮オプションなどの特定の組み合わせを、暗号化されていないトラフィックで見つかる類似の署名と比較することに基づいて、当事者のオペレーティングシステム、ブラウザ、またはアプリケーションを確率的に識別することを可能にします[Husak-2016]。

Despite these problems, DPI is the most powerful identification method and is 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 and to inject TCP RSTs and bad DNS responses, respectively, into connections [Crandall-2010] [Clayton-2006] [Anonymous-2014].

これらの問題にもかかわらず、DPIは最も強力な識別方法であり、実践的に広く使用されています。中国のグレートファイアウォール(GFW)は、世界最大の検閲システムであり、DPIを使用してHTTPおよびDNS上の制限されたコンテンツを識別し、それぞれ接続にTCP RSTおよび悪質なDNS応答を挿入します。

Empirical Examples: Several studies have found evidence of censors using DPI for censoring 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 discover 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 subsequently attack pro-opposition material [Wagstaff-2013]. It also seems likely that organizations that are not so worried about blocking content in real time could use DPI to sort and categorically search gathered traffic using technologies such as high-speed packet processing [Hepting-2011].

実証例:いくつかの研究で、検閲者がDPIを使用してコンテンツやツールを検閲している証拠が見つかっています。Claytonら、Crandalら、Anonymous、およびKhattakらは、すべてGFWを探究しました[Khattak-2013] [Crandall-2010] [Clayton-2006] [Anonymous-2014]。Khattakらは、ファイアウォールを調査して、どれだけの状態を保存しているかなどの実装の詳細を発見しました[Khattak-2013]。Torプロジェクトは、中国、イラン、エチオピアなどがobfs2プロトコルをブロックするためにDPIを使用していると主張しています[Wilde-2012]。マレーシアは、対象指向のDPIを使用し、DDoSと組み合わせて野党支持派の資料を特定し、その後攻撃すると非難されています[Wagstaff-2013]。リアルタイムでコンテンツをブロックすることにあまり懸念を抱いていない組織が、高速パケット処理などの技術を使用して収集されたトラフィックを分類して検索するためにDPIを使用する可能性もあります[Hepting-2011]。

4.3. Transport Layer
4.3. トランスポート層
4.3.1. Shallow Packet Inspection and Transport Header Identification
4.3.1. 浅いパケット検査とトランスポートヘッダーの識別

Of the various shallow packet inspection methods, transport header identification is the most pervasive, reliable, and predictable type of identification. Transport headers contain a few invaluable pieces of information that must be transparent for traffic to be successfully routed: destination and source IP address and port. Destination and source IP are doubly useful, as not only do they allow a censor to block undesirable content via IP blocklisting but also allow a censor to identify the IP of the user making the request and the IP address of the destination being visited, which in most cases can be used to infer the domain being visited [Patil-2019]. Port is useful for allowlisting certain applications.

さまざまな浅いパケット検査方法の中で、トランスポートヘッダー識別は最も普及しており、信頼性が高く、予測可能な識別のタイプです。トランスポートヘッダーには、トラフィックを正常にルーティングするために透過的である必要があるいくつかの貴重な情報が含まれています:宛先およびソースIPアドレスとポート。宛先およびソースIPは、センサーがIPブロックリストを使用して望ましくないコンテンツをブロックするだけでなく、リクエストを行っているユーザーのIPと訪れている宛先のIPアドレスを特定することができるため、二重に有用です。ほとんどの場合、訪れているドメインを推測するために使用できます。ポートは特定のアプリケーションをホワイトリストに登録するために役立ちます。

By combining IP address, port, and protocol information 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].

輸送ヘッダーに見つかるIPアドレス、ポート、およびプロトコル情報を組み合わせることで、検閲者は特定のTCPまたはUDPエンドポイントを特定するために浅いパケット検査を使用できます。UDPエンドポイントのブロックは、QUICブロッキングの文脈で観察されています[Elmenhorst-2021]。

Trade-offs: Header identification is popular due to its simplicity, availability, and robustness.

トレードオフ:ヘッダー識別はそのシンプルさ、利用可能性、頑丈さから人気があります。

Header identification is trivial to implement in some routers, but is difficult to implement in backbone or ISP routers at scale, and is therefore typically implemented with DPI. Blocklisting an IP is equivalent to installing a specific route on a router (such as a /32 route for IPv4 addresses and a /128 route for IPv6 addresses). However, due to limited flow table space, this cannot scale beyond a few thousand IPs at most. IP blocking is also relatively crude. It often leads to over-blocking and cannot deal with some 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 circumvent this type of identification. In addition, IP blocking is effective against all protocols above IP, e.g., TCP and QUIC.

ヘッダー識別は一部のルーターで簡単に実装できますが、バックボーンやISPのルーターでは規模に応じて実装が難しく、そのため通常はDPIで実装されます。IPをブロックすることは、ルーターに特定のルートをインストールすることと同等です(IPv4アドレスの場合は/32ルート、IPv6アドレスの場合は/128ルートなど)。ただし、フローテーブルのスペースが限られているため、最大でも数千のIPを超えるスケーリングはできません。IPブロックは比較的粗いものです。しばしば過剰ブロックを引き起こし、数百または数千のIPアドレスでコンテンツをホストするコンテンツ配信ネットワーク(CDN)などの一部のサービスに対処できません。これらの制限にもかかわらず、IPブロックは非常に効果的です。なぜなら、ユーザーはこの種の識別を回避するためにトラフィックを別の宛先を介してプロキシする必要があるからです。さらに、IPブロックはIP以上のすべてのプロトコル(例:TCPやQUIC)に対して効果的です。

Port blocking is generally not useful because many types of content share the same port, and it is possible for censored applications to change their port. For example, most HTTP traffic goes over port 80, so the censor cannot differentiate between restricted and allowed web content solely on the basis of port. HTTPS goes over port 443, with similar consequences for the censor except only partial metadata may now be available to the censor. Port allowlisting is occasionally used, where a censor limits communication to approved ports (such as 80 for HTTP traffic), and is most effective when used in conjunction with other identification mechanisms. For example, a censor could block the default HTTPS port (port 443), thereby forcing most users to fall back to HTTP. A counterexample is that port 25 (SMTP) has long been blocked on residential ISP networks to reduce the risk of email spam, but doing this also prohibits residential ISP customers from running their own email servers.

ポートブロッキングは一般的に有用ではありません。多くの種類のコンテンツが同じポートを共有しており、検閲されたアプリケーションがポートを変更する可能性があるためです。たとえば、ほとんどのHTTPトラフィックはポート80を通過するため、検閲者はポートだけで制限されたコンテンツと許可されたウェブコンテンツを区別することができません。HTTPSはポート443を通過しますが、検閲者には部分的なメタデータしか利用できなくなります。ポートの許可リストは時折使用されます。検閲者が承認されたポート(たとえばHTTPトラフィックの80番ポートなど)への通信を制限する場合で、他の識別メカニズムと併用すると最も効果的です。たとえば、検閲者はデフォルトのHTTPSポート(ポート443)をブロックすることで、ほとんどのユーザーをHTTPに戻すことができます。一方、ポート25(SMTP)は長らく住宅向けISPネットワークでブロックされており、メールスパムのリスクを軽減するためですが、これにより住宅向けISPの顧客は自分自身のメールサーバーを運用することができなくなります。

4.3.2. Protocol Identification
4.3.2. プロトコル識別

Censors sometimes identify entire protocols to be blocked 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 that they can analyze [Aryan-2013]. A simple protocol identification would be to recognize all TCP traffic over port 443 as HTTPS, but a more sophisticated analysis of the statistical properties of payload data and flow behavior would be more effective, even when port 443 is not used [Hjelmvik-2010] [Sandvine-2015].

時には、検閲者はさまざまなトラフィック特性を使用してブロックするためにプロトコル全体を特定します。例えば、イランはHTTPSトラフィックのパフォーマンスを低下させ、さらなる解析を防ぐプロトコルであるHTTPSに切り替えるようユーザーに促すために、HTTPに切り替えるようにしています。TCPトラフィックのすべてをポート443経由でHTTPSと認識する簡単なプロトコル識別もありますが、ペイロードデータとフロー動作の統計的特性をより洗練された分析する方が効果的です。ポート443が使用されていない場合でも[Hjelmvik-2010] [Sandvine-2015]。

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

もし検閲者が回避ツールを検出できれば、それらをブロックすることができます。そのため、中国のような検閲者は、検閲回避ツールのプロトコルを特定することに非常に興味を持っています。近年、これは検閲者と回避ツール開発者の間の競争に発展しています。この競争の一環として、中国は「アクティブプロービング」または「アクティブスキャン」と呼ばれる、非常に効果的なプロトコル識別技術を開発しました。

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

アクティブプロービングでは、検閲者は回避プロトコルを実行しているホストを特定するために、回避プロトコルを使用して通信を試みます。ホストと検閲者が接続を成功裏に交渉した場合、検閲者はホストが回避ツールを実行していることを確実に知ることができます。中国はTorをブロックするためにアクティブスキャンを効果的に使用してきました。

Trade-offs: Protocol identification only provides insight into the way information is traveling, and not the information itself.

トレードオフ:プロトコル識別は情報がどのように移動しているかを示すだけであり、情報そのものではありません。

Protocol identification is useful for detecting and blocking circumvention tools (like Tor) or traffic that is 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 problems when used with popular protocols. These methods are expensive, both computationally and financially, due to the use of statistical analysis and can be ineffective due to their imprecise nature.

プロトコルの識別は、回避ツール(Torなど)や分析が難しいトラフィック(VoIPやSSLなど)を検出してブロックするのに役立ちます。検閲者はこのトラフィックをブロックすべきだと仮定できます。ただし、一般的なプロトコルと組み合わせて使用すると、過剰ブロックの問題が発生する可能性があります。これらの方法は、統計分析を使用するため、計算上、財政上ともに費用がかかり、不正確な性質のために効果がないことがあります。

Censors have also used protocol identification in the past in an "allowlist" filtering capacity, such as by only allowing specific, pre-vetted protocols to be used and blocking any unrecognized protocols [Bock-2020]. These protocol filtering approaches can also lead to over-blocking if the allowed lists of protocols are too small or incomplete but can be cheap to implement, as many standard "allowed" protocols are simple to identify (such as HTTP).

過去に、検閲者はプロトコル識別を使用して、特定の事前審査済みプロトコルのみを許可し、認識されないプロトコルをブロックする「許可リスト」フィルタリング機能としても使用してきました[Bock-2020]。これらのプロトコルフィルタリングアプローチは、許可されたプロトコルのリストが小さすぎたり不完全だったりすると、過剰ブロックを引き起こす可能性がありますが、多くの標準的な「許可」プロトコルは簡単に識別できるため、実装コストを抑えることができます(たとえばHTTPなど)。

Empirical Examples: Protocol identification can be easy to detect if it is conducted in real time and only a particular protocol is blocked. However, some types of protocol identification, like active scanning, are much more difficult to detect. Protocol identification has been used by Iran to identify and throttle Secure Shell (SSH) protocol traffic to make it unusable [Van-der-Sar-2007] and by China to identify and block Tor relays [Winter-2012]. Protocol identification has also been used for traffic management, such as the 2007 case where Comcast in the United States used RST injection (injection of a TCP RST packet into the stream) to interrupt BitTorrent traffic [Winter-2012]. In 2020, Iran deployed an allowlist protocol filter, which only allowed three protocols to be used (DNS, TLS, and HTTP) on specific ports, and censored any connection it could not identify [Bock-2020]. In 2022, Russia seemed to have used protocol identification to block most HTTP/3 connections [Elmenhorst-2022].

実証例:プロトコル識別は、リアルタイムで行われ、特定のプロトコルのみがブロックされている場合、簡単に検出できることがあります。ただし、アクティブスキャンなどの一部のプロトコル識別は、はるかに検出が難しいです。イランは、セキュアシェル(SSH)プロトコルトラフィックを特定して遮断し、使用不能にするためにプロトコル識別を使用してきました[Van-der-Sar-2007]。また、中国は、Torリレーを特定してブロックするためにプロトコル識別を使用してきました[Winter-2012]。プロトコル識別は、トラフィック管理にも使用されており、2007年には、アメリカのComcastがBitTorrentトラフィックを中断するためにRSTインジェクション(TCP RSTパケットのストリームへのインジェクション)を使用した事例があります[Winter-2012]。2020年には、イランが特定のポートでのみ使用を許可するプロトコルフィルターを導入し、DNS、TLS、HTTPの3つのプロトコルのみを許可し、特定できない接続を検閲しました[Bock-2020]。2022年には、ロシアがHTTP/3接続のほとんどをブロックするためにプロトコル識別を使用したようです[Elmenhorst-2022]。

4.4. Residual Censorship
4.4. 残留検閲

Another feature of some modern censorship systems is residual censorship, a punitive form of censorship whereby after a censor disrupts a forbidden connection, the censor continues to target subsequent connections, even if they are innocuous [Bock-2021]. Residual censorship can take many forms and often relies on the methods of technical interference described in the next section.

一部の現代の検閲システムのもう1つの特徴は、残留検閲です。これは、検閲官が禁止された接続を妨害した後も、その後の接続を対象にし続ける罰則的な検閲の形式です。それらが無害であっても、検閲官は後続の接続を対象にします。残留検閲はさまざまな形を取り、しばしば次のセクションで説明される技術的干渉の方法に依存しています。

An important facet of residual censorship is precisely what the censor continues to block after censorship is initially triggered. There are three common options available to an adversary: 2-tuple (client IP, server IP), 3-tuple (client IP, server IP, server port), or 4-tuple (client IP, client port, server IP, server port). Future connections that match the tuple of information the censor records will be disrupted [Bock-2021].

残存検閲の重要な側面は、検閲が最初にトリガーされた後に検閲者が続けてブロックする内容です。敵対者には、3つの一般的なオプションがあります:2タプル(クライアントIP、サーバーIP)、3タプル(クライアントIP、サーバーIP、サーバーポート)、または4タプル(クライアントIP、クライアントポート、サーバーIP、サーバーポート)。検閲者が記録した情報のタプルに一致する将来の接続は妨害されます[Bock-2021]。

Residual censorship can sometimes be difficult to identify and can often complicate censorship measurement.

残留検閲は時々特定するのが難しく、検閲の測定を複雑にすることがあります。

Trade-offs: The impact of residual censorship is to provide users with further discouragement from trying to access forbidden content, though it is not clear how successful it is at accomplishing this.

トレードオフ:残存する検閲の影響は、ユーザーに禁止されたコンテンツにアクセスしようとする意欲をさらに抑制することですが、それがどれだけ成功しているかは明確ではありません。

Empirical Examples: China has used 3-tuple residual censorship in conjunction with their 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 their 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].

実証例:中国は長年、HTTP検閲と一緒に3タプル残留検閲を使用しており、研究者はHTTPSに対する類似の残留検閲を目撃して報告しています。中国はESNIを使用したHTTPSの検閲において、3タプルと4タプルの残留検閲の組み合わせを使用しているようです。パケットのドロップを通じて検閲を行う一部の検閲者は、イランやカザフスタンを含む、しばしば誤って4タプルの残留検閲を実装しています[Bock-2021]。

5. Technical Interference
5. 技術的な干渉
5.1. Application Layer
5.1. アプリケーション層
5.1.1. DNS Interference
5.1.1. DNSインターフェアランス

There are a variety of mechanisms that censors can use to block or filter access to content by altering responses from the DNS [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 in DNS over HTTPS [RFC8484] and DNS over TLS [RFC7858] that can mitigate interference with DNS queries between the stub and the resolver.

センサーがコンテンツへのアクセスをブロックまたはフィルタリングするために使用できるさまざまなメカニズムがあります。これには、応答をブロックする、エラーメッセージで応答する、または間違ったアドレスで応答するなどが含まれます。スタブとリゾルバー間のDNSクエリに干渉を軽減できるDNS over HTTPS [RFC8484]およびDNS over TLS [RFC7858]の暗号化輸送が現在利用可能であることに注意してください。

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クエリに誤ったアドレスで応答することは、オンパスインターセプト、オフパスキャッシュポイズニング、またはネームサーバーによる嘘をつくことで実現できます。

"DNS mangling" is a network-level technique of on-path interception where an incorrect IP address is returned in response to a DNS query to 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 technique 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:

「DNS mangling」とは、ネットワークレベルの技術であり、検閲された宛先に対するDNSクエリに対して誤ったIPアドレスが返される手法です。例えば、一部の中国のネットワークでこの手法が使われています。(マングリングの広範な使用例については知りません。)これらの中国のネットワークでは、通過する各DNSリクエストが検査され(おそらくDPIなどのネットワーク検査技術によって)、検閲されたドメインに一致する場合、誤った応答が挿入されます。エンドユーザーは、中国の未使用のIPアドレスに対して単純にDNSリクエストを送信することで、この手法を実際に見ることができます(以下の例を参照)。検閲されていない名前の場合、応答はありません。検閲されている場合、偽の応答が返されます。例えば、中国の未使用のIPアドレス192.0.2.2に対して「www.uncensored.example」と「www.censored.example」(執筆時点で検閲されている)の名前を問い合わせるためにコマンドラインのdigユーティリティを使用すると、「198.51.100.0」という偽のIPアドレスが応答として返されます。

   % 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 and 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 respond 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, causing 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, preventing a response from ever being sent [Aryan-2013].

DNSキャッシュポイズニングは、オフパスで発生し、検閲者が権威あるDNSネームサーバーが再帰的リゾルバに送信する応答に干渉するメカニズムを指し、権威あるネームサーバーが代替IPアドレスで応答する前に、検閲者がより迅速に応答することを指します。キャッシュポイズニングは、要求されたサイトのネームサーバーがリクエストを解決し、真のIPを要求デバイスに返そうとする後に発生します。返り路では、解決されたIPが最初にリクエストを転送した各DNSサーバーによって再帰的にキャッシュされます。このキャッシュプロセス中に望ましくないキーワードが認識されると、解決されたIPが「毒され」、上流のリゾルバが応答するよりも迅速に代替IP(またはNXDOMAINエラー)が返され、偽のIPアドレスがキャッシュされる(そして再帰的になる可能性があります)。代替IPは通常、ナンセンスなドメインまたは警告ページにリダイレクトされます。また、イランの検閲は、通信経路で通信を阻止し、応答が送信されるのを防ぐようです。

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 than what an authoritative name server would provide [Bortzmeyer-2015].

「DNS lying」と俗に呼ばれるケースもあります。ここで、検閲者が、再帰リゾルバ(インターネットアクセスプロバイダなど)の提供するDNS応答を、権威あるネームサーバが提供するものと異なるものにするよう指示する場合があります(Bortzmeyer-2015)。

Trade-offs: These forms of DNS interference require the censor to force a user to traverse a controlled DNS hierarchy (or 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 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.

トレードオフ:これらの形態のDNS干渉は、検閲者が効果的にするためにユーザーに制御されたDNS階層(または検閲者がDNS応答を書き換えるためのアクティブな普遍的攻撃者として機能する介在するネットワーク[RFC7624]を横断させる必要があります。 DNS干渉は、検閲者の管轄外にある可能性がある代替DNSリゾルバ(たとえば、公共DNSリゾルバのいずれか)や、仮想プライベートネットワーク(VPN)技術を使用することで回避することができます。 DNSの改ざんやキャッシュポイゾニングは、ドメイン名を解決しようとする人に間違ったIPを返すことを意味しますが、場合によっては宛先が技術的にアクセス可能である可能性があります。たとえば、HTTP経由で、ユーザーは目的のサイトのIPアドレスを取得する別の方法を持っているかもしれず、そのサイトがこのIPアドレスでリッスンするデフォルトサーバーに設定されている場合はアクセスできるかもしれません。ターゲットのブロックも問題となっており、時折、検閲者の地域外のユーザーが、検閲者が制御するDNSサーバーやDNS書き換えネットワーク機器を介して誘導され、リクエストが失敗することがあります。回避の容易さとコンテンツブロックやターゲットブロックの大きなリスクとの組み合わせにより、DNS干渉は部分的であり、困難で理想とは程遠い検閲メカニズムとなっています。

Additionally, the above mechanisms rely on DNSSEC not being deployed or DNSSEC validation not being active on the client or recursive resolver (neither of which 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.

さらに、上記のメカニズムは、DNSSECが展開されていないか、クライアントや再帰リゾルバでDNSSEC検証が有効になっていないことを前提としています(DNSSECの展開が限られており、DNSSEC検証のクライアントサポートが限られていることを考えると、それは想像しやすいことです)。単に解決をブロックしようとする敵対者は、当然、クライアントや再帰リゾルバが検証すると仮定して、正しく検証されないDNSSECレコードを提供することができます。

Previously, techniques were used for censorship that 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] no longer passed in the clear (see also Section 4.3.1).

以前は、DNSリクエストがポート53を通じてクリアテキストで送信されることに依存する検閲技術が使用されていました[SSAC-109-2020]。暗号化されたDNS(例:DNS over HTTPS [RFC8484])の展開により、これらのリクエストは今ではポート443を通じて他のHTTPSトラフィックと一緒に送信されるようになりました。また、DNS over TLS [RFC7858]の場合、クリアテキストでの送信は行われなくなりました(詳細は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

実証例:DNS干渉は、適切に実装された場合、上記の欠点に基づいて簡単に特定できます。トルコは2014年3月に、TwitterやYouTubeを含むウェブサイトの国内ブロックにDNS干渉を頼りました。回避が容易であったため、Twitterの人気が増加し、トルコのISPが政府の命令を達成するためにIPブロックリストを実装するまで続きました[Zmijewski-2014]。最終的に、トルコのISPはGoogleとLevel 3の国際DNSリゾルバへのすべてのリクエストを乗っ取り始めました[Zmijewski-2014]。DNS干渉は、誤って実装された場合、最大の検閲災害のいくつかを引き起こしています。2014年1月、中国は、適切に構成されていないDNSポイズニングの試みにより、すべてのリクエストを「dongtaiwang.com」という単一のドメインに誘導し始めました。この事件は、史上最大のインターネットサービスの停止と考えられています[AFP-2014] [Anon-SIGCOMM12]。中国、トルコ、アメリカなどの国々は、トップレベルドメイン(TLD)全体をブロックすることについても議論しています[Albert-2011]。DNSブロッキングは、ヨーロッパ諸国で望ましくないコンテンツに対処するために一般的に展開されています。

* child abuse content (Norway, United Kingdom, Belgium, Denmark, Finland, France, Germany, Ireland, Italy, Malta, the Netherlands, Poland, Spain, and Sweden [Wright-2013] [Eneman-2010]),

* 児童虐待コンテンツ(ノルウェー、イギリス、ベルギー、デンマーク、フィンランド、フランス、ドイツ、アイルランド、イタリア、マルタ、オランダ、ポーランド、スペイン、およびスウェーデン【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])),

* オンラインギャンブル(ベルギー、ブルガリア、チェコ共和国、キプロス、デンマーク、エストニア、フランス、ギリシャ、ハンガリー、イタリア、ラトビア、リトアニア、ポーランド、ポルトガル、ルーマニア、スロバキア、スロベニア、スペイン([EC-gambling-2012]、[EC-gambling-2019]のセクション6.3.2を参照))、

* copyright infringement (all European Economic Area countries),

* 著作権侵害(欧州経済領域全域)

* hate speech and extremism (France [Hertel-2015]), and

* 憎悪表現や過激主義(フランス[Hertel-2015])と、

* terrorism content (France [Hertel-2015]).

* テロリズムの内容(フランス[Hertel-2015])。

5.2. Transport Layer
5.2. トランスポート層
5.2.1. Performance Degradation
5.2.1. 性能の低下

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 to use a different site, service, or method of communication or 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 is one example of a performance degradation.

このセクションで概説されている他の干渉技術が主にコンテンツへのアクセスをブロックしたり防止することに焦点を当てているのに対し、ある場合には、特定の宛先やサービスへのアクセスを完全にブロックするのではなく、ネットワーク接続のパフォーマンスを低下させることが効果的な検閲戦略となることがあります。パフォーマンス低下下でのサイトやサービスのユーザーエクスペリエンスは非常に悪くなるため、ユーザーは別のサイト、サービス、または通信手段を選択するか、代替手段がない場合は全く通信を行わないことがあります。特定の種類のトラフィックに利用可能な帯域幅を制限するトラフィック整形技術は、パフォーマンス低下の一例です。

Trade-offs: While implementing a performance degradation will not always eliminate the ability of people to access a desire 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].

実証例:イランは、暗号化されていないHTTPトラフィックを促進するためにHTTPSトラフィックで利用可能な帯域幅を調整することで知られています[Aryan-2013]。

5.2.2. Packet Dropping
5.2.2. パケットのドロップ

Packet dropping is a simple mechanism to prevent undesirable traffic. The censor identifies undesirable traffic and chooses to not properly forward any packets it sees associated with the traversing undesirable traffic instead of following a normal routing protocol. This can be paired with any of the previously described mechanisms so long as the censor knows the user must route traffic through a controlled router.

パケットのドロップは望ましくないトラフィックを防ぐための簡単なメカニズムです。検閲者は望ましくないトラフィックを特定し、通常のルーティングプロトコルに従う代わりに、そのトラフィックを通過するパケットを適切に転送しないように選択します。これは、ユーザーがトラフィックを制御されたルーターを介してルーティングする必要があることを検閲者が知っている限り、以前に説明したメカニズムのいずれかと組み合わせることができます。

Trade-offs: Packet dropping is most successful when every traversing packet has transparent information linked to undesirable content, such as a destination IP. One downside packet dropping suffers from is the necessity of blocking all content from otherwise allowable IPs based on a single subversive subdomain; blogging services and GitHub repositories are good examples. China famously dropped all GitHub packets for three days based on a single repository hosting undesirable content [Anonymous-2013]. The need to inspect every traversing packet in almost real time also makes packet dropping somewhat challenging from a QoS perspective.

トレードオフ:パケットのドロップは、透過的な情報が不要なコンテンツ(例:宛先IPなど)にリンクされている場合に最も効果的です。パケットのドロップが抱える欠点の1つは、1つの反逆的なサブドメインに基づいて、それ以外の許可されたIPからのすべてのコンテンツをブロックする必要があることです。ブログサービスやGitHubリポジトリが良い例です。中国は、望ましくないコンテンツをホストする1つのリポジトリに基づいて、3日間すべてのGitHubパケットをドロップしました[Anonymous-2013]。ほぼリアルタイムですべてのトラバーシングパケットを検査する必要性は、パケットのドロップをQoSの観点からやや難しくしています。

Empirical Examples: Packet dropping is a very common form of technical interference and lends itself to accurate detection given the unique nature of the timeout requests it leaves 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 but 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]).

エンパイリカルな例:パケットのドロップは技術的な干渉の非常に一般的な形態であり、その後に残るタイムアウトリクエストの独自の性質から正確な検出が可能です。中国のグレートファイアウォールは、パケットのドロップをその主要な技術的検閲メカニズムの1つとして使用していることが観察されています[Ensafi-2013]。イランも、SSHのスロットリングのメカニズムとしてパケットのドロップを使用しています[Aryan-2013]。これらは普遍的な検閲の実践の2つの例に過ぎません。特筆すべきは、QUICトラフィックにおいて、ハンドシェイク中や接続中にパケットのドロップが観察された唯一の干渉技術であることです(例:インド、イラン、ロシア、ウガンダ[Elmenhorst-2021][Elmenhorst-2022])。

5.2.3. RST Packet Injection
5.2.3. RSTパケットインジェクション

Packet injection, generally, refers to 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 that is used to interrupt an established stream by sending RST packets to both sides of a TCP connection; as each receiver thinks the other has dropped the connection, the session is terminated.

パケットインジェクションは、一般的には、確立されたトラフィックストリーム内でパケットをスプーフィングするマシン・イン・ザ・ミドル(MITM)ネットワーク干渉技術を指します。RSTパケットは通常、TCP接続の一方が情報の送信を停止したことを他方に知らせ、受信者が接続を閉じるべきことを示すために使用されます。RSTパケットインジェクションは、確立されたストリームを中断するために使用される特定のタイプのパケットインジェクション攻撃であり、TCP接続の両側にRSTパケットを送信することでセッションを終了させます。各受信者は他方が接続を切断したと思うため、セッションが終了します。

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.)

QUIC は、接続が確立されると、この種のインジェクション攻撃に対して脆弱ではありません。QUIC は状態を持たないリセットメカニズムを実装していますが、そのようなリセットは、パケットが以前に発行された(状態を持たないリセット)トークンで終了する場合にのみ、ピアによって受け入れられます。これは推測が難しいです。ハンドシェイク中、QUIC はオフパス攻撃者に対して効果的な保護を提供しますが、以前のパケットを解析した攻撃者によるインジェクション攻撃には脆弱です。詳細については、[RFC9000] を参照してください。

Trade-offs: Although ineffective against non-TCP protocols (QUIC, IPsec), RST packet injection has a few advantages that make it extremely popular as a technique employed for censorship. RST packet injection is an out-of-band interference mechanism, allowing the avoidance of the QoS bottleneck that one can encounter with inline techniques such as packet dropping. This out-of-band property allows a censor to 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 has the advantage of only requiring one of the two endpoints to accept the spoofed packet for the connection to be interrupted.

トレードオフ:非TCPプロトコル(QUIC、IPsec)に対しては効果がないものの、RSTパケットの挿入にはいくつかの利点があり、それが検閲に使用される技術として非常に人気があります。 RSTパケットの挿入は、アウトオブバンドの干渉メカニズムであり、パケットのドロップなどのインライン技術で遭遇する可能性のあるQoSのボトルネックを回避できます。 このアウトオブバンドの特性により、検閲者は通常、光スプリッターによってミラーリングされた情報のコピーを検査できるため、DPIやプロトコル識別との理想的な組み合わせとなります[Weaver-2009]。(このMITMの非同期バージョンは、しばしばサイドマシン(MOTS)と呼ばれます。) RSTパケットの挿入には、接続を中断するためにスプーフィングされたパケットを受け入れる2つのエンドポイントのうちの1つだけが必要という利点もあります。

The difficult part of RST packet injection is spoofing "enough" correct information to ensure one endpoint accepts a RST packet as legitimate; this generally implies a correct IP, port, and TCP sequence number. The sequence number is the hardest to get correct, as [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 important; if it is implemented, it allows for successful Blind RST Injection attacks [Netsec-2011]. When in-window sequencing is allowed, it is trivial to conduct a Blind RST Injection. While the term "blind" injection implies the censor doesn't know any sensitive sequencing information about the TCP stream they are 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パケットのインジェクションの難しい部分は、「十分な」正しい情報を偽装して、エンドポイントがRSTパケットを正当なものとして受け入れるようにすることです。これは一般的に、正しいIP、ポート、およびTCPシーケンス番号を意味します。シーケンス番号を正しく取得するのが最も難しいです。[RFC9293]では、RSTパケットはシーケンスに従っている必要があると指定されていますが、そのRFCはまた、ウィンドウ内のパケットを許可することを推奨しています。このウィンドウ内の推奨事項は重要です。実装されている場合、Blind RST Injection攻撃を成功させることができます。ウィンドウ内のシーケンスが許可されていると、Blind RST Injectionを行うのは簡単です。"blind"インジェクションという用語は、検閲者がTCPストリームに注入している情報について敏感なシーケンス情報を知らないことを意味しますが、彼らは単純にすべての約70000の可能なウィンドウを列挙することができます。これは、SSHやTorなどの暗号化/難読化されたプロトコルを中断するのに特に役立ちます。一部の検閲回避システムは、検閲者が誤った情報を追跡するように混乱させようとすることで、彼らのRSTパケットのインジェクションを無効にします。

RST packet injection relies on a stateful network, making it useless against UDP connections. RST packet injection is 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].

RSTパケットのインジェクションは、状態を持つネットワークに依存しており、UDP接続に対しては無効です。RSTパケットのインジェクションは、その多目的性とすべての種類のTCPトラフィックに対する効果的性質から、現在広く使用されている検閲技術の1つです。最近の研究によると、TCP RSTパケットのインジェクション攻撃は、オフパス攻撃者の場合でも機能する可能性があることが示されています[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], subsequently leading 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].

実証的な例:前述のように、RSTパケットのインジェクションは、DPIやプロトコル識別などの分割を必要とする識別技術と最も頻繁にペアにされます。2007年、ComcastはBitTorrentと識別したトラフィックを中断するためにRSTパケットのインジェクションを使用したとして非難され、その後、米国連邦通信委員会がComcastに対して判決を下しました[VonLohmann-2008] [Schoen-2007]。中国も検閲目的でRSTパケットのインジェクションを使用していることが知られています。この干渉は、Torなどの暗号化/難読化されたプロトコルの中断に特に顕著です[Winter-2012]。

5.3. Routing Layer
5.3. ルーティングレイヤー
5.3.1. Network Disconnection
5.3.1. ネットワークの切断

While it is perhaps the crudest of all techniques employed for censorship, there is no more effective way of making sure undesirable information isn't allowed to propagate on the web than by 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.

情報を抑制するために使用される技術の中でも、もっとも粗雑な手法かもしれませんが、ネットワークをシャットダウンすることほど、望ましくない情報がウェブ上で伝播されるのを防ぐための効果的な方法はありません。検閲当局が自国を通過するすべてのBorder Gateway Protocol(BGP)プレフィックスを撤回すると、その地域のネットワークを論理的に切断することができます。

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 as 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 in a country.

トレードオフ:地域でのネットワークの切断の影響は非常に大きく、絶対的です。検閲者は、グローバルにアクセス可能なインターネットがもたらす利点を失うことで、デジタル情報に対する絶対的な制御を支払います。ネットワークの切断は、インターネットプラットフォームやサービスにアクセスすることに慣れている市民にとって、市民の自由の喪失と見なされるため、政治的にも高いコストがかかります。ネットワークの切断は、検閲者にとってほとんど長期的な解決策ではなく、通常は国内で大規模な市民の不安定状態が発生した場合にのみ、最終手段として使用されます。

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].

実証例:ネットワークの切断は、主にそのような行動がもたらす巨大な社会的、政治的、経済的影響のため、大きな不安定時にのみ起こりがちです。最初に大きく取り上げられた出来事の1つは、ミャンマーの軍事政権が2007年に反乱を鎮圧するためにネットワークの切断を行ったときでした[Dobie-2007]。中国は2009年の不安定時に新疆地域のネットワークを切断し、抗議活動が他の地域に広がるのを防ごうとしました[Heacock-2009]。アラブの春では、2011年にエジプトとリビア[Cowie-2011]、2012年にシリア[Thomson-2012]でネットワークの切断が最も頻繁に行われました。ロシアは2019年4月に、国のネットワーク独立のテストの一環として、すべてのロシアのネットワークを世界のインターネットから切断しようと示唆しました。報告によると、テストの切断の一環として、ロシアの通信企業はすべてのトラフィックを国営の監視ポイントにルーティングする必要があるとされています[Cimpanu-2019]。インドは2016年と2017年に年間最大のインターネットシャットダウン数を記録しました[Dada-2017]。

5.3.2. Adversarial Route Announcement
5.3.2. 敵対的な経路の発表

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 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, where the latter attacks traffic by deliberately introducing bogus BGP announcements that reach the global Internet.

BGPハイジャッキングを使用すると、より細かく、かつ広範囲にわたる検閲が可能です。これは、地域内およびそれ以上の範囲でBGP IPプレフィックスを誤って再ルーティングすることで達成されます。これにより、特定の情報の正確な位置が制限され、実質的に検閲され、その管轄区域に流入または流出する情報の正確な位置が制限されます。同様に、敵対的な経路アナウンスが広がることで、その管轄区域外の人々がその管轄区域外で生成されたコンテンツを閲覧するのを防ぎます。前者は、管轄区域を超えて漏洩する意図のない誤った経路の敵対的なBGPアナウンスによって達成されます。後者は、故意に偽のBGPアナウンスを導入し、それがグローバルインターネットに到達することでトラフィックを攻撃します。

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.

トレードオフ:誤経路のウェブサイトのグローバルなリークは、そのウェブサイトが多くのトラフィックを受けると、ISPを圧倒する可能性があります。グローバルにリークする誤ったBGP経路は修正できますが、管轄内でのリークは、ローカルユーザーのためにはISP/IXPによってのみ修正できます。

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].

エンパイリカルな例:2008年、パキスタンの政府の要請により、パキスタンテレコムはYouTubeへのアクセスを遮断するためにBGP経路を変更しました。新しい経路はISPの上流プロバイダーおよびそれ以上に公表されました。インターネット全体がYouTubeの経路をパキスタンテレコムに向け、数時間にわたって続けました。2018年、ほぼすべてのGoogleサービスおよびGoogle Cloudの顧客(Spotifyなど)は、Googleが数百万のIPアドレスの制御を失った後、1時間以上のサービスを失いました。これらのIPプレフィックスは、中国政府所有のISPである中国テレコムに誤誘導されていました。2010年に中国テレコムによって米国政府および軍のウェブサイトがBGPハイジャックされたのと同様の方法でした。ロシア(2022年)およびミャンマー(2021年)のISPは、同じTwitterプレフィックスを複数回ハイジャックしようとしました。

5.4. Multi-layer and Non-layer
5.4. マルチレイヤーとノンレイヤー
5.4.1. Distributed Denial of Service (DDoS)
5.4.1. 分散サービス妨害(DDoS)

Distributed Denial of Service attacks are a common attack mechanism used by "hacktivists" and malicious hackers. Censors have also used DDoS in the past for a variety of reasons. There is a wide variety of DDoS attacks [Wikip-DoS]. However, at a high level, two possible impacts from the attack tend to occur: a flood attack results in the service being unusable while resources are being spent to flood the service, and a crash attack aims to crash the service so resources can be reallocated elsewhere without "releasing" the service.

分散サービス妨害攻撃は、「ハクティビスト」と悪意のあるハッカーによってよく使われる攻撃手法です。検閲者も過去にさまざまな理由でDDoSを使用してきました。DDoS攻撃にはさまざまな種類があります[Wikip-DoS]。しかし、高いレベルでは、攻撃からの可能な影響として、洪水攻撃はサービスが使用不能になる一方で、サービスに洪水をかけるためにリソースが消費され、クラッシュ攻撃はサービスをクラッシュさせ、リソースを「解放」せずに他の場所に再割り当てすることを目指しています。

Trade-offs: DDoS is an appealing mechanism when a censor would like to prevent all access (not just regional access) to undesirable content for a limited period of time. Temporal impermanence is really the only uniquely beneficial feature of DDoS as a technique employed for censorship. The resources required to carry out a successful DDoS against major targets are computationally expensive, usually requiring rental or ownership of a malicious distributed platform such as a botnet, and they are imprecise. DDoS is an incredibly crude censorship technique and appears to largely be used as a timely, easy-to-access mechanism for blocking undesirable content for a limited period of time.

Trade-offs: DDoSは、検閲者が望ましくないコンテンツへのアクセスをすべて(地域的なアクセスだけでなく)一定期間防止したい場合に魅力的なメカニズムです。時間的な不完全性は、検閲目的で使用される技術としてDDoSの唯一の独自の有益な特徴です。主要なターゲットに対する成功したDDoSを実行するために必要なリソースは、計算上高価であり、通常はボットネットなどの悪意のある分散プラットフォームのレンタルまたは所有が必要であり、不正確です。DDoSは非常に原始的な検閲技術であり、望ましくないコンテンツを一定期間ブロックするためのタイムリーで簡単にアクセスできるメカニズムとして主に使用されているようです。

Empirical Examples: In 2012, the U.K.'s signals intelligence organization, the Government Communications Headquarters (GCHQ), used DDoS to temporarily shutdown Internet Relay Chat (IRC) chat rooms frequented by members of Anonymous using 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 victims of DDoS 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. In 2015, China launched a DDoS attack using a true MITM system (dubbed "Great Cannon"), collocated with the Great Firewall, that was able to inject JavaScript code into web visits to a Chinese search engine that commandeered those user agents to send DDoS traffic to various sites [Marczak-2015].

実証例:2012年、イギリスの信号情報機関である政府通信本部(GCHQ)は、Syn Flood DDoS手法を使用して、匿名のメンバーが頻繁に利用するInternet Relay Chat(IRC)チャットルームを一時的にシャットダウンしました。Syn Floodは、TCPが使用するハンドシェイクを悪用して、被害者サーバーに過剰なリクエストを送り、正当なトラフィックが遅くなるか不可能になるようにします。政治的に敏感なイベントの周りで、異議を唱えるウェブサイトは、しばしばDDoSの被害者となります。ロシア、ジンバブエ、マレーシアの支配政党は、選挙中に反対派の支持とアクセスを妨害するためにDDoSを使用したと非難されています。2015年、中国は、Great Firewallと共に設置された真のMITMシステム("Great Cannon"と呼ばれる)を使用して、中国の検索エンジンへのウェブ訪問にJavaScriptコードを挿入し、これらのユーザーエージェントを使用してDDoSトラフィックをさまざまなサイトに送信しました。

5.4.2. Censorship in Depth
5.4.2. 深層の検閲

Often, censors implement multiple techniques in tandem, creating "censorship in depth". Censorship in depth can take many forms; some censors block the same content through multiple techniques (such as blocking a domain by DNS, IP blocking, and HTTP simultaneously), some deploy parallel systems to improve censorship reliability (such as deploying multiple different censorship systems to block the same domain), and others can use complimentary systems to limit evasion (such as by blocking unwanted protocols entirely, forcing users to use other filtered protocols).

しばしば、検閲者は複数の技術を組み合わせて「深層検閲」を実施します。深層検閲にはさまざまな形態があります。一部の検閲者は、複数の技術を使って同じコンテンツをブロックします(たとえば、DNSによるドメインのブロック、IPブロック、HTTPの同時ブロックなど)、一部は信頼性を向上させるために並列システムを展開します(同じドメインをブロックするために複数の異なる検閲システムを展開するなど)、他の検閲者は回避を制限するために補完的なシステムを使用することがあります(たとえば、望ましくないプロトコルを完全にブロックして、ユーザーに他のフィルタリングされたプロトコルを使用させるなど)。

Trade-offs: Censorship in depth can be attractive for censors to deploy, as it offers additional guarantees about censorship: even if someone evades one type of censorship, they may still be blocked by another. The main drawback to this approach is the cost to initial deployment, as it requires the system to deploy multiple censorship systems in tandem.

トレードオフ:深い検閲は、検閲者が採用するのに魅力的であり、検閲に関する追加の保証を提供します。たとえ誰かが1つの検閲を回避しても、別の検閲によってブロックされる可能性があります。このアプローチの主な欠点は、初期展開にかかるコストです。複数の検閲システムを同時に展開する必要があります。

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 also has deployed a complimentary protocol filter to limit which protocols can be used on certain ports, forcing users to rely on protocols their censorship system can filter [Bock-2020].

実証例:深層の検閲は現在、多くの大規模な検閲国家で見られます。研究者は、中国が深層の検閲を大規模に展開しており、しばしば同じリソースを複数のプロトコルで検閲していることを観察しています[Chai-2019] [Bock-2020b]、または同じコンテンツとプロトコルを検閲するために追加の検閲システムを展開していることがあります[Bock-2021b]。イランも、特定のポートで使用できるプロトコルを制限するための補完的なプロトコルフィルターを展開しており、ユーザーには、彼らの検閲システムがフィルタリングできるプロトコルに頼る必要があります[Bock-2020]。

6. Non-technical Interference
6. 非技術的な干渉
6.1. Manual Filtering
6.1. 手動フィルタリング

As the name implies, sometimes manual labor is the easiest way to figure out which content to block. Manual filtering differs from the common tactic of building up blocklists in that it doesn't necessarily target a specific IP or DNS but instead removes or flags content. Given the imprecise nature of automatic filtering, manually sorting through content and flagging dissenting websites, blogs, articles, and other media for filtration can be an effective technique on its own or combined with other automated techniques of detection that are then followed by an action that would require manual confirmation. This filtration can occur on the backbone or ISP level. China's army of monitors is a good example [BBC-2013b], but more commonly, manual filtering occurs on an institutional level. ICPs, such as Google or Weibo, require a business license to operate in China. One of the prerequisites for a business license is an agreement to sign a "voluntary pledge" known as the "Public Pledge on Self-discipline for the Chinese Internet Industry". The failure to "energetically uphold" the pledged values can lead to the ICPs being held liable for the offending content by the Chinese government [BBC-2013b].

その名前が示すように、時には手作業がブロックすべきコンテンツを特定する最も簡単な方法です。手動フィルタリングは、通常のブロックリストの構築とは異なり、特定のIPやDNSを対象とする必要はなく、代わりにコンテンツを削除したりフラグを立てたりします。自動フィルタリングの不正確な性質を考慮すると、コンテンツを手動で分類し、異議のあるウェブサイト、ブログ、記事、および他のメディアをフィルタリングすることは、単独でまたは他の自動検出技術と組み合わせて行動に続く手動の確認が必要な効果的な技術となり得ます。このフィルタリングは、バックボーンやISPのレベルで発生することがあります。中国の監視部隊はその良い例です[BBC-2013b]が、より一般的には、手動フィルタリングは機関レベルで行われます。GoogleやWeiboなどのICPは、中国で運営するために事業ライセンスが必要です。事業ライセンスの前提条件の1つは、「中国インターネット業界の自己規律に関する公約」として知られる「自主公約」に署名することです。公約の価値観を「積極的に支持しない」場合、中国政府によって違反コンテンツの責任を負う可能性があります[BBC-2013b]。

6.2. Self-Censorship
6.2. 自己検閲

Self-censorship is difficult to document as it manifests primarily through a lack of undesirable content. Tools that encourage self-censorship may lead a prospective speaker to believe that speaking increases the risk of unfavorable outcomes for the speaker (technical monitoring, identification requirements, etc.). Reporters Without Borders exemplify methods of imposing self-censorship in their annual World Press Freedom Index reports [RWB-2020].

セルフセンシャーシップは、望ましくないコンテンツの不足を通じて主に現れるため、文書化するのが難しいです。セルフセンシャーシップを促進するツールは、発言者が発言することがリスクを増やすと信じさせる可能性があります(技術的な監視、身元確認要件など)。報道団体無国境記者団は、彼らの年次世界報道自由指数レポート[RWB-2020]において、セルフセンシャーシップを課す方法を示しています。

6.3. Server Takedown
6.3. サーバーダウン

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

[マードック-2008] で言及されているように、サーバーは世界のどこかに物理的な場所を持っている必要があります。検閲を行っている国に望ましくないコンテンツがホストされている場合、サーバーは物理的に押収される可能性があります。また、クラウドインフラストラクチャ内で仮想化されたサーバーが固定された物理的な場所を持たない場合、ホスティングプロバイダーにアクセスを防止するよう要求されることがあります。

6.4. Notice and Takedown
6.4. 削除通知

In many countries, legal mechanisms exist where an individual or other content provider can issue a legal request to a content host that requires the host to take down content. Examples include the systems employed by companies like Google 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].

多くの国では、個人や他のコンテンツプロバイダーがコンテンツホストに対して法的要求を出すことができる法的メカニズムが存在します。例としては、Googleなどの企業が欧州連合の「忘れられる権利」ポリシーに準拠するために使用しているシステム、電子プラットフォームプロバイダーの中間責任規則、または米国デジタルミレニアム著作権法(DMCA)セクション512の著作権指向の通知および削除制度があります。

6.5. Domain Name Seizures
6.5. ドメイン名の差し押さえ

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 the domain name 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
7. 未来の仕事

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

この文書は、検閲技術を詳細に説明するための包括的なリソースを確立するだけでなく、将来の取り組むべき重要な分野を示しています。

Taken as a whole, the apparent costs of implementation of censorship techniques indicate a need for 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 required of the censor to perform the specific censorship technique. Future work might classify techniques by essentially how hard a censor must work, including what infrastructure is required, in order 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 that thorough research on circumvention and encryption is left for another document. Moreover, the censorship circumvention community has developed an area of research on "pluggable transports," which collect, document, and make agile methods for obfuscating the on-path traffic of censorship circumvention tools such that it appears indistinguishable from other kinds of traffic [Tor-2019]. Those methods would benefit from future work in the Internet standards community, too.

回避に関して、この文書で説明されている一部の形態の検閲に対抗するために、暗号化を活用するプロトコルの増加が効果的な対策となりますが、回避と暗号化に関する徹底的な研究は別の文書に委ねられています。さらに、検閲回避コミュニティは、「プラグ可能トランスポート」という研究領域を開発しており、これは検閲回避ツールの通信を他の種類のトラフィックと区別できないようにするための柔軟な方法を収集し、文書化し、提供しています[Tor-2019]。これらの方法は、インターネット標準コミュニティにおいても今後の研究から恩恵を受けるでしょう。

Lastly, the empirical examples demonstrate that censorship techniques can evolve quickly, and experience shows that 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
8. IANAの考慮事項

This document has no IANA actions.

この文書にはIANAのアクションはありません。

9. Security Considerations
9. セキュリティに関する考慮事項

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.

この文書はネットワーク検閲技術に関する既存文献の調査です。したがって、調査された各論文で既に議論されている内容を超える新しいセキュリティ上の考慮事項を紹介していません。

10. Informative References
10. 参考引用
   [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>.
        
   [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>.
        
   [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://0b4af6cdc2f0c599
              8459-
              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://w
              eb.archive.org/web/20130825010947/http://www.theinquirer.n
              et/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>.
        
   [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
謝辞

This document benefited from discussions with and input from David Belson, Stéphane Bortzmeyer, Vinicius Fortuna, Gurshabad Grover, Andrew McConachie, Martin Nilsson, Michael Richardson, Patrick Vacek, and Chris Wood.

この文書は、David Belson、Stéphane Bortzmeyer、Vinicius Fortuna、Gurshabad Grover、Andrew McConachie、Martin Nilsson、Michael Richardson、Patrick Vacek、Chris Woodとの議論や意見を反映しています。

Coauthor Hall performed work on this document before employment at the Internet Society, and his affiliation listed in this document is for identification purposes only.

この文書に関する作業は、Internet Societyでの雇用前に共著者のHall氏が行いました。そして、この文書に記載されている所属は識別目的のためだけです。

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