diff --git a/thesis.tex b/thesis.tex index dda49e2..df8ef55 100644 --- a/thesis.tex +++ b/thesis.tex @@ -8,8 +8,8 @@ \usepackage[utf8]{inputenc} \usepackage{CJKutf8} +\usepackage[inline]{enumitem} \usepackage{graphicx} -\usepackage{makeidx} \usepackage{microtype} \usepackage{relsize} \usepackage[table,x11names]{xcolor} @@ -21,6 +21,9 @@ % edges of the paper. Page numbers must be ¾ of an inch from the edge." \usepackage[margin=1in]{geometry} +\usepackage{makeidx} +\makeindex + % biblatex manual: % "When using the hyperref package, it is preferable to load it after biblatex." \usepackage[backend=biber,bibencoding=utf8,sortcites=true,indexing=true,maxbibnames=99,backref=true]{biblatex} @@ -34,18 +37,14 @@ % https://tex.stackexchange.com/a/305486 \renewbibmacro*{citeindex}{\ifciteindex{\indexnames{author}}{}} \renewbibmacro*{bibindex}{\ifbibindex{\indexnames{author}}{}} + \usepackage[hidelinks]{hyperref} \urlstyle{same} \def\chapterautorefname{Chapter} \def\sectionautorefname{Section} +\def\subsectionautorefname{subsection} \def\figurenutorefname{Figure} -% Use one sequence to number both figures and tables. -% https://stackoverflow.com/a/43266057 -\makeatletter -\let\c@table\c@figure -\let\ftype@table\ftype@figure -\makeatother % Disable metadata for reproducible PDF. % https://tex.stackexchange.com/a/313605 @@ -56,16 +55,26 @@ \hypersetup{pdfcreator={},pdfproducer={}} \fi +% Table of contents only down to \section, not \subsection. +\setcounter{tocdepth}{1} + +% Use one sequence to number both figures and tables. +% https://stackoverflow.com/a/43266057 +\makeatletter +\let\c@table\c@figure +\let\ftype@table\ftype@figure +\makeatother -\makeindex -\hyphenation{Web-RTC} \hyphenation{GAE-uploader} \hyphenation{Go-Agent} +\hyphenation{Web-RTC} \usepackage{yfonts} \newcommand{\dragons}{\bigskip\noindent\textfrak{\Large here be dragons:}\bigskip\noindent} \newcommand{\placeholder}[1]{\colorbox{lightgray}{\parbox[c][#1][c]{\textwidth}{\centering placeholder for figure}}} +% A reference to one of the circled markers in fig:proxy-probe-timelines-china1. +\newcommand{\cnref}[1]{\textcircled{\smaller\fontfamily{phv}\selectfont #1}} \begin{document} @@ -80,6 +89,9 @@ % \include{frontmatter} {\Large Draft of \today} +\makeatletter +\renewcommand{\@oddfoot}{Draft of \today\hfill} +\makeatother \makeatletter \@starttoc{toc} @@ -588,7 +600,7 @@ reducing false positives without reducing false negatives.) For example, it has been repeatedly documented---by Clayton et~al.~\cite{Clayton2006a}, Winter and Lindskog~\cite{Winter2012a}, -and Fifield and Tsai~\cite{Fifield2016a-local}, +and Fifield, Tsai, and Zhong~\autoref{chap:proxy-probe}, for example---that the Great Firewall prefers to block individual ports (or a small range of ports), rather than blocking an entire IP address, @@ -1381,11 +1393,6 @@ just as censors do. \chapter{Understanding censors} \label{chap:censor-modeling} -\dragons - -A detached view is helpful when taking a longer view. -(As long as it is not \emph{too} detached.) - The main tool we have to build relevant threat models is the natural study of censors. The study of censors is complicated by difficulty of access: @@ -1399,215 +1406,578 @@ destinations that are blocked. Somewhat harder is the investigation into \emph{where} and \emph{how}, the specific technical mechanisms used to effect censorship and where they are deployed in the network. -What we are really interested in, -and what is most difficult to infer, -is the \emph{why}, -or the motivations and goals that underlie -a censorship apparatus. -We posit that censors, far from being unitary entities -of focused purpose, -are rather complex organizations of people and machines, -with conflicting purposes and economic rationales, -subject to resource limitations. +Most difficult to infer is the \emph{why}, +the motivations and goals that underlie +an apparatus of censorship. The \emph{why} gets to the heart of why circumvention is even possible: -a censoring firewall's duty is not merely to block, -but to \emph{discriminate} between what is blocked and what is allowed, -in support of some other goal. -Circumvention systems confuse this discrimination -in order to sneak traffic through the firewall. - -Past measurement studies -have mostly been short-lived, one-off affairs, -focusing deeply on one region of the world for at most a few months. -Thus published knowledge about censors' capabilities -consists mostly of a series of ``spot checks'' -with blank areas between them. -There have been a few designs proposed to -do ongoing measurements of censorship, -such as ConceptDoppler~\cite{Crandall2007a} in 2007 and -CensMon~\cite{Sfakianakis2011a} in 2011, -but these have not lasted long in practice, -and for the most part there is an unfortunate lack of longitudinal -and cross-country measurements. -Just as in circumvention, in censorship measurement -a host of difficulties arise when running a scalable system -for a long time, that do not arise when doing a one-time operation. -The situation is thankfully becoming better, -with the increasing data collection capabilities -of measurement systems like OONI~\cite{Filasto2012a}. +a censoring firewall's true purpose is not only blocking; +the blocking is done in pursuit of some other goal. From the survey of measurement studies we may draw some general conclusions. Censors change over time, -sometimes for unknown reasons, -and not always in the direction of greater restrictions. -Censorship conditions differ greatly +and not always in the direction of more restrictions. +Censorship differs greatly across countries, not only in subject but in mechanism and motivation. -The ``Great Firewall'' of China has long been -the world's most sophisticated censor, -but it is in many ways an outlier, -and not representative of censors elsewhere. -Most censors are capable of manipulating DNS responses, -IP address blocking, -and keyword filtering at some level. - -A reasonable set of capabilities, therefore, -that a contemporary censor may be assumed to have is: +However it is reasonable to assume a basic +set of capabilities that many censors have in common: \begin{itemize} -\item blocking of specific IP addresses and ports, -\item control of default DNS servers, -\item injection of false DNS responses, -\item injection of TCP RSTs, -\item throttling of connection, -\item keyword filtering -\item protocol identification, and -\item temporary total shutdown of Internet connections +\item blocking of specific IP addresses and ports +\item control of default DNS servers +\item injection of false DNS responses +\item injection of TCP RSTs +\item pattern matching / keyword filtering +\item application protocol parsing (``deep packet inspection'') +\item participation in a circumvention system as a client +\item scanning to discover proxies +\item throttling connections +\item temporary total shutdowns \end{itemize} -Not all censors will be able to do all of these. +Not all censors will be able to---or be motivated to---do all of these. As the amount of traffic to be handled increases, in-path attacks such as throttling become relatively more expensive. -Whether a particular censoring act even makes sense -will depend on a local cost--benefit analysis. +Whether a particular act of censorship even makes sense +will depend on a local cost--benefit analysis, +a weighing of the expected gains against the potential collateral damage. Some censors may be able to tolerate a brief total shutdown, while for others the importance of the Internet is too great -for such a crude measure. - -Past measurement studies have done a good job at -determining the technical aspects of censorship, -for example where in the network censorship routers are located. -There is not so much known about the inner workings of censors. -The anonymous paper on China's DNS censorship~\cite{Anonymous2014a} -probably comes closest to the kind of insight I am talking about, -with its clever use of side channels to infer -operational characteristics of censor boxes. -For example, their research found that each DNS injection node -runs a few hundred independent processes. -This is indirect information, to be sure, -but it hints at the level of resources the censor -is able to bring to bear. -I am interested in even deeper information, -for example how censors make the decision on what to block, -and what bureaucratic and other considerations -might cause them to work less than optimally. - -informing our threat models - -censors' capabilities---presumed and actual -e.g. ip blocking (reaction time?) -active probing - -Internet curfews (Gabon), limited time of shutdowns shows sensitivity to collateral damage. - -commercial firewalls (Citizen Lab) and bespoke systems - - -Ongoing, longitudinal measurement of censorship -remains a challenge. -Studies tend to be limited to one geographical region -and one period of time. -Dedicated measurement platforms such as -OONI~\cite{Filasto2012a} and ICLab~\cite{iclab} -are starting to make a dent in this problem, -by providing regular measurements from many locations worldwide. -Even with these, there are challenges around -getting probes into challenging locations -and keeping them running. - -Apart from a few reports of, for example, -per annum spending on filtering hardware, -not much is known about how much censorship costs to implement. -In general, contemporary threat models tend to ignore -resource limitations on the part of the censor. +for such a blunt instrument. + +The Great Firewall of China, +because of its unparalleled technical sophistication, +is tempting to use as a model adversary. +There has indeed been more research focused on China +than any other country. +But the GFW is in many ways an outlier, +and not representative of other censors. +A~worldwide view is needed. + +% Past measurement studies have done well at +% determining the technical aspects of censorship, +% for example where in the network censorship routers are located. +% There is not so much known about the inner workings of censors. +% The anonymous paper on China's DNS censorship~\cite{Anonymous2014a} +% probably comes closest to the kind of insight I am talking about, +% with its clever use of side channels to infer +% operational characteristics of censor boxes. +% For example, their research found that each DNS injection node +% runs a few hundred independent processes. +% This is indirect information, to be sure, +% but it hints at the level of resources the censor +% is able to bring to bear. +% I am interested in even deeper information, +% for example how censors make the decision on what to block, +% and what bureaucratic and other considerations +% might cause them to work less than optimally. + +% Internet curfews (Gabon), limited time of shutdowns shows sensitivity to collateral damage. + + +% Apart from a few reports of, for example, +% per annum spending on filtering hardware, +% not much is known about how much censorship costs to implement. +% In general, contemporary threat models tend to ignore +% resource limitations on the part of the censor. + + +\section{Censorship measurement studies} +\label{sec:measurement-surveys} + +A~large part of censorship research is composed of +studies of censor behavior in the wild. +In this section I~summarize past studies, which, taken together, +present a picture of censor behavior in general. +They are based on those in an evaluation study done by +me and others in 2016~\cite[\S IV.A]{Tschantz2016a-local}. +The studies are diverse and hard to categorize. +Here, I have grouped them according whether they +were one-time measurements or long-term projects, +and whether they looked at more than one censor (or country). -Tying questions of ethics\index{ethics} to questions about censor behavior, motivation: -\cite{Wright2011a} (also mentions ``organisational requirements, administrative burden'') -\cite{Jones2015a} -\cite{Crandall2015a} -Censors may come to conclusions different than what we expect -(have a clue or not). +Thus published knowledge about censors' capabilities +consists mostly of a series of ``spot checks'' +with blank areas between them. +There have been a few designs proposed to +do ongoing measurements of censorship, +such as ConceptDoppler~\cite{Crandall2007a} in 2007 and +CensMon~\cite{Sfakianakis2011a} in 2011, +but these have not lasted long in practice, +and for the most part there is an unfortunate lack of longitudinal +and cross-country measurements. +\todo[inline]{ +Zittrain and Edelman ``Internet filtering in China''~\cite{Zittrain2003a}. +\textsl{Access Denied}~\cite{OpenNet2008AccessDenied}. +Wright ``Regional Variation in Chinese Internet Filtering''~\cite{Wright2012a}. +Mathrani and Alipour ``Website Blocking Across Ten Countries: A Snapshot''~\cite{Mathrani2010a}. +Aase et~al.\ ``Whiskey, Weed, and Wukan on the World Wide Web: On Measuring Censors' Resources and Motivations''~\cite{Aase2012a}. +Dalek et~al.\ ``O Pakistan, We Stand on Guard for Thee''~\cite{CitizenLab2013opakistan}. +Marquis-Boire et~al.\ ``Planet Blue Coat''\cite{Marquis2013planet}. +Anderson ``Splinternet Behind the Great Firewall of China''~\cite{Anderson2012splinternet}. +Dalek et~al.\ ``A Method for Identifying and Confirming the Use of URL Filtering Products for Censorship''~\cite{Dalek2013a}. +Gill et~al.\ ``Characterizing Web Censorship Worldwide: Another Look at the OpenNet Initiative Data''~\cite{Gill2015a}. +Aceto and Pescapè ``Analyzing Internet Censorship in Pakistan''~\cite{Aceto2016a}. +Gwagwa ``A study of {Internet}-based information controls in {Rwanda}''~\cite{Gwagwa_a_study_of_internet-based_information_controls_in_rwanda}. +} -Evaluating the quality of circumvention systems is tricky, -whether they are only proposed or actually deployed. -The problem of evaluation is directly tied to threat modeling. -Circumvention is judged according to how well it works -under a given model; -the evaluation is therefore meaningful only as far as -the threat model reflects reality. -Without grounding in reality, researchers -risk running an imaginary arms race -that evolves independently of the real one. -This kind of work is rather different than -the direct evaluations of circumvention tools -that have happened before, for example those done by -the Berkman Center~\cite{Berkman2011} -and Freedom House~\cite{FreedomHouse2011} in 2011. -Rather than testing tools against censors, we evaluated -how closely calibrated designers' own models were to -models derived from actual observations of censors. +\subsection*{One-shot studies} -This research was partly born out of -frustration with some typical assumptions made -in academic research on circumvention, -which we felt placed undue emphasis -on steganography and obfuscation of traffic streams, -while not paying enough attention to -the perhaps more important problems of bridge distribution and rendezvous. -Indeed, in our survey of over 50 circumvention tools, -we found that academic designs tended to be concerned -with detection in the steady state after a connection -is established, -while actually deployed systems cared more about -how the connection is established initially. -We wanted to help bridge the gap by laying out a research agenda -to align the incentives of researchers with those of circumventors. -This work was built on extensive surveys -of circumvention tools, measurement studies, -and known censorship events against Tor. +One of the earliest technical studies of censorship occurred +in a place you might not expect, in the German state of +North Rhein-Westphalia. +In 2003, Dornseif~\cite{Dornseif2003a} tested ISPs' implementation +of a controversial legal order to block web sites. +While there were many possible ways to implement the block, +none were trivial to implement, nor free of overblocking side effects. +The most popular implementation used DNS tampering, which is +returning (or injecting) false responses to DNS requests +for the domain names of the blocked sites. +An in-depth survey of DNS tampering +found a variety of implementations, some blocking more +and some blocking less than required by the order. -This work on evaluation appeared in the 2016 research paper -``Towards Grounding Censorship Circumvention in Empiricism''~\cite{Tschantz2016a-local}, -which I coauthored with -Michael Carl Tschantz, Sadia Afroz, and Vern Paxson. +Clayton~\cite{Clayton2006b} in 2006 studied a ``hybrid'' blocking system, +CleanFeed by the British ISP BT, +that aimed for a better balance of costs and benefits: +a ``fast path'' IP address and port matcher +acted as a prefilter for the ``slow path,'' a full HTTP proxy. +The system, in use since 2004, +was designed to block access to any of a secret list of +pedophile web sites compiled by a third party. +The author identifies ways to circumvent or attack such a system: +use a proxy, use source routing to evade the blocking router, +obfuscate requested URLs, use an alternate IP address or port, +return false DNS results to put third parties on the ``bad'' list. +They demonstrate that the two-level nature of the blocking system +unintentionally makes it an oracle +that can reveal the IP addresses of sites in the secret blocking list. -Do they check the right things? +In 2006, Clayton, Murdoch, and Watson~\cite{Clayton2006a} +further studied the technical aspects of the Great Firewall of China. +They relied on an observation that the firewall was symmetric, +treating incoming and outgoing traffic equally. +By sending web requests from outside the firewall to a web server inside, +they could provoke the same blocking behavior +that someone on the inside would see. +They sent HTTP requests containing forbidden keywords (e.g., ``falun'') +caused the firewall to inject RST packets +towards both the client and server. +Simply ignoring RST packets (on both ends) +rendered the blocking mostly ineffective. +The injected packets had inconsistent TTLs and other anomalies +that enabled their identification. +Rudimentary countermeasures such as splitting keywords +across packets were also effective in avoiding blocking. +The authors of this paper bring up an important point +that would become a major theme of future censorship modeling: +censors are forced to trade blocking effectiveness +against performance. +In order to cope with high load at a reasonable costs, +censors may choose the architecture of a network monitor +or intrusion detection system, +one that can passively monitor and inject packets, +but cannot delay or drop them. -what's used and what's not used +A nearly contemporary study by Wolfgarten~\cite{Wolfgarten2006a} +reproduced many of the results of Clayton, Murdoch, and Watson. +Using a rented server in China, the author found cases of +DNS tampering, search engine filtering, and RST injection +caused by keyword sniffing. +Not much later, in 2007, Lowe, Winters, and Marcus~\cite{Lowe2007a} +did detailed experiments on DNS tampering in China. +They tested about 1,600 recursive DNS servers in China +against a list of about 950 likely-censored domains. +For about 400 domains, responses came back with bogus IP addresses, +chosen from a set of about 20 distinct IP addresses. +Eight of the bogus addresses were used more than the others: +a whois lookup placed them in Australia, Canada, China, Hong Kong, and the U.S. +By manipulating TTLs, the authors found that the false responses +were injected by an intermediate router: +the authentic response would be received as well, only later. +A more comprehensive survey~\cite{Anonymous2014a} +of DNS tampering and injection occurred in 2014, +giving remarkable insight into the internal structure +of the censorship machines. +DNS injection happens only at border routers. +IP ID and TTL analysis show that each node +is a cluster of several hundred processes +that collectively inject censored responses. +They found 174 bogus IP addresses, more than previously documented. +They extracted a blacklist of about 15,000 keywords. +The Great Firewall, because of its unusual sophistication, +has been an enduring object of study. +Part of what makes it interesting is its many blocking modalities, +both active and passive, proactive and reactive. +The ConceptDoppler project of Crandall et~al.~\cite{Crandall2007a} +measured keyword filtering by the Great Firewall +and showed how to discover new keywords automatically +by latent semantic analysis, using +the Chinese-language Wikipedia as a corpus. +They found limited statefulness in the firewall: +sending a naked HTTP request +without a preceding SYN resulted in no blocking. +In 2008 and 2009, Park and Crandall~\cite{Park2010a} +further tested keyword filtering of HTTP responses. +Injecting RST packets into responses is more difficult +than doing the same to requests, +because of the greater uncertainty in predicting +TCP sequence numbers +once a session is well underway. +In fact, RST injection into responses was hit or miss, +succeeding only 51\% of the time, +with some, apparently diurnal, variation. +They also found inconsistencies in the statefulness of the firewall. +Two of ten injection servers would react to a naked HTTP request; +that it, one sent outside of an established TCP connection. +The remaining eight of ten required an established TCP connection. +Xu et~al.~\cite{Xu2011a} continued the theme of keyword filtering in 2011, +with the goal of +discovering where filters are located at the IP and AS levels. +Most filtering is done at border networks +(autonomous systems with at least one non-Chinese peer). +In their measurements, the firewall was fully stateful: +blocking was never +triggered by an HTTP request outside an established TCP connection. +Much filtering occurs +at smaller regional providers, +rather than on the network backbone. -\chapter{Active probing} -\label{chap:active-probing} +Winter and Lindskog~\cite{Winter2012a}, +and later Ensafi et~al.~\cite{Ensafi2015b} +did a formal investigation into active probing, +a reported capability of the Great Firewall since around October 2011. +They focused on the firewall's probing of Tor +and its most common pluggable transports. -The Great Firewall of China rolled out an innovation -in the identification of proxy servers around 2010: -\emph{active probing} of suspected proxy addresses. -In active probing, the censor pretends to be a legitimate client, -making its own connections to suspected addresses -to see whether they speak a proxy protocol. -Any addresses that are found to be proxies -are added to a blacklist -so that the destination will be blocked in the future. -The input to active probing, a set of suspected addresses, -comes from passive observation of the content of client connections. -The censor sees a client connect to a destination. -Whenever the censor's content classifier is unsure -whether an ongoing connection is accessing a proxy, -it may pass the address of the destination to the active prober. -The active prober's connection then checks---with a low -chance of false positives---whether the destination actually is a proxy. -\autoref{fig:active-probing} illustrates the process. +Anderson~\cite{Anderson2013a-local} +documented network throttling in Iran, +which occurred over two major periods between 2011 and 2012. +Throttling degrades network access without totally blocking it, +and is harder to detect than blocking. +Academic institutions were affected by throttling, +but less so than other networks. +Aryan et~al.~\cite{Aryan2013a} +tested censorship in Iran +during the two months before the June 2013 presidential election. +They found multiple blocking methods: HTTP request keyword filtering, +DNS tampering, and throttling. +The most usual method was HTTP request filtering. +DNS tampering (directing to a blackhole IP address) +affected only three domains: +facebook.com, +youtube.com, and +plus.google.com. +SSH connections were throttled down to about 15\% +of the link capacity, +while randomized protocols were throttled almost down to zero +60 seconds into a connection's lifetime. +Throttling seemed to be achieved by dropping packets, thereby +forcing TCP's usual recovery. -\begin{figure} -\centering -\placeholder{2in} -\caption{ -The censor watches a connection between a client and a destination. -If content inspection does not definitively indicate a circumvention protocol, -but also does not definitively rule it out, -the censor passes the destination's address an active prober, -which itself attempts connections using various proxy protocols. +Khattak et~al.~\cite{Khattak2013a} +evaluated the Great Firewall from the perspective that it works like +an intrusion detection system or network monitor, +and applied existing technique for evading a monitor +the the problem of circumvention. +They looked particularly for ways to +evade detection that are expensive for the censor to remedy. +They found that the firewall is stateful, +but only in the client-to-server direction. +The firewall is vulnerable to a variety of TCP- and HTTP-based evasion +techniques, such as overlapping fragments, TTL-limited packets, +and URL encodings. + +Nabi~\cite{Nabi2013a} +investigated web censorship in Pakistan in 2013, using a publicly known +list of banned web sites. +They tested on 5 different networks in Pakistan. +Over half of the sites on the list were blocked by DNS tampering; +less than 2\% were additionally blocked by HTTP filtering +(an injected redirection before April 2013, +or a static block page after that). +They conducted a small survey to find the most +commonly used circumvention methods in Pakistan. +The most used method was public VPNs, at 45\% of respondents. + +Ensafi et~al.~\cite{Ensafi2015a} +employed an intriguing technique to measure censorship +from many locations in China---a ``hybrid idle scan.'' +The hybrid idle scan allows one to test TCP connectivity +between two Internet hosts, +without needing to control either one. +They selected roughly uniformly geographically distributed sites +in China from which to measure connectivity to +Tor relays, Tor directory authorities, +and the web servers of popular Chinese web sites. +There were frequent failures of the firewall resulting +in temporary connectivity, typically lasting in bursts of hours. + +In 2015, Marczak et~al.~\cite{Marczak2015a-local} +investigated an innovation in the capabilities +of the border routers of China, +an attack tool dubbed the ``Great Cannon.'' +The cannon was responsible for denial-of-service attacks +on Amazon CloudFront and GitHub. +The unwitting participants in the attack were +web browsers located outside of China, +who began their attack when the cannon injected +malicious JavaScript into certain HTTP responses +originating in China. +The new attack tool is noteworthy because it demonstrated +previously unseen in-path behavior, +such as packet dropping. + +A major aspect of censor modeling is that +many censors use commercial firewall hardware. +A case in point is the analysis by +Chaabane et~al.~\cite{Chaabane2014a} +of 600 GB of leaked logs from Blue Coat proxies +used for censorship in Syria. +The logs cover 9 days in July and August 2011, +and contain an entry for every HTTP request. +The authors of the study found evidence of IP address blocking, +domain name blocking, and HTTP request keyword blocking, +and also of users circumventing censorship +by downloading circumvention software or using the Google cache. +All subdomains of .il, the top-level domain for Israel, +were blocked, as were many IP address ranges in Israel. +Blocked URL keywords included +``proxy'', +``hotspotshield'', +``israel'', and +``ultrasurf'' +(resulting in collateral damage to the Google Toolbar +and Facebook Like button because they have ``proxy'' in HTTP requests). +Tor was only lightly censored---only one of several proxies +blocked it, and only sporadically. + + + +\subsection*{Multiple-location studies} + +For a decade, the OpenNet Initiative produced reports +on Internet filtering and surveillance in dozens of countries, +until it ceased operation in 2014. +For example, their 2005 report on Internet filtering in China~\cite{oni-china-2005} +studied the problem from many perspectives, +political, technical, and legal. +They translated and interpreted Chinese laws relating to the Internet, +which provide strong legal justifications for filtering. +The laws regulate both Internet users and service providers, +including cybercafes. +They prohibit the transfer of information that is indecent, +subversive, false, criminal, or that reveals state secrets. +The OpenNet Initiative tested the extent of filtering +of web sites, search engines, blogs, and email. +They found a number of blocked web sites, +some related to news and politics, and some on sensitive subjects +such as Tibet and Taiwan. +In some cases, entire sites (domains) were blocked; +in others, only specific pages within a larger site were blocked. +In a small number of cases, sites were accessible by +IP address but not by domain name. +There were cases of overblocking: apparently inadvertently blocked sites +that simply shared an IP address or URL keyword +with an intentionally blocked site. +On seeing a prohibited keyword, the firewall blocked connections +by injecting a TCP RST packet to tear down the connection, +then injecting a zero-sized TCP window, +which would prevent any communication with the same server +for a short time. +Using technical tricks, the authors inferred +that Chinese search engines index blocked sites +(perhaps having a special exemption from the general firewall policy), +but do not return them in search results. +% https://opennet.net/bulletins/005/ +The firewall blocks access searches for certain keywords on Google +as well as the Google Cache---but the latter could be worked around +by tweaking the format of the URL. +% https://opennet.net/bulletins/006/ +Censorship of blogs comprised keyword blocking +by domestic blogging services, +and blocking of external domains such as blogspot.com. +% https://opennet.net/bulletins/008/ +Email filtering is done by the email providers themselves, +not by an independent network firewall. +Email providers seem to implement their filtering rules +independently and inconsistently: +messages were blocked by some providers and not others. +% More ONI? +% \cite{oni-china-2007} +% \cite{oni-china-2009} +% \cite{oni-china-2012} +% \cite{oni-iran-2005} +% \cite{oni-iran-2007} +% \cite{oni-iran-2009} + +Sfakianakis et~al.~\cite{Sfakianakis2011a} +built CensMon, a system for testing web censorship +using PlanetLab nodes as distributed measurement points. +They ran the system for for 14 days in 2011 across 33 countries, +testing about 5,000 unique URLs. +They found 193 blocked domain–country pairs, 176 of them in China. +CensMon reports the mechanism of blocking. +Across all nodes, it was +18.2\% DNS tampering, +33.3\% IP address blocking, and +48.5\% HTTP keyword filtering. +The system was not run on a continuing basis. +Verkamp and Gupta~\cite{Verkamp2012a} +did a separate study in 11 countries, +using a combination of PlanetLab nodes +and the computers of volunteers. +Censorship techniques vary across countries; +for example, some show overt block pages and others do not. +China was the only stateful censor of the 11. +% \cite{Mathrani2010a} + +Dainotti et~al.~\cite{Dainotti2011a} +reported on the total Internet shutdowns +that took place in Egypt and Libya +in the early months of 2011. +They used multiple measurements to document +the outages as they occurred: +BGP data, a large network telescope, and active traceroutes. +During outages, there was a drop in scanning traffic +(mainly from the Conficker botnet) to their telescope. +By comparing these different measurements, +they showed that the shutdown in Libya was accomplished +in more that one way, +both by altering network routes and by firewalls dropping packets. + + +\subsection*{Long-term measurement platforms} + +Just as in circumvention, in censorship measurement +a host of difficulties arise when running a scalable system +for a long time, that do not arise when doing a one-time operation. + +Dedicated measurement platforms such as +OONI~\cite{Filasto2012a} and ICLab~\cite{iclab} +provide regular measurements from many locations worldwide. +Even with these, there are challenges around +getting probes into difficult locations +and keeping them running. + +PlanetLab is a system that was not originally designed for censorship measurement, +that was later adapted for that purpose. +Another recent example is RIPE Atlas, +a globally distributed Internet +measurement network consisting of physical probes hosted by volunteers, +Atlas allows 4 types of measurements: ping, traceroute, DNS resolution, +and X.509 certificate fetching. +Anderson et~al.~\cite{Anderson2014a} +used Atlas to examine two case studies of censorship: +Turkey's ban on social media sites in March 2014 and +Russia's blocking of certain LiveJournal blogs in March 2014. +In Turkey, they +found at least six shifts in policy during two weeks of site blocking. +They observed an escalation in blocking in Turkey: +the authorities first poisoned DNS for twitter.com, +then blocked the IP addresses of the Google public DNS servers, +then finally blocked Twitter's IP addresses directly. +In Russia, they found ten unique bogus IP addresses used to poison DNS. + +\todo[inline]{ +Pearce, Ensafi, et~al.\ ``Augur: Internet-Wide Detection of Connectivity Disruptions''~\cite{Pearce2017a}. +Pearce et~al.\ ``Global Measurement of DNS Manipulation''~\cite{Pearce2017b}. +} + + +\section{The evaluation of circumvention systems} + +Evaluating the quality of circumvention systems is tricky, +whether they are only proposed or actually deployed. +The problem of evaluation is directly tied to threat modeling. +Circumvention is judged according to how well it works +under a given model; +the evaluation is therefore meaningful only as far as +the threat model reflects reality. +Without grounding in reality, researchers +risk running an imaginary arms race +that evolves independently of the real one. + +I~took part, +with Michael Carl Tschantz, Sadia Afroz, and Vern Paxson, +in a meta-study~\cite{Tschantz2016a-local}, +of how circumvention systems are evaluated by their authors +and designers, +and comparing those empirically determined censor models. +This kind of work is rather different than +the direct evaluations of circumvention tools +that have happened before, for example those done by +the Berkman Center~\cite{Berkman2011} +and Freedom House~\cite{FreedomHouse2011} in 2011. +Rather than testing tools against censors, we evaluated +how closely calibrated designers' own models were to +models derived from actual observations of censors. + +This research was partly born out of +frustration with some typical assumptions made +in academic research on circumvention, +which we felt placed undue emphasis +on steganography and obfuscation of traffic streams, +while not paying enough attention to +the perhaps more important problems of bridge distribution and rendezvous. +We wanted to help bridge the gap by laying out a research agenda +to align the incentives of researchers with those of circumventors. +This work was built on extensive surveys +of circumvention tools, measurement studies, +and known censorship events against Tor. +Our survey included over 50 circumvention tools. + +One outcome of the research is that +that academic designs tended to be concerned +with detection in the steady state after a connection +is established (related to detection by content), +while actually deployed systems cared more about +how the connection is established initially +(related to detection by address). +Real censors care greatly about the cost of running detection, +and prefer cheap, passive, stateless solutions whenever possible. +It is important to guard against these modes of detection +before becoming too concerned with those that require +fast computation, packet flow blocking, or lots of state. +Designers tend to misperceive the censor's +weighting of false positives and false negatives---assuming +a whitelist rather than a blacklist, say---and +indeed it remains an open problem how to estimate these. + + +\chapter{Active probing} +\label{chap:active-probing} + +The Great Firewall of China rolled out an innovation +in the identification of proxy servers around 2010: +\emph{active probing} of suspected proxy addresses. +In active probing, the censor pretends to be a legitimate client, +making its own connections to suspected addresses +to see whether they speak a proxy protocol. +Any addresses that are found to be proxies +are added to a blacklist +so that the destination will be blocked in the future. +The input to active probing, a set of suspected addresses, +comes from passive observation of the content of client connections. +The censor sees a client connect to a destination. +Whenever the censor's content classifier is unsure +whether an ongoing connection is accessing a proxy, +it may pass the address of the destination to the active prober. +The active prober's connection then checks---with a low +chance of false positives---whether the destination actually is a proxy. +\autoref{fig:active-probing} illustrates the process. + +\begin{figure} +\centering +\placeholder{2in} +\caption{ +The censor watches a connection between a client and a destination. +If content inspection does not definitively indicate a circumvention protocol, +but also does not definitively rule it out, +the censor passes the destination's address an active prober, +which itself attempts connections using various proxy protocols. If any of the proxy connections succeeds, the censor adds the destination to an address blacklist. @@ -1765,7 +2135,7 @@ becomes available~\cite{tor-blog-tor-browser-45-released}. \\ 2015 August & BreakWa11 discovers an active-probing weakness in -ShadowSocks~\cites{github-shadowsocks-rss-issue-38}[\S 2]{BlessingStudio-why-do-shadowsocks-deprecate-ota}. +Shadowsocks~\cites{github-shadowsocks-rss-issue-38}[\S 2]{BlessingStudio-why-do-shadowsocks-deprecate-ota}. \\ 2015 October & Ensafi et~al.~\cite{Ensafi2015b} publish results of @@ -2056,6 +2426,7 @@ We continued this process, adding new classifiers for likely probes, until reaching a fixed point. \section{Probing infrastructure} +\label{sec:active-probing-infrastructure} \begin{figure} \centering @@ -2189,41 +2560,915 @@ and the TLS fingerprint are inconsistent with Chromium. \chapter{Time delays in censors' reactions} \label{chap:proxy-probe} -\dragons - -I am interested in understanding -censors at a deeper level. -To that end, I am working on a project to measure -how long censors take to react to sudden changes in circumvention. -So far, our technique has been to monitor the reachability -of newly added Tor Browser bridges, -to see how long after they are introduced they get blocked. -Portions of this work have already appeared in the 2016 research paper -``Censors' Delay in Blocking Circumvention Proxies''~\cite{Fifield2016a-local}, -which I coauthored with Lynn Tsai. -We discovered some interesting, previously undocumented behaviors -of the Great Firewall of China. -While the firewall, through active probing, -is able to detect some bridges dynamically within seconds or minutes, -it lags in detecting Tor Browser's newly added bridges, -taking days or weeks to block them. -It seems that bridges are first blocked -only at certain times of day, -perhaps reflecting an automated batch operation. - -I am now continuing to work on this project along with Lynn Tsai and Qi Zhong. -We plan to run targeted experiments to find out more about -how censors extract bridge addresses from public information, -for example, by adding bridges with different attributes -and seeing whether they are blocked differently. -Our first experiment used measurement sites only in China and Iran, -but we hope to expand to many more countries -by collaborating with measurement platforms -such as OONI~\cite{Filasto2012a} and ICLab~\cite{iclab}. -We hope to solicit other kinds of censor delays -from other circumvention projects, -in order to build a more all-encompassing picture -of censors' priorities with respect to circumvention. +Tor bridges are secret relays that help clients get around censorship. +The effectiveness of bridges depends on their secrecy---a censor +that learns a bridge's address can simply block its IP address. +Since the beginning, the designers of Tor's bridge system +envisioned that users would learn of bridges through +covert or social channels~\cite[\S 7]{tor-techreport-2006-11-001}, +in order to prevent any one actor from learning about +and blocking a large number of bridges. + +But as it turns out, most users do not use bridges +in the way envisioned. +Rather, most users who use bridges use one of a +small number of \emph{default} bridges hardcoded +in a configuration file within Tor Browser. +(According to Matic et~al.~\cite[\S VII.C]{Matic2017a}, +over 90\% of bridge users use a default bridge.) +At a conceptual level, the notion of a ``default'' bridge +is a ridiculous contradiction. +Bridges are meant to be secret, +not plainly listed in the source code. +Any reasonable threat model would assume that default bridges +are immediately blocked. +And yet in practice we find that they are often not blocked, +even by censors that otherwise block Tor relays. +We face a paradox: +why is it that censors do not take blocking steps +that we find obvious? +There must be some quality of censors' +internal dynamics that we do not understand adequately. + +The purpose of the present chapter is to begin +to peel back the veneer of censorship, +to gain insight into why they behave as they do---particularly +when they behave contrary to expectations. +We posit that censors, far from being unitary entities +of focused purpose, +are rather complex organizations composed of human and machine components, +with perhaps conflicting goals; +this project is a small step towards +better understanding what lies under the face that censors present. +The main vehicle for the exploration of this subject +is the observation of default bridges (a specific +kind of proxy) to find out how quickly they are blocked +after they first become discoverable by a censor. +I~took part in this project +along with Lynn Tsai and Qi Zhong; +the results in this chapter are an extension +of work Lynn and I~published in 2016~\cite{Fifield2016a-local}. +Through active measurements of default bridges +from probe sites in China, Iran, and Kazakhstan, +we uncovered previously undocumented behaviors of censors +that hint at how they operate at a deeper level. + +It was with a similar spirit that +Aase, Crandall, Díaz, Knockel, Ocaña Molinero, Saia, Wallach, and Zhu~\cite{Aase2012a} +looked into case studies of censorship +with a focus on understanding censors' +motivation, resources, and sensitivity to time. +They had ``assumed that censors are fully motivated to block content +and the censored are fully motivated to disseminate it.'' +But some of their observations challenged that assumption, +with varied and seemingly undirected censorship +hinting at behind-the-scenes resource limitations. +They describe an apparent ``intern effect,'' +by which keyword lists seem to have been compiled by +a bored and unmotivated worker, +without much guidance. +Knockel et~al.~\cite{Knockel2017a} looked into +censorship of keywords in Chinese mobile games, +finding that censorship enforcement +in that context is similarly decentralized, +different from the centralized control we +commonly envision when thinking about censorship. + +Zhu et~al.~\cite{Zhu2013a} addressed the question +of the time delay of censorship on Chinese microblogging sites: +how long it takes posts with forbidden content to be deleted. +\todo{better summary} + +Nobori and Shinjo give a timeline~\cite[\S 6.3]{Nobori2014a} +of circumventor and censor actions and reactions +during the first month and a half of the deployment of VPN~Gate in China. +Within the first four days, the firewall had blocked +their main proxy distribution server, +and begun scraping the proxy list. +When they blocked the single scraping server, +the firewall began scraping from multiple other locations +within a day. +After VPN~Gate deployed the countermeasure of mixing +high-collateral-damage servers into their proxy list, +the firewall stopped blocking proxies for two days, +after which it resumed blocking proxies, +after checking them first to see that they really were +VPN~Gate proxies. + +Wright et~al.~\cite{Wright2011a} motivated a desire +for fine-grained censorship measurement by highlighting +limitations that would tend to prevent a censor from +begin equally effective everywhere in its controlled network. +Not only resource limitations, +but also administrative and logistical requirements, +make it difficult to manage a system as complex as a national +censorship apparatus. + +\todo[inline]{ +Questions of ethics are tied to models of censors; +e.g., will a censor arrest/harm someone who is caught circumventing? +What URLs are ``safe'' to probe in a measurement system? +Wright et~al.\ ``Fine-Grained Censorship Mapping: Information Sources, Legality and Ethics''~\cite{Wright2011a}. +Jones et~al.\ ``Ethical Concerns for Censorship Measurement''~\cite{Jones2015a}. +Crandall et~al.\ ``Forgive Us our SYNs: Technical and Ethical Considerations for Measuring Internet Filtering''~\cite{Crandall2015a}. +} + +There has been no prior long-term study dedicated to measuring +time delays in the blocking of default bridges. +There have, however, been a couple of point measurements that +put bounds on what blocking delays in the past must have been. +Tor Browser first shipped with obfs2 bridges on +February~11, 2012~\cite{tor-blog-obfsproxy-next-step-censorship-arms-race}; +Winter and Lindskog tested them 41~days later~\cite[\S 5.1]{Winter2012a} +and found all~13 of them blocked. +(The bridges then were blocked by RST injection, +different than the timeouts we have seen more recently.) +In 2015 I~used public reports of blocking and non-blocking +of the first batch of default obfs4 bridges +to infer a blocking delay of not less than~15 +and not more than 76~days~\cite{tor-dev-censorship-lag}. + + +\section{The experiment} + +Our experiment primarily involved frequent, +active measurements of the reachability of default bridges +from probe sites in China, Iran, and Kazakhstan +(countries well known to censor the network), +as well as a control site in the U.S. +We used a script that, +every 20~minutes, +attempted to make a TCP connection +to each default bridge. +The script recorded, for each attempt, +whether the connection was successful, +the time elapsed, and any error code. +The error code allows us to distinguish between +different kinds of failures such as +``timeout'' and ``connection refused.'' +The control site in the U.S.\ enables +to distinguish temporary bridge failures +from actual blocking. + +The script only tests whether it is possible to make a TCP connection, +which is necessary but not sufficient to actually make a Tor connection +through the bridge. +In Kazakhstan, we additionally deployed measurements +that attempted to establish a full Tor connection, +in order to better understand the different type of blocking +we discovered there. + +The experiment was opportunistic in nature: +we ran from China, Iran, and Kazakhstan not only because +they are likely suspects for Tor blocking, +but because we happened to have access to a site from which +we could run probes over some period of time. +Therefore the measurements cover different dates +in different countries. +We began at a time when Tor was building up +its stock of default bridges. +We began monitoring the new bridges as they were added, +coordinating with Tor Browser developers to get advance notice +of them when possible. +Additionally we had the developers run certain more controlled +experiments for us---such as adding a bridge to the source code +but commenting it out---that are further detailed below. + +We were only concerned with default bridges, not secret ones. +Our goal was not to estimate the difficulty of the bridge discovery problem, +but to better understand how censors deal with what seems to be a trivial task. +We focused on bridges using the obfs4 pluggable transport~\cite{obfs4}, +which not only is the most-used transport and the one +marked ``recommended'' in the interface, +but also has properties that help in our experiment. +The content obfuscation of obfs4 reduces the risk of its passive detection. +More importantly, it resists active probing attacks +as described in \autoref{chap:active-probing}. +We could not have done the experiment with obfs3 bridges, +because whether default bridges or not, +they would be probed and blocked shortly after their first use. + +Bridges are identified by a nickname and a port number. +The nickname is an arbitrary identifier, chosen by the bridge operator. +So, for example, ``ndnop3:24215'' is one bridge, +and ``ndnop3:10527'' is another bridge on the same IP address. +We pulled the list of bridges from Tor Browser +and Orbot, which is the port of Tor for Android. +Tor Browser and Orbot mostly shared bridges in common, +though there were a few Orbot-only bridges. +A~list of bridges and other destinations we measured +appears in \autoref{tab:proxy-probe-destinations}. +Along with the new obfs4 bridges, we tested some +existing bridges. + +\begin{table} +\small +\centering +\begin{tabular}[t]{r@{\,:\,}l} +\multicolumn{2}{l}{\textbf{New Tor Browser default obfs4 bridges}} \\ +ndnop3 & 24215, 10527 \\ +ndnop5 & 13764 \\ +riemann & 443 \\ +noether & 443 \\ +Mosaddegh & 41835, 80, 443, 2934, 9332, 15937 \\ +MaBishomarim & 49868, 80, 443, 2413, 7920, 16488 \\ +GreenBelt & 60873, 80, 443, 5881, 7013, 12166 \\ +JonbesheSabz & 80, 1894, 4148, 4304 \\ +Azadi & 443, 4319, 6041, 16815 \\ +Lisbeth & 443 \\ +NX01 & 443 \\ +LeifEricson & 50000, 50001, 50002 \\ +cymrubridge31 & 80 \\ +cymrubridge33 & 80 \\ +\end{tabular} +\quad +\begin{tabular}[t]{r@{\,:\,}ll} +\multicolumn{3}{l}{\textbf{Orbot-only default obfs4 bridges}} \\ +Mosaddegh & 1984 \\ +MaBishomarim & 1984 \\ +JonbesheSabz & 1984 \\ +Azadi & 1984 \\ +\noalign{\medskip} +\multicolumn{3}{l}{\textbf{Already existing default bridges}} \\ +LeifEricson & 41213 & (obfs4) \\ +fdctorbridge01 & 80 & (FTE) \\ +\noalign{\medskip} +\multicolumn{3}{l}{\textbf{Never-published bridges}} \\ +ndnop4 & 27668 & (obfs4) \\ +% \noalign{\smallskip} +% \multicolumn{2}{l}{\textbf{Non-obfs4 destinations}} \\ +% ndnop3 & 22 \\ +% ndnop4 & 22 \\ +% LeifEricson & 22 \\ +% riemann & 22 \\ +% noether & 22 \\ +% Mosaddegh & 22 \\ +% MaBishomarim & 22 \\ +% JonbesheSabz & 22 \\ +% Azadi & 22 \\ +% Lisbeth & 2200 (SSH) \\ +% NX01 & 22 \\ +\end{tabular} +\caption{ +The bridges whose reachability we tested. +Except for the already existing and never-published bridges, +they were all introduced during the course of our experiment. +Each bridge is identified by a nickname +(a label chosen by its operator) and a port. +Each nickname represents a distinct IP address. +Port numbers are in chronological order of release. +} +\label{tab:proxy-probe-destinations} +\end{table} + +There are four stages in the process of deploying a new +default bridge. +At the start, the bridge is secret, +perhaps only having been discussed on a private mailing list. +Each successive stage of deployment makes the bridge more public, +increasing the number of places where a censor +may look to discover it. +The whole process takes a few days to a few weeks, +mostly depending on the release schedule. +\begin{description} +\item[Ticket filed] +The process begins with the filing of a ticket in Tor's public issue tracker. +The ticket includes the bridge's IP address. +A~censor that pays attention to the issue tracker +could discover bridges as early as this stage. +\item[Ticket merged] +After review, the ticket is merged and the new bridge +is added to the source code of Tor Browser. +From there it will begin to be included in nightly builds. +A~censor that reads the bridge configuration file +from the source code repository, +or downloads nightly builds, +could discover bridges at this stage. +\item[Testing release] +Just prior to a public release, +Tor Browser developers send candidate builds +to a public mailing list to solicit +quality assurance testing. +A~censor that follows testing releases would +find ready-made executables with bridges embedded +at this stage. +Occasionally the developers skip the testing period, +such as in the case of an urgent security release. +\item[Public release] +After testing, the releases are made public +and announced on the Tor Blog. +A~censor could learn of bridges at this stage +by reading the blog and downloading executables. +This is also the stage at which the new bridges +begin to have an appreciable number of users. +There are two release tracks of Tor Browser: stable and alpha. +Alpha releases are distinguished by an `a' in their version number, +for example 6.5a4. +According to Tor Metrics~\cite{tor-metrics-webstats-tb}, +stable downloads outnumber +alpha downloads by a factor of about 30~to~1. +\end{description} +We advised operators to configure their bridges +so that they would not become public except +via the four stages described above. +Specifically, we made sure the bridges did not appear in +BridgeDB~\cite{BridgeDB}, the online database of secret bridges, +and that the bridges did not expose any transports other than obfs4. +We wanted to ensure that any blocking of bridges could only +be the result of their status as default bridges, +and not a side effect of some other detection system. + + +\section{Results from China} +\label{sec:proxy-probe-china} + +We had access to probe sites in China for just over a year, +from December 2015 to January 2017. +Due to the difficulty of getting access to hosts in China, +we used four different IP addresses +(all in the same autonomous system) +at different points in time. +The times during which we had control of each IP address +partially overlap, but there is a 21-day gap in measurements +during August 2016. + +Our observations in China turned up several +interesting behaviors of the censor. +Throughout this section, +refer to \autoref{fig:proxy-probe-timelines-china1}, +which shows the timeline of reachability of every bridge, +in context with dates related to tickets and releases. +Circled references in the text (\cnref{a}, \cnref{b}, etc.) +refer to marked points in the figure. +A~``batch'' of releases is a set that all +contain the same default bridges. + +\begin{figure} +\centering +\includegraphics{figures/proxy-probe-timelines-china1} +\caption{ +Tor Browser default bridge reachability +from a single autonomous system in China. +Releases are grouped into batches according to +the new bridges they contain. +The thickness of lines indicates whether the measurements +agreed with those of the control site; +their color shows whether the attempted TCP connection was successful. +Blocking events appear as a transition from +narrow blue (success, agrees with control) to +wide gray (timeout, disagrees with control). +The notation ``//~NX01:443'' means that the bridge was commented out for that release. +Points marked with circled letters \cnref{a}, \cnref{b}, etc., +are explained in the text. +} +\label{fig:proxy-probe-timelines-china1} +\end{figure} + +The most significant single event---covered in detail +in \autoref{sec:china-preemptive}---was a change +in the censor's detection and blocking strategy in October 2016. +Before that date, blocking was port-specific +and happened only after the ``public release'' stage. +After, bridges began to be blocked on all ports simultaneously, +and were blocked soon after the ``ticket merged'' stage. +We believe that this change reflects a shift in how the censor discovers bridges, +from running the finished software to see what addresses it connects to, +to extracting addresses from source code. +More details and evidence appear in the following subsections. + + +\subsection{Per-port blocking} +\label{sec:china-perport} + +In the first few release batches, the censor blocked individual ports, +not an entire IP address. +This characteristic of the Great Firewall has been documented +as far back as 2006 by Clayton et~al.~\cite{Clayton2006a}, +and in 2012 by Winter and Lindskog~\cite{Winter2012a}. +For example, see point~\cnref{a} in \autoref{fig:proxy-probe-timelines-china1}: +after ndnop3:24215 was blocked, +we opened ndnop3:10527 on the same IP address. +The alternate port remained reachable +until it, too, +was blocked in the next release batch. +We used this technique of rotating +ports in several release batches. + +Per-port blocking is also evident in the continued reachability +of non-bridge ports. +For example, many of the bridges had an SSH port open, +in addition to their obfs4 ports. +After riemann:443 (obfs4) was blocked (point~\cnref{c} in \autoref{fig:proxy-probe-timelines-china1}), +riemann:22 (SSH) remained reachable for a further nine months, +until it was finally blocked at point~\cnref{m}. +Per-port blocking would give way to whole-IP blocking +in October 2016. + + +\subsection{Blocking only after public release} +\label{sec:china-after-release} + +In the first six batches, +blocking occurred only after public release---despite +the fact that the censor could potentially have learned about +and blocked the bridges in an earlier stage. +In the 5.5.5/6.0a5/6.0 batch, +the censor even seems to have missed the 5.5.5 and 6.0a5 releases +(point~\cnref{e} in \autoref{fig:proxy-probe-timelines-china1}), +only blocking after the 6.0 release, 36 days later. +This observation hints that, before October 2016 anyway, +the censor was somehow extracting bridge addresses +from the release packages themselves. +In Sections~\ref{sec:china-simultaneous} and~\ref{sec:china-different-times} +we present more evidence that supports +the hypothesis that the censor extracted bridge addresses +from public releases, +not reacting at any earlier phase. + +An evident change in blocking technique +occurred around October 2016 with the 6.0.6/6.5a4 batch, +when for the first time bridge were blocked +before a public or testing release was available. +The changed technique is the subject of \autoref{sec:china-preemptive}. + + +\subsection{Simultaneous blocking of all bridges in a batch} +\label{sec:china-simultaneous} + +The first five blocking incidents +were single events: +when a batch contained more than one bridge, +all were blocked at the same time (within 20 minutes). +These incidents appear as crisp vertical columns of blocking icons +in \autoref{fig:proxy-probe-timelines-china1}, +for example at point~\cnref{c}. +This fact supports the idea that the censor +discovered bridges by examining release packages directly, +and did not, for example, +detect bridges one by one by examining network traffic. + +The 6.0.5/6.5a3 batch is an exception to the pattern +of simultaneous blocking. +In that batch, one bridge (LeifEricson:50000) was already blocked, +three were blocked simultaneously as in the previous batches, +but two others (GreenBelt:5881 and Azadi:4319) were temporarily unscathed. +At the time, GreenBelt:5881 was experiencing a temporary outage---which +could explain why it was not blocked---but +Azadi:4319 was operational. +This specific case is discussed more in +\autoref{sec:china-different-times}. + + +\subsection{Variable delays before blocking} +\label{sec:china-varied} + +During the time when the censor was blocking +bridges simultaneously after a public release, +we found no pattern in the length of time +between the release and the blocking event. +The blocking events did not seem to occur after a fixed length +of time, nor did they occur on the same day of the week +or at the same time of day. +The delays were +7, 2, 18, 10, 35, and~6 days after a batch's first public release---up +to 57 days +after the filing of the first ticket. +Recall from \autoref{sec:active-probing-infrastructure} that +the firewall was even at that time +capable of detecting and blocking \emph{secret} bridges +within minutes. +Delays of days or weeks really stand out in contrast. + + +\subsection{Inconsistent blocking and failures of blocking} +\label{sec:china-failures} + +There is a conspicuous on--off pattern +in the reachability of certain bridges from China, +for example in ndnop3:24215 throughout February, March, and April 2016 +(point~\cnref{b} in \autoref{fig:proxy-probe-timelines-china1}). +Although the censor no doubt intended to block the bridge fully, +% 3,024 of 6,480 (47\%) +47\% +of connection attempts were successful during that time. +On closer inspection, we find that +the pattern is roughly periodic with a period of 24~hours. +The pattern may come and go, for example in riemann:443 +before and after March~27, 2016. +The predictable daily variation in reachability rates +makes us think that, at least at the times under question, +the Great Firewall's effectiveness was dependent on load---varying +load at different times of day leads to varying bridge reachability. + +Beyond the temporary reachability of individual bridges, +we also see what are apparent temporary failures of firewall, +making all bridges reachable for hours or days at a time. +Point~\cnref{d} in \autoref{fig:proxy-probe-timelines-china1} marks such a failure. +All the bridges under test, including those that had already been blocked, +became available between 10:00 and 18:00~UTC on March~27, 2016. +Further evidence that these results indicate a failure of the firewall +come from a press report~\cite{scmp-gfw} that Google services---normally +blocked in China---were also unexpectedly available on the same day, +from about 15:30 to 17:15~UTC. +% 2016-06-28 17:42:01,spline,109.105.109.147,13764,30.0200228691,False,None,timed out +% 2016-06-29 03:02:01,spline,109.105.109.147,13764,30.0292298794,False,None,timed out +A similar pattern appears across all bridges +for nine hours starting on +June~28, 2016 at 17:40~UTC. + +After the switch to whole-IP blocking, +there are more instances of spotty and inconsistent blocking, +though of a different nature. +Several cases are visible near point~\cnref{j} +in \autoref{fig:proxy-probe-timelines-china1}. +It is noteworthy that not all ports on a single host are affected equally. +For example, the blocking of GreenBelt is inconsistent on ports 5881 and 12166, +but it is solidly blocked on ports 80, 443, 7013, and 60873. +Similarly, Mosaddegh's ports 1984 and 15937 are intermittently reachable, +in the exact same pattern, +while ports 80, 443, 2934, and 9332 remain blocked. +These observations lead us to suspect a two-tiered structure of the firewall: +one tier for per-port blocking and a separate one for whole-IP blocking. +If there were a temporary failure of the whole-IP tier, +any port not specifically handled by the per-port tier would become reachable. + + +\subsection{Failure to block all new bridges in a batch} +\label{sec:china-different-times} + +The 6.0.5/6.5a2 release batch was noteworthy in several ways. +Its six new bridges were all fresh ports on already used IP addresses. +For the first time, not all bridges were blocked simultaneously. +Only three of the bridges---Mosaddegh:2934, +MaBishomarim:2413, and JonbesheSabz:1894---were blocked in a way +consistent with previous release batches. +Of the other three, +\begin{itemize} +\item LeifEricson:50000 +had been blocked since we began measuring it. +The LeifEricson IP address is one of the oldest in the browser. +We suspect the entire IP address had been blocked at some point. +We will have more to say about LeifEricson in \autoref{sec:china-allports}. +\item GreenBelt:5881 (point~\cnref{f}) +was offline at the time when other bridges in the batch were blocked. +We confirmed this fact by talking with the bridge operator +and through control measurements: +the narrow band in \autoref{fig:proxy-probe-timelines-china1} shows that +while connection attempts were timing out not only from China, but also from the U.S. +The bridge became reachable again from China as soon as it came back online. +\item Azadi:4319 (point~\cnref{g}), +in contrast, was fully operational at the time of the other bridges' blocking, +and the censor nevertheless failed to block it. +\end{itemize} + +We take from the failure to block GreenBelt:5881 and Azadi:5881 +that the censor, as late as September 2016, +was most likely \emph{not} discovering bridges +by inspecting the bridge configuration file in the source code, +because if it had been, +it would not have missed two of the bridges in the list. +Rather, we suspect that the censor used some kind of network analysis---perhaps +running a release of Tor Browser in a black-box fashion, +and making a record of all addresses it connected to. +This would explain why GreenBelt:5881 was not blocked +(it couldn't be connected to while the censor was harvesting bridge addresses) +and could also explain why Azadi:4319 was not blocked +(Tor does not try every bridge simultaneously, +so it simply may not have tried to connect to Azadi:4319 +in the time the censors allotted for the test). +It is consistent with the observation that bridges were not blocked before a release: +the censor's discovery process needed a runnable executable. + +Azadi:4319 remained unblocked even after an additional port +on the same host was blocked in the next release batch. +This tidbit will enable us, in the next section, +to fairly narrowly locate the onset of bridge discovery +based on parsing the bridge configuration file +in October 2016. + + +\subsection{A switch to blocking before release} +\label{sec:china-preemptive} + +The 6.0.6/6.5a4 release batch marked two major changes in the censor's behavior: +\begin{enumerate} +\item For the first time, newly added bridges were blocked \emph{before} a release. +(Not counting LeifEricson, an old bridge which we had never been able to reach from China.) +\item For the first time, new blocks affected more than one port. +(Again not counting LeifEricson.) +\end{enumerate} + +The 6.0.6/6.5a4 batch contained eight new bridges. +Six were new ports on previously used IP addresses +(including LeifEricson:50001, +which we expected to be already blocked, % our email thread with LeifEricson operator is on 04 Oct 2016 +but included for completeness). +The other two---Lisbeth:443 and NX01:443---were fresh IP addresses. +However one of the new bridges, NX01:443, had a twist: +we left it commented out in the bridge configuration file, thus: +\begin{quote} +\small +\begin{verbatim} +pref(..., "obfs4 192.95.36.142:443 ..."); +// Not used yet +// pref(..., "obfs4 85.17.30.79:443 ..."); +\end{verbatim} +\end{quote} + +Six of the bridges---all +but the exceptional LeifEricson:50000 and NX01:443---were +blocked, not quite simultaneously, but within 13 hours of each other +(see point~\cnref{h} in \autoref{fig:proxy-probe-timelines-china1}). +The blocks happened 14 days (or 22 days in the case of Lisbeth:443 and NX01:443) +after ticket merge, +and 27 days before the next public release. + +We hypothesize that this blocking event +indicates a change in the censor's technique, +and that in October 2016 the Great Firewall began +to discover bridge addresses either by +examining newly filed tickets, +or by inspecting the bridge configuration file in the source code. +A first piece of evidence for the hypothesis is, +of course, that the bridges were blocked at a time +when they were present in the bridge configuration file, +but had not yet appeared in a release. +The presence of the never-before-seen Lisbeth:443 +in the blocked set removes the possibility that the censor +spontaneously decided to block additional ports on IP addresses it already knew about, +as does the continued reachability of certain blocked bridges +on further additional ports. + +A second piece of evidence comes from a careful scrutiny of the +timelines of the Azadi:4319 and Azadi:6041 bridges. +As noted in \autoref{sec:china-different-times}, +Azadi:4316 had unexpectedly been left unblocked in the previous release batch, +and it remained so, even after Azadi:6041 was blocked in this batch. +\begin{center} +\begin{tabular}{r@{~}ll} + 7 & September & Azadi:4319 enters the source code \\ +16 & September & Azadi:4319 appears in public release 6.0.5 \\ + 6 & October & Azadi:4319 is deleted from the source code, and Azadi:6041 is added \\ +20 & October & Azadi:6041 (among others) is blocked \\ +15 & November & Azadi:6041 appears in public release 6.0.6 \\ +\end{tabular} +\end{center} +The same ticket that removed Azadi:4319 on October~6 also added Azadi:6041. +On October~20 when the bridges were blocked, +Azadi:4319 was gone from the bridge configuration file, +having been replaced by Azadi:6041. +It appears that the yet-unused Azadi:6041 was blocked +merely because it appeared in the bridge configuration file, +even though it would have been more beneficial to the censor +to instead block the existing Azadi:4319, which was still in active use. + +The Azadi timeline enables us to locate fairly narrowly the change in bridge discovery techniques. +It must have happened during the two weeks between October~6 and October~20, 2016. +It cannot have happened before October~6, because at that time Azadi:4319 was still listed, +which would have gotten it blocked. +And it cannot have happened after October~20, because that is when bridges listed in the file +were first blocked. + +A third piece of evidence supporting the hypothesis that the censor +began to discover bridges through the bridge configuration file +is its treatment of the commented-out bridge NX01:443. +The bridge was commented out in the 6.0.6/6.5a4 batch, +in which it remained unblocked, +and uncommented in the following 6.0.8/6.5a6 batch. +% 2016-11-30 01:11:58,ticket_filed,NX01:443 +% NX01:443,2016-12-04 09:48:26,6.0.8/6.5a6,prerelease +% 2016-12-13 12:20:02,6.0.8,6.0.8/6.5a6,public +The bridge was blocked four days after the ticket uncommenting it was merged, +which was still 11~days before the public release in which it was +to have become active +(see point~\cnref{i} in \autoref{fig:proxy-probe-timelines-china1}). + + +\subsection{The onset of whole-IP blocking} +\label{sec:china-allports} + +The blocking event on October~20 2016 was noteworthy not only because it occurred before a release, +but also because it affected more than one port on some bridges. +See point~\cnref{h} in \autoref{fig:proxy-probe-timelines-china1}. +When GreenBelt:7013 was blocked, +so were GreenBelt:5881 (which had escaped blocking in the previous batch) +and GreenBelt:12166 (which was awaiting deployment in the next batch). +Similarly, when MaBishomarim:7920 and JonbesheSabz:4148 were blocked, +so were the Orbot-reserved MaBishomarim:1984 and JonbesheSabz:1984 (point~\cnref{k}), +ending an eight-month unblocked streak. + +The blocking of Mosaddegh:9332 and Azadi:6041 also affected other ports, +though after a delay of some days. +We do not have an explanation for why some multiple-port blocks took effect faster than others. +The SSH port riemann:22 was blocked at about the same time (point~\cnref{m}), +10~months after the corresponding obfs4 port riemann:443 had been blocked; +there had been no changes to the riemann host in all that time. +We suspected that the Great Firewall might employ a threshold scheme: +once a certain number of individual ports on a particular IP address +have been blocked, go ahead and block the entire IP address. +But riemann with its single obfs4 port is a counterexample to that idea. + +This was the first time we saw blocking of multiple ports +on bridges that had been introduced during our measurements. +LeifEricson may be an example of the same phenomenon happening in the past, +before we even began our experiment. +The host LeifEricson had, since February 2014, been running bridges on multiple ports, +and obfs4 on port 41213 since October 2014. +% https://gitweb.torproject.org/builders/tor-browser-bundle.git/commit/?id=3279db32f147479af225d7106949e8dddd360dbb +% https://gitweb.torproject.org/builders/tor-browser-bundle.git/commit/?id=bb6389fbe7aa9539c4dce2aba0659e61ae8a376a +LeifEricson:41213 remained blocked +(except intermittently) throughout the entire experiment +(see point~\cnref{l} in \autoref{fig:proxy-probe-timelines-china1}). +We asked its operator to open additional obfs4 ports so we could rotate through them +in successive releases; +when we began testing them on +% 2016-08-30 17:43:25,muskie,83.212.101.3,50000,30.0267419815,False,None,timed out +August~30, 2016, they were all already blocked. +To confirm, on October~4 we asked the operator privately to open additional, randomly selected ports, +and they too were blocked, as was the SSH port~22. + +In \autoref{sec:china-failures}, we observed that ports +that had been caught up in whole-IP blocking exhibited different patterns +of intermittent reachability after blocking, +than did those ports that had been blocked individually. +We suspected that a two-tiered system left certain ports double-blocked---blocked +both by port and by IP address---which would make their +blocking robust to a failure of one of the tiers. +The same pattern seems to happen with LeifEricson. +The newly opened ports 50000, 50001, and 50002 share +brief periods of reachability in September and October 2016, +but port 41213 during the same time remained solidly down. + + +\subsection{No discovery of Orbot bridges} +\label{sec:china-orbot} + +Orbot, the Android version of Tor, +also includes default bridges. +It has its own bridge configuration file, +similar to Tor Browser's but in a different format. +Most of Orbot's bridges are borrowed from Tor Browser, +so when a bridge gets blocked, it ends up being blocked for both Orbot +and Tor Browser users. + +There were, however, a few bridges that were used only by Orbot +(see the ``Orbot bridges'' batch in \autoref{fig:proxy-probe-timelines-china1}). +They were only alternate ports on IP addresses that were already used by Tor Browser, +but they remained unblocked for over eight months, +even as the ports used by Tor Browser were blocked one by one. +The Orbot-only bridges were finally blocked---see point~\cnref{k} +in \autoref{fig:proxy-probe-timelines-china1}---as a side effect +of the whole-IP blocking that began in October 2016 (\autoref{sec:china-allports}). +(All of the Orbot bridges suffered outages, +as \autoref{fig:proxy-probe-timelines-china1} shows, but they +were the result of temporary misconfigurations, not blocking. +They were unreachable during those outages from the control site as well.) + +These results show that whatever mechanism the censor had +for discovering and blocking default Tor Browsers, +it had not even that much for discovering and blocking Orbot bridges. +Again we have a case of our assumptions not matching reality---blocking +that should be easy to do, and yet is not done. +A lesson to take from all this is that there is a benefit to +some degree of compartmentalization between sets of default bridges. +Even though they are all in theory easy to discover, +in practice the censor may not have built the necessary automation. + + +\subsection{Continued blocking of established bridges} +\label{sec:china-no-unblocking} + +We monitored some bridges that were already established and +had been distributed before we began our experiments. +As expected, they were already blocked at the beginning, and remained so +(point~\cnref{l} in \autoref{fig:proxy-probe-timelines-china1}). + + +\subsection{No blocking of unused bridges} +\label{sec:china-unused} + +As a control measure, we reserved a bridge in secret. +ndnop4:27668 (see point~\cnref{n} in \autoref{fig:proxy-probe-timelines-china1}) +was not published, neither in Tor Browser's bridge configuration file, +nor in BridgeDB. +As expected, it was never blocked. + + +\section{Results from Iran} +\label{sec:proxy-probe-iran} + +We had a probe site in Iran from December 2015 to June 2016, +a virtual private server which a personal contact could only +provide for a limited time. + +\begin{figure} +\centering +\includegraphics{figures/proxy-probe-timelines-iran} +\caption{ +Tor Browser default bridge reachability from Iran. +We found no evidence of blocking of default bridges in Iran. +What connection failures there were, +were also seen from our control site. +} +\label{fig:proxy-probe-timelines-iran} +\end{figure} + +In contrast to the situation in China, +in Iran we found no evidence of blocking. +See \autoref{fig:proxy-probe-timelines-iran}. +Although there were timeouts and refused connections, +they were the result of failures at the bridge side, +as confirmed by a comparison with measurements +from our control site. +This, despite the fact that Iran is a notorious censor, +and has in the past blocked Tor directory authorities~\cite{tor-trac-12727}. + +It seems that Iran has overlooked the blocking of default bridges. +Tor Metrics shows thousands of simultaneous bridge users +in Iran since 2014~\cite{tor-metrics-userstats-bridge-country-ir}, +so it is unlikely that the bridges were simply blocked in a way +that our probing script could not detect. +However, in Kazakhstan we found exactly that situation, +with bridges being effectively blocked +despite the firewall allowing TCP connections to them. + + +\section{Results from Kazakhstan} +\label{sec:proxy-probe-kazakhstan} + +We had a single probe site in Kazakhstan +between December 2016 and May 2017. +It was a VPN (virtual private network) node, +with IP address 185.120.77.110. +It was in AS~203087, which belongs to GoHost.kz, +a Kazakh hosting provider. +The flakiness of the VPN left us with two extended +gaps in measurements. + +\begin{figure}[p] +\centering +\includegraphics{figures/proxy-probe-timelines-kazakhstan} +\caption{ +Tor Browser default bridge reachability from Iran. +Judging by TCP reachability alone, +it would seem that the only disagreement with control---and +the only blocked bridge---is LeifEricson:41213, one of the oldest bridges. +However, actually trying to establish a Tor connection +through the obfs4 channel reveals that bridges actually are blocked. +} +\label{fig:proxy-probe-timelines-kazakhstan} +\end{figure} + +\begin{figure}[p] +\centering +\placeholder{3in} +\caption{ +Tor connection progress in the U.S.\ and Kazakhstan. +These measurements show that even though bridges accepted TCP connections, +the firewall usually caused them to stall before a Tor circuit +could be fully constructed. +The first three batches were blocked since before we started measuring; +the next two were blocked while we were watching; +and the last was not blocked. +} +\label{fig:proxy-probe-bridgetest-kazakhstan} +\end{figure} + +The bridge blocking in Kazakhstan was of a different nature +than that which we observed in China. +At a TCP reachability level, the only blocked bridge was +LeifEricson:41213---in \autoref{fig:proxy-probe-timelines-kazakhstan} +it is the only one whose measurements disagree with controls. +This, however, disagreed with reports of blocking of Tor +and pluggable transports since June 2016~\cite[\S obfs blocking]{kazakhstan-wiki}. +The reports stated that the connection would stall +(no packets received from the bridge) +a short time after the TCP handshake. + +We deployed an additional probe script in Kazakhstan. +This one did not only try to establish a TCP connection, +but also build a full Tor-in-obfs4 connection and build a circuit. +\autoref{fig:proxy-probe-bridgetest-kazakhstan} shows the results. +Tor reports its connection progress as a percentage; +connections to blocked bridges would usually fail at 25\%. +The bridges in the first three release batches were blocked +before we started measurements in December 2015. +The bridges in the 6.0.6/6.5a4 and 6.0.8/6.5a6 batches +were blocked on or around January~26, 2017, +evidenced by the fact that they usually progressed to 100\% +before that date, and only to 25\% after. +The blocking date comes either 71~or 43~days +after public release, depending on which release you compare to. + + +% \section{Other cases of delay} +% \label{sec:proxy-probe-other} + +% "2016-12-12 tr Turkey blocks direct Tor connections. The order to block had come on 2016-11-04." + +% - UAE & Egypt blocking Signal with domain fronting, ~11 months later, +% https://github.com/WhisperSystems/Signal-iOS/issues/2678#issuecomment-340391824 +% https://groups.google.com/forum/?hl=en#!topic/traffic-obf/bqeUYp5Vkow \chapter{Domain fronting} @@ -2903,8 +4148,8 @@ the App Engine bill (\$0.12/GB, with one~GB free each day) was less than \$1.00 per month for the first seven months of 2014~\cite[\S Costs]{meek-wiki}. In August, the cost started to be nonzero every day, and would continue to rise from there. -See \autoref{tab:meek-costs} for a history -of monthly costs. +See \autoref{tab:meek-costs} on page~\pageref{tab:meek-costs} +for a history of monthly costs. Tor Browser 4.0~\cite{tor-blog-tor-browser-40-released} was released on October 15, 2014. @@ -3292,539 +4537,453 @@ in the Kazakhstan work. Allot's marketing materials advertised support for detection of a wide variety of circumvention protocols, including Tor pluggable transports, Psiphon, -and various VPN services~\cite{traffic-obf-allot}. -They claimed support for ``Psiphon CDN (Meek mode)'' -going back to January 2015, -and for ``TOR (CDN meek)'' going back to April 2015. -We did not have any Allot devices to experiment with, -and I do not know how (or how well) their detectors worked. - -In June 2017, the estimated user count from Brazil -began to increase again, similarly to how it had -between July 2016 and March 2017. -Just as before, we did not find an explanation for the increase. - -Between July~29 and August~17, -meek-amazon had another outage due to an expired TLS certificate. - -\todo[inline]{Blocking of look-like-nothing, and success of domain fronting -during the 19th Chinese Communist Party Congress} - - -\chapter{Snowflake} -\label{chap:snowflake} - -\dragons - -\begin{figure} -\centering -\includegraphics{figures/snowflake} -\caption{ -Diagram of Snowflake. -} -\label{fig:snowflake} -\end{figure} - -Flash proxy revisited - -WebRTC fingerprinting - -Engineering challenges - -I am working on a new circumvention system, -a transport for Tor called Snowflake. -Snowflake is the successor to flash proxy. -It keeps the basic idea of in-browser proxies -while fixing the usability problems that hampered -the adoption of flash proxy. -My main collaborators in this project are -Arlo Breault, Serene Han, Mia Gil Epner, and Hooman Mohajeri. - -The key difference between flash proxy and Snowflake -is the basic communications protocol between client and browser proxy. -Flash proxy used the TCP-based WebSocket protocol, -which required users to configure their personal firewall -to allow incoming connections. -Snowflake instead uses WebRTC, a UDP-based protocol -that enables peer-to-peer connections without -manual configuration. -The most similar existing system is uProxy~\cite{uproxy}, -which in one of its operating modes -uses WebRTC to connect through a friend's computer. -Snowflake differs because it does not require -prior coordination with a friend before connecting. -Instead, it pulls its proxies from a pool of web users -who are running the Snowflake code. -Beyond the changed protocol, -we hope to build in performance and efficiency improvements. - -Snowflake will afford interesting research opportunities. -One, of course, is the design of the system itself---no -circumvention system of its nature -has previously been deployed at a large scale. -Another opportunity is observing how censors react -to a new challenge. - -Most of the available documentation on Snowflake is linked from -the project's wiki page~\cite{snowflake-wiki}. -Mia Gil Epner and I wrote a technical report on the fingerprinting -hazards of WebRTC~\cite{FifieldGilEpnerWebRTC}. - -\subsection{Flash proxy} - -I began working on censorship circumvention with flash proxy in 2011. -Flash proxy is targeted at the difficult problem -of proxy address blocking: -it is designed against a censor model -in which the censor can block any IP address it chooses, -but only on a relatively slow timeline of several hours. - -Flash proxy works by running tiny JavaScript proxies in -ordinary users' web browsers. -The mini-proxies serve as temporary stepping stones -to a full-fledged proxy, such as a Tor relay. -The idea is that the flash proxies are too numerous, -diverse, and quickly changing to block effectively. -A censored user may use a particular proxy for -only seconds or minutes before switching to another. -If the censor manages to block the IP address of one proxy, -there is little harm, -because many other temporary proxies are ready to take its place. - -The flash proxy system was designed under interesting constraints -imposed by being partly implemented in JavaScript in the browser. -The proxies sent and received data using the WebSocket protocol, -which allows for socket-like -persistent TCP connections in browsers, but with a catch: -the browser can only -make outgoing connections, not receive incoming ones as a traditional proxy would. -The censored client must somehow inform the system of its own public address, -and then the proxy connects \emph{back} to the client. -This architectural constraint was probably -the biggest impediment to the usability of flash proxy, -because it required users to configure their local router -to permit incoming connections. -(Removing this impediment is the main reason -for the development of Snowflake, described later.) -Flash proxy does not itself try to obfuscate patterns -in the underlying traffic; -it only provides address diversity. - -For the initial ``rendezvous'' step in which a client advertises -its address and a request for proxy service, -flash proxy uses a neat idea: -a low-capacity, but highly covert channel bootstraps -the high-capacity, general-purpose WebSocket channel. -For example, we implemented an automated email-based rendezvous, -in which the client would send its address in an encrypted email to a special address. -While it is difficult to build a useful low-latency bidirectional channel -on top of email, -email is difficult to block -and it is only needed once, at the beginning of a session. -We later replaced the email-based rendezvous with one based on domain fronting, -which would later inspire -meek, described below. - -I was the leader of the flash proxy project and the main developer of its code. -Flash proxy was among the first circumvention systems built for Tor---only -obfs2 is older. -It was first deployed in Tor Browser in January 2013, -and was later retired in January 2016 -after it ceased to see appreciable use. -Its spirit lives on in Snowflake, now under development. - -Flash proxy appeared in the 2012 research paper -``Evading Censorship with Browser-Based Proxies''~\cite{Fifield2012a-local}, -which I coauthored with -Nate Hardison, Jonathan Ellithorpe, Emily Stark, Roger Dingledine, Phil Porras, and Dan Boneh. - -% \section{How does it end?} - -% Probably the circumstances of the world change -% and make irrelevant this field of study. -% How can we reach that moment favorably? -% (Spend the war winning, not losing.) - -\appendix - -\chapter{Summary of censorship measurement studies} - -Here I survey past measurement studies -which have helped to build models -about censor behavior in general. -The objects of the survey are -based on those in an evaluation study done by -me and others in 2016~\cite[\S IV.A]{Tschantz2016a-local}. - -One of the earliest technical studies of censorship occurred -not in some illiberal place, but in the German state of -North Rhein-Westphalia. -In 2003, Dornseif~\cite{Dornseif2003a} tested ISPs' implementation -of a controversial legal order to block two Nazi web sites. -While there were many possible ways to implement the block, -none were trivial to implement, nor free of overblocking side effects. -The most popular implementation used \emph{DNS tampering}, -simply returning (or injecting) false responses to DNS requests -for the domain names of the blocked sites. -An in-depth survey of DNS tampering -found a variety of implementations, some blocking more -and some blocking less than required by the order. - -% TODO: \cite{Zittrain2003a} - -Clayton~\cite{Clayton2006b} in 2006 studied a ``hybrid'' blocking system, -called ``CleanFeed'' by the British ISP BT, -that aimed for a better balance of costs and benefits: -a ``fast path'' IP address and port matcher -acted as a prefilter for the ``slow path,'' a full HTTP proxy. -The system, in use since 2004, -was designed to block access to any of a secret list of -pedophile web sites compiled by a third party. -The author identifies ways to circumvent or attack such a system: -use a proxy, use source routing to evade the blocking router, -obfuscate requested URLs, use an alternate IP address or port, -return false DNS results to put third parties on the ``bad'' list. -They demonstrate that the two-level nature of the blocking system -unintentionally makes it an oracle -that can reveal the IP addresses of sites in the secret blocking list. - -\cite{OpenNet2008AccessDenied} - -For a decade, the OpenNet Initiative produced reports -on Internet filtering and surveillance in dozens of countries, -until it ceased operation in 2014. -For example, their 2005 report on Internet filtering in China~\cite{oni-china-2005} -studied the problem from many perspectives, -political, technical, and legal. -They translated and interpreted Chinese laws relating to the Internet, -which provide strong legal justifications for filtering. -The laws regulate both Internet users and service providers, -including cybercafes. -They prohibit the transfer of information that is indecent, -subversive, false, criminal, or that reveals state secrets. -The OpenNet Initiative tested the extent of filtering -of web sites, search engines, blogs, and email. -They found a number of blocked web sites, -some related to news and politics, and some on sensitive subjects -such as Tibet and Taiwan. -In some cases, entire sites (domains) were blocked; -in others, only specific pages within a larger site were blocked. -In a small number of cases, sites were accessible by -IP address but not by domain name. -There were cases of overblocking: apparently inadvertently blocked sites -that simply shared an IP address or URL keyword -with an intentionally blocked site. -On seeing a prohibited keyword, the firewall blocked connections -by injecting a TCP RST packet to tear down the connection, -then injecting a zero-sized TCP window, -which would prevent any communication with the same server -for a short time. -Using technical tricks, the authors inferred -that Chinese search engines index blocked sites -(perhaps having a special exemption from the general firewall policy), -but do not return them in search results. -% https://opennet.net/bulletins/005/ -The firewall blocks access searches for certain keywords on Google -as well as the Google Cache---but the latter could be worked around -by tweaking the format of the URL. -% https://opennet.net/bulletins/006/ -Censorship of blogs comprised keyword blocking -by domestic blogging services, -and blocking of external domains such as blogspot.com. -% https://opennet.net/bulletins/008/ -Email filtering is done by the email providers themselves, -not by an independent network firewall. -Email providers seem to implement their filtering rules -independently and inconsistently: -messages were blocked by some providers and not others. -% More ONI? -% \cite{oni-china-2007} -% \cite{oni-china-2009} -% \cite{oni-china-2012} -% \cite{oni-iran-2005} -% \cite{oni-iran-2007} -% \cite{oni-iran-2009} - -In 2006, Clayton, Murdoch, and Watson~\cite{Clayton2006a} -further studied the technical aspects of the Great Firewall of China. -They relied on an observation that the firewall was symmetric, -treating incoming and outgoing traffic equally. -By sending web requests from outside the firewall to a web server inside, -they could provoke the same blocking behavior -that someone on the inside would see. -They sent HTTP requests containing forbidden keywords (e.g., ``falun'') -caused the firewall to inject RST packets -towards both the client and server. -Simply ignoring RST packets (on both ends) -rendered the blocking mostly ineffective. -The injected packets had inconsistent TTLs and other anomalies -that enabled their identification. -Rudimentary countermeasures such as splitting keywords -across packets were also effective in avoiding blocking. -The authors of this paper bring up an important point -that would become a major theme of future censorship modeling: -censors are forced to trade blocking effectiveness -against performance. -In order to cope with high load at a reasonable costs, -censors may choose the architecture of a network monitor -or intrusion detection system, -one that can passively monitor and inject packets, -but cannot delay or drop them. +and various VPN services~\cite{traffic-obf-allot}. +They claimed support for ``Psiphon CDN (Meek mode)'' +going back to January 2015, +and for ``TOR (CDN meek)'' going back to April 2015. +We did not have any Allot devices to experiment with, +and I do not know how (or how well) their detectors worked. -A nearly contemporary study by Wolfgarten~\cite{Wolfgarten2006a} -reproduced many of the results of Clayton, Murdoch, and Watson. -Using a rented server in China, the author found cases of -DNS tampering, search engine filtering, and RST injection -caused by keyword sniffing. -Not much later, in 2007, Lowe, Winters, and Marcus~\cite{Lowe2007a} -did detailed experiments on DNS tampering in China. -They tested about 1,600 recursive DNS servers in China -against a list of about 950 likely-censored domains. -For about 400 domains, responses came back with bogus IP addresses, -chosen from a set of about 20 distinct IP addresses. -Eight of the bogus addresses were used more than the others: -a whois lookup placed them in Australia, Canada, China, Hong Kong, and the U.S. -By manipulating TTLs, the authors found that the false responses -were injected by an intermediate router: -the authentic response would be received as well, only later. -A more comprehensive survey~\cite{Anonymous2014a} -of DNS tampering and injection occurred in 2014, -giving remarkable insight into the internal structure -of the censorship machines. -DNS injection happens only at border routers. -IP ID and TTL analysis show that each node -is a cluster of several hundred processes -that collectively inject censored responses. -They found 174 bogus IP addresses, more than previously documented. -They extracted a blacklist of about 15,000 keywords. +In June 2017, the estimated user count from Brazil +began to increase again, similarly to how it had +between July 2016 and March 2017. +Just as before, we did not find an explanation for the increase. -\cite{Wright2012a} +Between July~29 and August~17, +meek-amazon had another outage due to an expired TLS certificate. -The Great Firewall, because of its unusual sophistication, -has been an enduring object of study. -Part of what makes it interesting is its many blocking modalities, -both active and passive, proactive and reactive. -The ConceptDoppler project of Crandall et~al.~\cite{Crandall2007a} -measured keyword filtering by the Great Firewall -and showed how to discover new keywords automatically -by latent semantic analysis, using -the Chinese-language Wikipedia as a corpus. -They found limited statefulness in the firewall: -sending a naked HTTP request -without a preceding SYN resulted in no blocking. -In 2008 and 2009, Park and Crandall~\cite{Park2010a} -further tested keyword filtering of HTTP responses. -Injecting RST packets into responses is more difficult -than doing the same to requests, -because of the greater uncertainty in predicting -TCP sequence numbers -once a session is well underway. -In fact, RST injection into responses was hit or miss, -succeeding only 51\% of the time, -with some, apparently diurnal, variation. -They also found inconsistencies in the statefulness of the firewall. -Two of ten injection servers would react to a naked HTTP request; -that it, one sent outside of an established TCP connection. -The remaining eight of ten required an established TCP connection. -Xu et~al.~\cite{Xu2011a} continued the theme of keyword filtering in 2011, -with the goal of -discovering where filters are located at the IP and AS levels. -Most filtering is done at border networks -(autonomous systems with at least one non-Chinese peer). -In their measurements, the firewall was fully stateful: -blocking was never -triggered by an HTTP request outside an established TCP connection. -Much filtering occurs -at smaller regional providers, -rather than on the network backbone. +\todo[inline]{Blocking of look-like-nothing, and success of domain fronting +during the 19th Chinese Communist Party Congress} -Winter and Lindskog~\cite{Winter2012a} -did a formal investigation into active probing, -a reported capability of the Great Firewall since around October 2011. -They focused on the firewall's probing of Tor relays. -Using private Tor relays in Singapore, Sweden, and Russia, -they provoked active probes by -simulating Tor connections, collecting 3295 firewall scans over 17 days. -Over half the scan came from a single IP address in China; -the remainder seemingly came from ISP pools. -Active probing -is initiated every 15 minutes and each burst lasts for about 10 minutes. -Sfakianakis et~al.~\cite{Sfakianakis2011a} -built CensMon, a system for testing web censorship -using PlanetLab nodes as distributed measurement points. -They ran the system for for 14 days in 2011 across 33 countries, -testing about 5,000 unique URLs. -They found 193 blocked domain–country pairs, 176 of them in China. -CensMon reports the mechanism of blocking. -Across all nodes, it was -18.2\% DNS tampering, -33.3\% IP address blocking, and -48.5\% HTTP keyword filtering. -The system was not run on a continuing basis. -Verkamp and Gupta~\cite{Verkamp2012a} -did a separate study in 11 countries, -using a combination of PlanetLab nodes -and the computers of volunteers. -Censorship techniques vary across countries; -for example, some show overt block pages and others do not. -China was the only stateful censor of the 11. -% \cite{Mathrani2010a} +\chapter{Snowflake} +\label{chap:snowflake} -PlanetLab is a system that was not originally designed for censorship measurement, -that was later adapted for that purpose. -Another recent example is RIPE Atlas, -a globally distributed Internet -measurement network consisting of physical probes hosted by volunteers, -Atlas allows 4 types of measurements: ping, traceroute, DNS resolution, -and X.509 certificate fetching. -Anderson et~al.~\cite{Anderson2014a} -used Atlas to examine two case studies of censorship: -Turkey's ban on social media sites in March 2014 and -Russia's blocking of certain LiveJournal blogs in March 2014. -In Turkey, they -found at least six shifts in policy during two weeks of site blocking. -They observed an escalation in blocking in Turkey: -the authorities first poisoned DNS for twitter.com, -then blocked the IP addresses of the Google public DNS servers, -then finally blocked Twitter's IP addresses directly. -In Russia, they found ten unique bogus IP addresses used to poison DNS. +Snowflake is a new circumvention system currently under development. +It is based on peer-to-peer connections +through lightweight, ephemeral proxies +that run in web browsers. +Snowflake proxies are lightweight: +activating one is as easy as browsing to a web page +and shutting one down only requires closing the browser tab. +They serve only as temporary stepping stones +to a full-fledged proxy. +Snowflake derives its blocking resistance from +having a large number of proxies. +A~client may use a particular proxy for +only seconds or minutes before switching to another. +If the censor manages to block the IP address of one proxy, +there is little harm, +because many other temporary proxies are ready to take its place. -Most research on censors has focused on the blocking of -specific web sites and HTTP keywords. -A few studies have looked at less discriminating -forms of censorship: outright shutdowns and throttling without fully blocking. -Dainotti et~al.~\cite{Dainotti2011a} -reported on the total Internet shutdowns -that took place in Egypt and Libya -in the early months of 2011. -They used multiple measurements to document -the outages as they occurred: -BGP data, a large network telescope, and active traceroutes. -During outages, there was a drop in scanning traffic -(mainly from the Conficker botnet) to their telescope. -By comparing these different measurements, -they showed that the shutdown in Libya was accomplished -in more that one way, -both by altering network routes and by firewalls dropping packets. -Anderson~\cite{Anderson2013a-local} -documented network throttling in Iran, -which occurred over two major periods between 2011 and 2012. -Throttling degrades network access without totally blocking it, -and is harder to detect than blocking. -The author argues that a hallmark of throttling -is a decrease in network throughput -without an accompanying increase in latency and packet loss, -distinguishing throttling from ordinary network congestion. -Academic institutions were affected by throttling, -but less so than other networks. -Aryan et~al.~\cite{Aryan2013a} -tested censorship in Iran -during the two months before the June 2013 presidential election. -They found multiple blocking methods: HTTP request keyword filtering, -DNS tampering, and throttling. -The most usual method was HTTP request filtering. -DNS tampering (directing to a blackhole IP address) -affected only three domains: -facebook.com, -youtube.com, and -plus.google.com. -SSH connections were throttled down to about 15\% -of the link capacity, -while randomized protocols were throttled almost down to zero -60 seconds into a connection's lifetime. -Throttling seemed to be achieved by dropping packets, thereby -forcing TCP's usual recovery. +Snowflake~\cite{snowflake-wiki} is the spiritual successor +to flash proxy~\cite{Fifield2012a-local}, +a system that similarly used browser-based proxies. +Flash proxy, with obfs2 and obfs3, was one of the first three pluggable +transports for Tor~\cite{tor-blog-combined-flash-proxy-pyobfsproxy-browser-bundles}, +but since its introduction in 2013 it never +had many users~\cite{tor-metrics-userstats-bridge-transport-websocket}. +I~believe that its lack of adoption was a result mainly +of its incompatibility with NAT (network address translation): +its use of the TCP-based WebSocket protocol~\cite{rfc6455} +required clients to follow complicated port forwarding instructions~\cite{flashproxyhowto-wiki}. +For that reason flash proxy was deprecated in 2016~\cite{tor-trac-17428}. + +Snowflake keeps flash proxy's basic idea of in-browser proxies, +but replaces WebSocket with WebRTC~\cite{draft-ietf-rtcweb-overview}, +a suite of protocols for peer-to-peer communications. +Importantly, WebRTC is UDP-based +and includes facilities for NAT traversal, +allowing most clients to use it without manual configuration. +WebRTC mandatorily encrypts its channels, +which as a side effect obscures any keywords or byte patterns +in the tunneled traffic. +(While leaving open the possibility of detecting +the very use of WebRTC itself---see \autoref{sec:webrtc-fingerprinting}.) + +Aside from flash proxy, +the most similar existing design was a former version of uProxy~\cite{uproxy}. +uProxy required clients to know a confederate outside +the censor's network who could run a proxy. +The client would connect through the proxy +using WebRTC; the proxy would then directly fetch +the client's requested URLs. +Snowflake centralizes the proxy discovery process, +removing the requirement to arrange one's own proxy +outside the firewall. +Snowflake proxies are merely dumb pipes to a more capable proxy, +allowing them to carry traffic other than web traffic, +and preventing them from spying on the client's traffic. +prior coordination with a friend before connecting. -Khattak et~al.~\cite{Khattak2013a} -evaluated the Great Firewall from the perspective that it works like -an intrusion detection system or network monitor, -and applied existing technique for evading a monitor -the the problem of circumvention. -They looked particularly for ways to -evade detection that are expensive for the censor to remedy. -They found that the firewall is stateful, -but only in the client-to-server direction. -The firewall is vulnerable to a variety of TCP- and HTTP-based evasion -techniques, such as overlapping fragments, TTL-limited packets, -and URL encodings. +The name ``Snowflake'' comes from one of WebRTC's subprotocols, +called ICE (Interactive Connectivity Establishment)~\cite{rfc5245}, +and from the temporary proxies, +which resemble snowflakes in their impermanence and uniqueness. -Nabi~\cite{Nabi2013a} -investigated web censorship in Pakistan in 2013, using a publicly known -list of banned web sites. -They tested on 5 different networks in Pakistan. -Over half of the sites on the list were blocked by DNS tampering; -less than 2\% were additionally blocked by HTTP filtering -(an injected redirection before April 2013, -or a static block page after that). -They conducted a small survey to find the most -commonly used circumvention methods in Pakistan. -The most used method was public VPNs, at 45\% of respondents. +Snowflake now exists in an experimental alpha release, +incorporated into Tor Browser. +My main collaborators on the Snowflake project are +Arlo Breault, Mia Gil~Epner, Serene Han, and Hooman Mohajeri. -Ensafi et~al.~\cite{Ensafi2015a} -employed an intriguing technique to measure censorship -from many locations in China---a ``hybrid idle scan.'' -The hybrid idle scan allows one to test TCP connectivity -between two Internet hosts, -without needing to control either one. -They selected roughly uniformly geographically distributed sites -in China from which to measure connectivity to -Tor relays, Tor directory authorities, -and the web servers of popular Chinese web sites. -There were frequent failures of the firewall resulting -in temporary connectivity, typically lasting in bursts of hours. -In 2015, Marczak et~al.~\cite{Marczak2015a-local} -investigated an innovation in the capabilities -of the border routers of China, -an attack tool dubbed the ``Great Cannon.'' -The cannon was responsible for denial-of-service attacks -on Amazon CloudFront and GitHub. -The unwitting participants in the attack were -web browsers located outside of China, -who began their attack when the cannon injected -malicious JavaScript into certain HTTP responses -originating in China. -The new attack tool is noteworthy because it demonstrated -previously unseen in-path behavior, -such as packet dropping. +\section{Design} +\label{sec:snowflake-design} -Not every censor is China, -with its sophisticated homegrown firewall. -A major aspect of censor modeling is that -many censors use commercial firewall hardware. -A case in point is the analysis by -Chaabane et~al.~\cite{Chaabane2014a} -of 600 GB of leaked logs from Blue Coat proxies -used for censorship in Syria. -The logs cover 9 days in July and August 2011, -and contain an entry for every HTTP request. -The authors of the study found evidence of IP address blocking, -domain name blocking, and HTTP request keyword blocking, -and also of users circumventing censorship -by downloading circumvention software or using the Google cache. -All subdomains of .il, the top-level domain for Israel, -were blocked, as were many IP address ranges in Israel. -Blocked URL keywords included -``proxy'', -``hotspotshield'', -``israel'', and -``ultrasurf'' -(resulting in collateral damage to the Google Toolbar -and Facebook Like button because they have ``proxy'' in HTTP requests). -Tor was only lightly censored---only one of several proxies -blocked it, and only sporadically. -% \cite{CitizenLab2013opakistan} -% \cite{Marquis2013planet} +\begin{figure} +\centering +\placeholder{3in} +\caption{ +Schematic of Snowflake. +} +\label{fig:snowflake} +\end{figure} + +There are three main components of the Snowflake system. +Refer to \autoref{fig:snowflake}. +\begin{itemize} +\item +many \emph{snowflake proxies} (``snowflakes'' for short), +which communicate with clients using WebRTC and forward +their traffic to the bridge +\item +many \emph{clients}, responsible for +initially requesting service and then routing traffic +though snowflakes as they arrive +\item +the \emph{broker}, an online database that serves +to match clients with snowflakes +\item +the \emph{bridge} +(so called to distinguish it from the snowflake proxies), +a full-featured proxy capable of connecting to any destination +\end{itemize} +The architecture of the system is influenced +by the requirement that proxies run in a browser, +and the nature of WebRTC connection establishment, +which uses a bidirectional handshake. +In our implementation, the bridge is really a Tor bridge. +Even though a Tor circuit consists of multiple hops, +that fact is abstracted away from the client's perspective; +the Snowflake design does not inherently depend on Tor. + +A Snowflake connection happens in multiple steps +(refer to \autoref{fig:snowflake}). +In the first part, called \emph{rendezvous}, +the client and snowflake exchange information +necessary for a WebRTC connection. +\begin{enumerate} +\item +The client registers its need for service by sending +a message to the broker. +The message, called an \emph{offer}~\cite{rfc3264}, +contains the client's IP address and other +metadata needed to establish a WebRTC connection. +How the client sends its offer is further explained below. +\item +At some point, a snowflake comes online +and polls the broker. +The broker hands the client's offer to the proxy, +which sends back its \emph{answer}~\cite{rfc3264}, +containing its IP address and other connection metadata +the client will need to know. +\item +The broker sends back to the client +the snowflake's answer message. +\end{enumerate} +At this point rendezvous is finished. +The snowflake has the client's offer, +and the client has the snowflake's answer, +so they have all the information needed +to establish a WebRTC connection to each other. +\begin{enumerate}[resume] +\item +The client and snowflake proxy +connect to each other using WebRTC. +\item +The snowflake proxy connects to the bridge +(using WebSocket, though the specific type of channel +does not matter for this step). +\item +The snowflake proxy copies data back and forth +between client and bridge until it is terminated. +The client's communication with the bridge is +encrypted and authenticated end-to-end through +the WebRTC tunnel, +so the proxy may not interfere with it. +\end{enumerate} +When the snowflake proxy terminates, +the client may request a new one. +Various optimizations are possible, +such as having the client maintain a pool of proxies +so as to bridge gaps in connectivity, +but we have not implemented and tested them +sufficiently to state their effects. + +The rendezvous phase bears further explanation. +Steps~1, 2, and~3 actually happen synchronously, +using interleaved HTTP requests and responses. +See \autoref{fig:snowflake-rendezvous}. +The client's single request uses domain fronting and +the snowflake's are direct. +In Step~1, the client sends an request containing its offer. +The broker holds the connection open but does not immediately respond. +In Step~2, a snowflake makes a polling request +(``do you have any clients for me?'') +and the broker responds with the client's offer. +The snowflake composes its answer and sends it back +to the broker in a second HTTP request +(linked to the first by a random token). +In Step~3, the broker finally responds to the client's +initial request by passing on the snowflake's answer. +From the client's point of view, it has sent +a single request (containing an offer) +and received a single response (containing an answer). +If no proxy arrives within a time threshold of the client +sending its offer, the broker replies with an error message instead. +We learned from the experience of running flash proxy +that it is not difficult to archive a proxy arrival rate of +several per second, so timeouts should be exceptional. + +\begin{figure} +\centering +\small +\begin{verbatim} +// diagram to be redrawn +client broker snowflake + domain-fronted + 1. ------------------> + POST /offer <-------------------- 2.1 + [offer] GET /proxy + + --------------------> 2.2 + 200 OK + [offer] + + <-------------------- 2.3 + POST /answer + [answer] + + --------------------> 2.4 + 3. <------------------ 200 OK + 200 OK + [answer] +\end{verbatim} +\caption{ +Snowflake rendezvous. +The client makes only one HTTP request--response pair. +In between the client's request and response, +the snowflake proxy makes two of its own request--response pairs, +the first to learn the client's offer and the second +to send back its answer. +} +\label{fig:snowflake-rendezvous} +\end{figure} -% \cite{Anderson2012splinternet} -% \cite{Dalek2013a} -% \cite{Gill2015a} +One may ask, if the domain-fronted rendezvous channel +is bidirectional and already assumed to be difficult to block, +why doesn't it suffice for circumvention on its own? +Well, it does suffice, and it's called meek +(\autoref{sec:meek-history}). +The main disadvantage of domain fronting, though, is its high cost +(see \autoref{tab:meek-costs} on page~\pageref{tab:meek-costs}). +Snowflake offloads the bulk of data transfer onto WebRTC, +and uses expensive domain fronting only for rendezvous. + +There are two reasons why the snowflake proxies +forward client traffic to a separate bridge, +rather than connecting directly to the +client's desired destination. +The first is generality: a browser-based proxy +can only do the things a browser can do; +it can fetch web pages but cannot, for example, +open sockets to arbitrary destinations. +The second is privacy: +the proxies are operated by untrusted, +potentially malicious strangers. +If they were to exit client traffic directly, +they could tamper with it; +furthermore a malicious \emph{client} +would be able to cause a well-meaning proxy +to connect to suspicious destinations, +potentially getting its operator in trouble. +This is essentially +untrusted messenger delivery~\cite{Feamster2003a}, +proposed by Feamster et~al.\ in~2003. + +WebRTC offers two features that are necessary for Snowflake: +\begin{enumerate*} +\item it is supported in web browsers, and +\item it deals with NAT. +\end{enumerate*} +In other respects, though, WebRTC is a nuisance. +Its close coupling with browser code makes it difficult +to use as a library outside of a browser; +a big part of the Snowflake project was to +extract the code into a reusable library, +\mbox{go-webrtc}~\cite{go-webrtc}. +WebRTC comes with a lot of baggage around audio and video codecs, +which is useful for some of its intended use cases, +but which we would prefer not to have to deal with. +Working within a browser environment limits our flexibility, +because we cannot access the network directly, +but only at arm's length through some or other~API. +This has implications for detection by content, +as discussed in the next section. + + +\section{WebRTC fingerprinting} +\label{sec:webrtc-fingerprinting} + +Snowflake primarily tackles the problem of +detection by address. +The pool of temporary proxies changes too quickly +for a censor to keep up with +(at least that's the idea). +Equally important, though, +is the problem of detection by content. +If Snowflake's protocol has an easily +detectable ``tell,'' then it could be blocked +despite its address diversity. +Just as with meek we were concerned about +TLS fingerprinting (\autoref{sec:meek-impl}), +with Snowflake we are concerned with +WebRTC fingerprinting. + +Snowflake will always look like WebRTC---that's +unavoidable without a major change in architecture. +Therefore the best we can hope for is to make +Snowflake's WebRTC hard to distinguish from other +applications of WebRTC. +And that alone is not enough---it also +must be that the censor is reluctant to block +those other uses of WebRTC. + +Mia Gil~Epner and I~began an investigation into +the potential fingerprintability of +WebRTC~\cite{FifieldGilEpnerWebRTC,snowflake-fingerprinting-wiki}. +While preliminary, we were able to find many +potential fingerprinting features, +and a small survey of applications revealed +a diversity of implementation choices in practice. + +WebRTC is a stack of interrelated protocols, +and leaves implementers much freedom to combined them +in different ways. +We checked the various protocols in order +to find places where implementation choices +could facilitate fingerprinting. +\begin{description} +\item[Signaling] +Signaling is WebRTC's term for the exchange of +metadata and control data necessary to establish +the peer-to-peer connection. +WebRTC offers no standard way to do signaling~\cite[\S 3]{draft-ietf-rtcweb-overview}; +it is left up to implementers. +For example, some implementations do signaling via +XMPP, an instant messaging protocol. +Snowflake does signaling through the broker, +during the rendezvous phase. +\item[ICE] +ICE (Interactive Connectivity Establishment)~\cite{rfc5245} +is a combination of two protocols. +STUN (Session Traversal Utilities for NAT)~\cite{rfc5389} +helps hosts open and maintain a binding +in a NAT table. +TURN (Traversal Using Relays around NAT)~\cite{rfc5766} +is a way to proxying through a third party, +when the end hosts' NAT configurations are such +that they cannot communicate directly. +In STUN, both client and server messages have +a number of optional attributes, +including one called SOFTWARE +that directly specifies the implementation. +Furthermore, the very choice of what STUN and TURN server +to use is a choice made by the client. +\item[Media and data channels] +WebRTC offers media channels (used for audio and video) +as well as two kinds of data channels +(stream-oriented reliable and datagram-oriented unreliable). +All channels are encrypted, +however they are encrypted differently +according to their type. +Media channels use +SRTP (Secure Real-time Transport Protocol)~\cite{rfc3711} +and data channels use +DTLS (Datagram TLS)~\cite{rfc6347}. +Even though the contents of both are encrypted, +an observer can easily distinguish a media channel from a data channel. +Applications that use media channels have +options for doing key exchange: +some borrow the DTLS handshake in a process called +DTLS-SRTP~\cite{rfc5764} +and some use +SRTP with Security Descriptions (SDES)~\cite{rfc4568}. +Snowflake uses reliable data channels. +\item[DTLS] +DTLS, as with TLS, +offers a wealth of fingerprintable features. +Some of the most salient are the protocol version, +extensions, +the client's offered ciphersuites, +and values in the server's certificate. +\end{description} -\cite{Gwagwa_a_study_of_internet-based_information_controls_in_rwanda} -and other OONI. +Snowflake uses a WebRTC library extracted +from the Chromium web browser, +which mitigates some potential +dead-parrot distinguishers~\cite{Houmansadr2013b}. +But the protocol remains complicated +and its behavior on the network +depends on more than the WebRTC library in use. + +We conducted a survey of some WebRTC-using applications +in order to get an idea of the implementation choices +being made in practice. +We tested three applications that use media channels, +all chat services: +Google Hangouts (\url{https://hangouts.google.com}), +Facebook Messenger (\url{https://www.messenger.com}), +and OpenTokRTC (\url{https://opentokrtc.com/}). +We also tested two applications that use data channels: +Snowflake itself and +Sharefest (\url{https://github.com/Peer5/ShareFest}), +a now-defunct file sharing service. +Naturally, the network fingerprints of all five applications +were distinguishable at some level. +Snowflake, by default, uses a Google-operated STUN server, +which may be a good choice because +so do Hangouts and Sharefest. +All applications other than Hangouts +used DTLS for key exchange. +While the client portions differed, +the server certificate was more promising, +in all cases having a Common Name\index{common name (X.509)} +of ``WebRTC'' and a validity of 30~days. + +Finally, we wrote a script~\cite{github-DTLS-fingerprint} +to detect and fingerprint +DTLS handshakes. +While DTLS does not +Vern Paxson ran it for us on a day's worth of traffic +from Lawrence Berkeley National Lab. +The script turned up only seven handshakes, +having three distinct fingerprints. +While it is difficult to generalize from one measurement at one site, +these results suggest that WebRTC use---at least the forms +that use DTLS---is not common. +We guessed that Google Hangouts would be the +main source of WebRTC connections; +however our script would not have found Hangouts connections +because Hangouts does not use DTLS. + + +% \chapter{Don't call it a conclusion} -Analyzing Internet Censorship in Pakistan\cite{Aceto2016a} +% Probably the circumstances of the world change +% and make irrelevant this field of study. +% How can we reach that moment favorably? +% (Spend the war winning, not losing.) \backmatter