diff --git a/thesis.tex b/thesis.tex index df8ef55..d1673a0 100644 --- a/thesis.tex +++ b/thesis.tex @@ -8,11 +8,13 @@ \usepackage[utf8]{inputenc} \usepackage{CJKutf8} +\usepackage[font=small]{caption} \usepackage[inline]{enumitem} \usepackage{graphicx} \usepackage{microtype} \usepackage{relsize} \usepackage[table,x11names]{xcolor} +\usepackage{tocloft} \usepackage{todonotes} % http://grad.berkeley.edu/academic-progress/dissertation/: @@ -23,20 +25,29 @@ \usepackage{makeidx} \makeindex +\usepackage{idxlayout} % 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} +\usepackage[backend=biber,bibencoding=utf8,sortcites=true,datamodel=indexname,indexing=cite,maxnames=99,backref=true]{biblatex} \bibliography{local,censor-local,censor} % Remove "URL: " prefix from bibliography URLs. Original declaration is from % texmf-dist/tex/latex/biblatex/biblatex.def. \DeclareFieldFormat{url}{\url{#1}} % Better look for citations that include a section reference like \cite[\S 3]{foobar}. \renewcommand{\postnotedelim}{~} + +% We want to use BibTeX indexing of the authors of citations, but we don't want +% to index every single citation. Opt in to indexing with this \indexauthors{} macro. +\newif\ifindexauthors +\indexauthorsfalse +\newcommand{\indexauthors}[1]{{\indexauthorstrue #1\indexauthorsfalse}} + % Index only author names, not work titles. % https://tex.stackexchange.com/a/305486 -\renewbibmacro*{citeindex}{\ifciteindex{\indexnames{author}}{}} -\renewbibmacro*{bibindex}{\ifbibindex{\indexnames{author}}{}} +% For citeindex, additionally check \ifindexauthors (i.e. we're inside \indexauthors{}) +\renewbibmacro*{citeindex}{\ifciteindex{\ifindexauthors\ifnameundef{indexname}{\indexnames{labelname}}{\indexnames{indexname}}}{}\else\fi} +\renewbibmacro*{bibindex}{\ifbibindex{\ifnameundef{indexname}{\indexnames{labelname}}{\indexnames{indexname}}}{}} \usepackage[hidelinks]{hyperref} \urlstyle{same} @@ -65,8 +76,18 @@ \let\ftype@table\ftype@figure \makeatother +\hyphenation{cymru-bridge} +\hyphenation{fdc-tor-bridge} \hyphenation{GAE-uploader} \hyphenation{Go-Agent} +\hyphenation{Green-Belt} +\hyphenation{Jon-beshe-Sabz} +\hyphenation{Kazakh-stan} +\hyphenation{Leif-Eric-son} +\hyphenation{Lis-beth} +\hyphenation{Ma-Bisho-marim} +\hyphenation{Proxi-max} +\hyphenation{rie-mann} \hyphenation{Web-RTC} @@ -77,6 +98,81 @@ \newcommand{\cnref}[1]{\textcircled{\smaller\fontfamily{phv}\selectfont #1}} +% Indexing cheat sheet +% https://en.wikibooks.org/wiki/LaTeX/Indexing#Sophisticated_indexing +% \index{hello} Plain +% \index{hello!Peter} Subentry +% \index{Sam@\textbf{Sam}} Formatted entry +% \index{Jenny|textbf} Formatted page number +% \index{ecole@\'ecole} Handling of accents +% \index{Peter|see {hello}} +% \index{Jen|seealso{Jenny}} +% \index{topic|(} Begin range +% \index{topic|)} End range + +% Helper for putting seealso on a separate line. +% https://tex.stackexchange.com/a/86662 +\makeatletter +\newcommand{\gobblecomma}[1]{\@gobble{#1}\ignorespaces} +\makeatother +\index{Adobe Flash|see {Flash}} +\index{Amazon CloudFront!zzz@\gobblecomma|seealso {meek-amazon}} +\index{App Engine|see {Google App Engine}} +\index{appspot.com@\nolinkurl{appspot.com}|see {Google App Engine}} +\index{APT29|see {Cozy Bear}} +\index{AS|see {autonomous system}} +\index{Azure|see {Microsoft Azure}} +\index{broker|see {Snowflake, broker}} +\index{ciphersuite|see {TLS, fingerprinting}} +\index{CDN|see {content delivery network}} +\index{CN|see {common name (X.509)}} +\index{CN|see {China}} +\index{China!zzz@\gobblecomma|seealso {Great Firewall of China}} +\index{CloudFront|see {Amazon CloudFront}} +\index{decoy routing|see {refraction networking}} +\index{default Tor bridge|see {Tor Bridge, default}} +\index{domain fronting!zzza@\gobblecomma|seealso {front domain}} +\index{domain fronting!zzzb@\gobblecomma|seealso {meek}} +\index{Domain Name System|see {DNS}} +\index{DPI|see {deep packet inspection}} +\index{end-to-middle proxying|see {refraction networking}} +\index{entropy!zzz@\gobblecomma|seealso {Kullback--Leibler divergence}} +\index{false positives!zzz@\gobblecomma|seealso {collateral damage}} +\index{format-transforming encryption|see {FTE}} +\index{GFW|see {Great Firewall of China}} +\index{Google App Engine!zzz@\gobblecomma|seealso {meek-google}} +\index{Hypertext Transfer Protocol|see {HTTP}} +\index{injection|see {packet injection}} +\index{Microsoft Azure!zzz@\gobblecomma|seealso {meek-azure}} +\index{NDSS|see {Network and Distributed System Security Symposium}} +\index{OpenSSH|see {obfuscated-openssh}} +\index{PETS|see {Privacy Enhancing Technologies Symposium}} +\index{pluggable transports!zzz@\gobblecomma|seealso {flash proxy; FTE; meek; obfs2; obfs3; obfs4; ScrambleSuit; Snowflake}} +\index{Portable Document Format|see {PDF}} +\index{port scanning!zzz@\gobblecomma|seealso {active probing}} +\index{precision|see {false positives}} +\index{recall|see {false negatives}} +\index{SNI|see {Server Name Indication}} +\index{Secure Sockets Layer|see {TLS}} +\index{SSL|see {TLS}} +\index{TCP!flags|see {ACK; SYN; RST}} +\index{Transport Layer Security|see {TLS}} +\index{Transmission Control Protocol|see {TCP}} +\index{type~I error|see {false positive}} +\index{type~II error|see {false negative}} +\index{time to live|see {TTL}} +\index{User Datagram Protocol|see {UDP}} +\index{virtual private network|see {VPN}} +\index{VoIP|see {voice over IP}} +\index{relative entropy|see {Kullback--Leibler divergence}} +\index{reset|see {RST}} +\index{Secure Shell|see {SSH}} +\index{Uniform Resource Locator|see {URL}} +\index{U.S.|see {United States of America}} + +\index{Tor bridge!zzz@\gobblecomma|seealso {Azadi, cymrubridge31, cymrubridge33, fdctorbridge01, GreenBelt, JonbesheSabz, LeifEricson, Lisbeth, MaBishomarim, Mosaddegh, ndnop3, ndnop4, ndnop5, noether, NX01, riemann}} + + \begin{document} \begin{CJK}{UTF8}{gbsn} @@ -86,17 +182,14 @@ % https://tex.stackexchange.com/questions/18924/pdftex-warning-ext4-destination-with-the-same-identifier-nam-epage-1-has#comment35713_18927 \hypersetup{pageanchor=false} -% \include{frontmatter} +\include{frontmatter} -{\Large Draft of \today} \makeatletter -\renewcommand{\@oddfoot}{Draft of \today\hfill} +\renewcommand{\@oddfoot}{Draft of \today\hfill\url{https://www.bamsoftware.com/papers/thesis/}} \makeatother -\makeatletter -\@starttoc{toc} -\makeatother -% \tableofcontents +\setlength{\cftbeforetoctitleskip}{-.5em} +\tableofcontents \mainmatter @@ -122,23 +215,24 @@ \label{chap:intro} This is a thesis about Internet censorship. -In it, I will expand on two threads of research +Specifically, it is about +two threads of research that have occupied my attention for the past several years: -better understanding how censors work, +gaining a better understanding of how censors work, and fielding systems that circumvent their restrictions. -These two threads fuel each other: -better understanding censors -enables us to build better circumvention systems -that take into account their strengths and weaknesses; -and the deployment of a circumvention system +These two topics drive each other: +better understanding +leads to better circumvention systems +that take into account censors' strengths and weaknesses; +and the deployment of circumvention systems affords an opportunity to observe -how censors themselves react to changing circumstances. -If I am successful, the output of my research -is useful models that describe not only how censors -behave today but how they may evolve in the future, +how censors react to changing circumstances. +The output of my research takes two forms: +models that describe how censors +behave today and how they may evolve in the future, and tools for circumvention -that are not only sound in theory -but also effective in practice. +that are sound in theory +and effective in practice. % end of cat and mouse @@ -146,91 +240,98 @@ but also effective in practice. \section{Scope} -Censorship is an enormous topic. -Even the addition of the ``Internet'' qualifier -hardly reduces its scope, -because almost everything that might be censored -touches the Internet in some way. -To deal with the subject in depth, +\index{border firewall|(} + +Censorship is an enormous topic, +and Internet censorship is hardly smaller. +In order to deal with the subject in detail, it is necessary to limit the scope. -My research is focused on an +My research is on an important special case of censorship, -which I call the ``border firewall'' case. +which I~call the ``border firewall\index{border firewall}.'' It is illustrated in \autoref{fig:border-firewall}. \begin{figure} \centering -\includegraphics[width=3in]{figures/border-firewall} +\includegraphics{figures/border-firewall} \caption{ In the border firewall scenario, a client within a censor-controlled network -wants to reach a destination that lies outside the censor's control. +wants to reach a destination on the outside. +% The nodes and links remind use that there +% is a fabric of hardware beneath our network abstractions. } \label{fig:border-firewall} -\index{``border firewall'' scenario} +\index{border firewall} \end{figure} -A \emph{client} resides within a network +A~\emph{client} resides within a network that is entirely controlled by a \emph{censor}. -Within the censor's network, the censor may +Within the controlled network, the censor may observe, modify, inject, or block any communication along any link. -The censor, in particular, tries to prevent -some subset of communication with the wider Internet, -for instance by blocking certain keywords, network addresses, or protocols. The client's computer, however, is trustworthy and not controlled by the censor. -The client's goal is to communicate with some -\emph{destination} that lies outside the censor's network, -despite the censor's blocks: -we call this activity \emph{circumvention}. -Circumvention requires somehow safely traversing +The censor tries to prevent +some subset of the client's communication with the wider Internet, +for instance by blocking those that discuss certain topics, +that are destined to certain network addresses, or +that use certain protocols. +The client's goal is to +evade the censor's controls +and communicate with some +\emph{destination} that lies outside the censor's network; +successfully doing so is called \emph{circumvention}\index{circumvention|textbf}. +Circumvention means somehow safely traversing a hostile network, -eluding detection and blocking by the censor, -in order to reach a destination. -The censor does not control network links outside its own border; -it may of course send messages to the outside world, +eluding detection and blocking. +The censor does not control the network outside its border; +it may send messages to the outside world, but it cannot control them after they have traversed the border. This abstract model is a good starting point, -but the situation in practice is never so clear-cut. +but it is not the whole story. +We will have to adapt it to fit different situations, +sometimes relaxing and sometimes strengthening assumptions. For example, the censor may be weaker than assumed: -it may observe only the links at the border, not those wholly inside; -it may not be able to fully inspect every packet that flows on its network; +it may observe only the links that cross the border, not those that lie wholly inside; +it may not be able to fully inspect every packet; or there may be deficiencies or dysfunctions in its detection capabilities. Or the censor may be stronger: -perhaps it, while not fully controlling outside networks, -may influence their operators to discourage them from assisting in circumvention. +while not fully controlling outside networks, +it may perhaps exert outside influence to discourage +network operators from assisting in circumvention. The client may be limited, for technical or social reasons, in the software and hardware they can use. -The destination may knowingly cooperate with the client's circumvention, or may not. -There is no limit to the possible complications. +The destination may knowingly cooperate with the client's +circumvention effort, or may not. +There are many possible complications, +reflecting the messiness and diversity of dealing with real censors. Adjusting the basic model to reflect real-world actors' -motivations and capabilities is the heart of threat modeling, -one of the main topics of this thesis. -Depending on the situation, we will add to the list of assumptions. +motivations and capabilities is the heart of \emph{threat modeling}. In particular, what makes circumvention possible at all -is the censor's motivation to block only \emph{some} -of the incoming and outgoing traffic, and allow the rest to pass---this +is the censor's motivation to block only some, +but not all, +of the incoming and outgoing communications---this assumption will be a major focus of the next chapter. It is not hard to see how the border firewall model relates to censorship in practice. -In a common case, the censor is a national government, -and the borders of its controlled network correspond to -the borders of a country. +In a common case, the censor is the government of a country, +and the limits of its controlled network correspond to +the country's borders. A government typically has the power to enforce laws -and control network infrastructure to act -within its own borders, but not outside. -However the boundaries of censorship do not always correspond -exactly to the border of a country. -Almost since the study of Internet censorship began, -it has been recognized that content restrictions +and control network infrastructure +inside its borders, but not outside. +However this is not the only case: +the boundaries of censorship do not always correspond +to the border of a country. +Content restrictions may vary across geographic locations, -even within the same country -(Wright et~al.~\cite{Wright2011a} identified some possible causes). -In some places a better model is not a single unified censorship regime, -but rather many individual Internet service providers, -each controlling its own network and acting as a mini-censor, +even within the same country---Wright et~al.~\indexauthors{\cite{Wright2011a}} +identified some reasons why this might be. +A~good model for some places is not a single unified regime, +but rather several autonomous service providers, +each controlling and censoring its own portion of the network, perhaps coordinating with others about what to block and perhaps not. Another important case is that of a university or corporate network, in which the only outside network access is through a single gateway router, @@ -242,92 +343,93 @@ or the amount of computation they can afford to spend on each communication. % and the capabilities of commercial networking technology may presage % those of larger censors in the future. -Here are some examples of forms of censorship that are in scope: +\index{border firewall|)} + +Here are examples of forms of censorship that are in scope: \begin{itemize} -\item blocking IP addresses -\item blocking specific network protocols -\item blocking DNS resolution for certain domains -\item blocking keywords in URLs -\item dissecting network layers (``deep packet inspection'') +\item blocking IP addresses\index{blocking!by address} +\item blocking specific network protocols\index{blocking!by content} +\item blocking DNS resolution for certain domains\index{DNS!blocking}\index{blocking!by address} +\item blocking keywords in URLs\index{URL}\index{blocking!by content} +\item parsing application-layer data (``deep packet inspection'')\index{deep packet inspection} \item statistical and probabilistic traffic classification -\item connection speed throttling -\item active measures by censors to discover the use of circumvention +\item bandwidth throttling\index{throttling} +\item active scanning to discover the use of circumvention \end{itemize} -Other forms of censorship that are \emph{not} in scope include: +Some other censorship-related topics that are \emph{not} in scope include: \begin{itemize} -\item domain takedowns (that affect all clients globally) -\item server-side blocking (servers refusing to serve certain clients) +\item domain takedowns (affecting all clients globally) +\item server-side blocking (servers that refuse to serve certain clients) +\item forum moderation and deletion of social media posts \item anything that takes place entirely within the censor's network and does not cross the border -\item forum moderation and deletion of social media posts \item deletion-resistant publishing in the vein of - the Eternity Service~\cite{Anderson1996a} - (what Köpsell and Hillig call ``censorship resistant publishing systems''~\cite[\S 1]{Koepsell2004a}), + the Eternity Service~\cite{Anderson1996a}\index{Eternity Service, The} + (what Köpsell and Hillig call ``censorship resistant + publishing systems''~\indexauthors{\cite[\S 1]{Koepsell2004a}}), except insofar as access to such services may be blocked -% Dagster~\cite{Stubblefield2001a} -% Publius~\cite{Waldman2000a} -% Tangler~\cite{Waldman2001a} \end{itemize} -Many parts of the abstract model are deliberately +Parts of the abstract model are deliberately left unspecified, to allow for the many variations that arise in practice. The precise nature of ``blocking'' can take many forms, -from packet dropping, to injection of false responses, -and softer forms of disruption such as bandwidth throttling. -Detection need not be purely passive. -The censor is permitted to do work outside the context of a single connection; +from packet dropping\index{packet dropping}, to injection of false responses\index{packet injection}, +to softer forms of disruption such as bandwidth throttling\index{throttling}. +Detection does not have to be purely passive. +The censor may to do work outside the context of a single connection; for example, it may compute aggregate statistics over many connections, make lists of suspected IP addresses, and defer some analysis for offline processing. -The client may cooperate with other entities +The client may cooperate with other parties inside and outside the censor's network, and indeed almost all circumvention will require -the cooperation of a willing proxy on the outside. - -Some have objected to the use of the generic term -``Internet censorship''\index{``Internet censorship'' as a term} -to refer to the narrow case of the border firewall. -I am sensitive to this objection and acknowledge that +the assistance of a collaborator +on the outside. + +It is a fair criticism that the term +``Internet censorship''\index{Internet censorship@``Internet censorship''} +in the title overreaches, +given that I~am talking only about +one specific manifestation of censorship, +albeit an important one. +I~am sympathetic to this view, and I~acknowledge that far more topics could fit under the umbrella of Internet censorship. -Nevertheless, for the purpose of this thesis, -I will continue to use ``Internet censorship'' without further qualification -to refer to the border firewall case. +Nevertheless, for consistency and ease of exposition, +in this document I~will continue to use +``Internet censorship'' without further qualification +to mean the border firewall case. -\section{Context and overview} +\section{My background} -This thesis contains knowledge I~have collected -and research projects I have taken part in -over the last five years. +This document describes my research experience +from the past five years. The next chapter, ``\nameref{chap:principles},'' is the thesis of the thesis, -wherein I~lay out opinionated general principles -of the field. +in which I~lay out opinionated general principles +of the field of circumvention. The remaining chapters are split between -the topics of modeling and circumvention: -Chapters~\ref{chap:censor-modeling}--\ref{chap:proxy-probe} on censor modeling -and Chapters~\ref{chap:domain-fronting} and~\ref{chap:snowflake} on circumvention systems. +the topics of modeling and circumvention. One's point of view is colored by experience. I~will therefore briefly describe the background to my research. I~owe much of my experience to collaboration -with the Tor Project, +with the Tor Project\index{Tor Project, The}, producers of the Tor anonymity network. -Although Tor was not originally intended as a circumvention system, +whose anonymity network has been the vehicle for deployment +of my circumvention systems. +Although Tor\index{Tor} was not originally intended as a circumvention system, it has grown into one -thanks to pluggable transports, +thanks to \emph{pluggable transports}\index{pluggable transports}, a modularization system for circumvention implementations. -whose anonymity network has been the vehicle for deployment -of my circumvention systems, -as well as a common object of research. I~know a lot about Tor and pluggable transports, but I~have less experience (especially implementation experience) with other systems, particularly those -that are developed in a language other than English. +that are developed in languages other than English\index{English}. And while I~have plenty of operational experience---deploying and maintaining systems with real users---I~have not been in a situation where I~needed @@ -342,6 +444,8 @@ to circumvent regularly, as a user. % ss now has its own plugin system \end{itemize} +\index{detection!versus blocking} +\index{blocking!versus detection} In order to understand the challenges of circumvention, it helps to put yourself in the mindset of a censor. A censor has two high-level functions: detection and blocking. @@ -394,7 +498,7 @@ we can make the tradeoffs less favorable for the censor and more favorable for the circumventor. The censor may base its detection decision -on whatever criteria it find practical. +on whatever criteria it finds practical. I like to divide detection techniques into two classes: \emph{detection by content} and \emph{detection by address}. Detection by content is based on the content or topic @@ -402,7 +506,7 @@ of the message: keyword filtering and protocol identification fall into this class. Detection by address is based on the sender or recipient of the message: -IP address blacklists and DNS response tampering fall into this class. +IP address blacklists and DNS response tampering\index{DNS!poisoning} fall into this class. An ``address'' may be any kind of identifier: an IP address, a domain name, an email address. Of these two classes, my experience is that @@ -419,16 +523,16 @@ preventing direct access. Any communication between the client and the destination must therefore be indirect. The intermediary between client and destination -is called a \emph{proxy}, +is called a \emph{proxy}\index{proxy|textbf}, and it must do two things: provide an unblocked address for the client to contact; and somehow mask the contents of the channel and the eventual destination address. Throughout this thesis, I will use the word ``proxy'' with an abstract meaning of ``one that acts of behalf of another.'' -A proxy need not be what is typically understood by the term ``proxy server,'' +A~proxy need not be what is typically understood by the term ``proxy server,'' a single host accepting and forwarding connections. -A VPN (virtual private network) is also a kind of proxy, +A~VPN\index{VPN} (virtual private network) is also a kind of proxy, as is the Tor network, as may be a specially configured network router. In \autoref{chap:domain-fronting} we will see @@ -520,6 +624,8 @@ but as a time to work out growing pains. \section{Collateral damage} \label{sec:collateral-damage} +\index{collateral damage|(textbf} + What's to prevent the censor from shutting down all connectivity within its network, trivially preventing the client from reaching the destination? @@ -567,7 +673,7 @@ It may be reduced productivity, as workers are unable to access resources they need to to their job. This is the usual explanation for why the -Great Firewall of China has never blocked GitHub +Great Firewall of China has never blocked GitHub\index{GitHub} for long\todo{when and how long?}, despite GitHub's hosting and distribution of circumvention software: @@ -724,11 +830,13 @@ to make decisions that cause more harm than good. One might even say that the very decision to censor is exactly such an irrational decision, at the greater societal level. +\index{collateral damage|)} + \section{Content obfuscation strategies} \label{sec:obfuscation-strategies} -\index{blocking by content|(} +\index{detection!by content|(} \begin{itemize} \item Sony thing on passive/active detection \cite[\S 5.1]{SladekBroseEANTC} @@ -737,14 +845,15 @@ is exactly such an irrational decision, at the greater societal level. There are two general strategies to counter content-based blocking. The first is to mimic some content that the censor allows, -like HTTP or email. +like HTTP\index{HTTP} or email\index{email}. The second is to randomize the content, to make it dissimilar to anything that the censor specifically blocks. Tschantz et~al.~\cite{Tschantz2016a-local} call these two strategies -``steganography'' and ``polymorphism'' respectively. +``steganography''\index{steganography} and +``polymorphism''\index{polymorphism} respectively. Another way to say it is ``look like something'' -and ``look like nothing.'' +and ``look like nothing.''\index{look-like-nothing transport} They are not strict classifications---any real system will incorporate a bit of both---and they reflect differing conceptions of censors. @@ -758,6 +867,7 @@ but works against a ``blacklisting'' or ``default-allow'' censor, one that blocks a set of specifically enumerated protocols and allows all others. +\index{steganography|(} This is not to say that steganography is strictly superior to polymorphism---there are tradeoffs in both directions. Effective mimicry can be difficult to achieve, @@ -769,7 +879,7 @@ And just as obfuscation protocols are not purely steganographic or polymorphic, real censors are not purely whitelisting or blacklisting. Houmansadr et~al.~\cite{Houmansadr2013b} -exhibited weaknesses in ``parrot'' circumvention systems +exhibited weaknesses in ``parrot''\index{dead-parrot attacks} circumvention systems that mimic a cover protocol but do not perfectly imitate it. Mimicking a protocol in every detail, down to its error behavior, is difficult, and any inconsistency is a potential feature @@ -806,40 +916,43 @@ than mimicry. I will list some representative circumvention systems that exemplify the steganographic strategy. -Infranet~\cite{Feamster2002a}, way back in 2002, -built a covert channel out of HTTP, +Infranet~\cite{Feamster2002a}\index{Infranet}, way back in 2002, +built a covert channel out of HTTP\index{HTTP}, encoding upstream data in special requests and downstream data using standard steganography in image files. (An aside on the evolution of threat models: -the authors of Infranet rejected the possibility of using TLS (then called SSL), -because it was not then common enough that its wholesale blocking +the authors of Infranet rejected the possibility of using TLS\index{TLS}, +because TLS was not then common enough that its wholesale blocking would cause much damage. -Today the situation around TLS is much different, +Today the situation surrounding TLS is much different, and it is much relied on by circumventors.) -% Collage~\cite{Burnett2010a} -% Facade~\cite{Jones2014a} (2014) updates Infranet. +% Collage~\cite{Burnett2010a}\index{Collage} +% Facade~\cite{Jones2014a}\index{Facade} (2014) updates Infranet. StegoTorus~\cite{Weinberg2012a} (2012) uses custom encoders to make traffic resemble common HTTP file types, -such as PDF, JavaScript, and Flash. -SkypeMorph~\cite{Moghaddam2012a} (2012) mimics a Skype video call. -FreeWave~\cite{Houmansadr2013a} (2013) modulates a data stream -into an acoustic signal and transmits it over VoIP. -FTE~\cite{Dyer2013a} (for ``format-transforming encryption''; 2013) -and its followup Marionette~\cite{Dyer2015a} (2015) +such as PDF\index{PDF}, JavaScript\index{JavaScript}, and Flash\index{Flash}. +SkypeMorph~\cite{Moghaddam2012a}\index{SkypeMorph} (2012) mimics a Skype\index{Skype} video call. +FreeWave~\cite{Houmansadr2013a}\index{FreeWave} (2013) modulates a data stream +into an acoustic signal and transmits it over VoIP\index{voice over IP}. +FTE~\cite{Dyer2013a}\index{FTE} (for ``format-transforming encryption''; 2013) +and its followup Marionette~\cite{Dyer2015a}\index{Marionette} (2015) force traffic to conform to a user-specified syntax: if you can describe it, you can imitate it. Despite the research attention they have received, steganographic systems have not been as used in practice: of these listed systems, FTE is the only one that has seen substantial deployment. +\index{steganography|)} +\index{polymorphism|(} There are many examples of the randomized, polymorphic strategy. An important subclass of these are the so-called -look-like-nothing systems that encrypt a stream +look-like-nothing systems\index{look-like-nothing transport} that encrypt a stream without any plaintext header or framing information, so that it appears to be a uniformly random byte sequence. -A pioneering design was the obfuscated-openssh of Bruce Leidl~\cite{Leidl-obfuscated-openssh}, -which aimed to hide the plaintext packet metadata in the SSH protocol. +A pioneering design was the obfuscated-openssh\index{obfuscated-openssh} +of Bruce Leidl~\cite{Leidl-obfuscated-openssh}, +which aimed to hide the plaintext packet metadata in the SSH protocol\index{SSH}. obfuscated-openssh worked, in essence, by first sending a cryptographic key, then sending ciphertext encrypted with that key. @@ -851,13 +964,13 @@ situation partially mitigated by the use of an expensive key derivation function based on iterated hashing. obfuscated-openssh could optionally incorporate a pre-shared password into the key derivation function, which would prevent easy identification. -Dust~\cite{Wiley2011a}, a design by Brandon Wiley, +Dust\index{Dust}~\cite{Wiley2011a}, a design by Brandon Wiley, similarly randomized bytes (at least in its v1 version---later versions permitted fitting to distributions other than uniform). It was not susceptible to passive deobfuscation, relying on an out-of-band key exchange before each session. -Shadowsocks~\cite{Shadowsocks} +Shadowsocks~\cite{Shadowsocks}\index{Shadowsocks} is a lightweight encryption layer atop a simple proxy protocol. There is a line of successive look-like-nothing protocols---known by the names @@ -922,12 +1035,15 @@ not generated afresh for each connection. That means that even if a censor is able to build a profile for a particular server, it is not necessarily useful for detecting other server instances. +\index{polymorphism|(} -\index{blocking by content|)} +\index{detection!by content|)} \section{Address blocking resistance strategies} \label{sec:address-strategies} +\index{detection!by address|(} + \begin{itemize} \item VPN Gate ``collaborative spy detection''~\cite[\S 4.3]{Nobori2014a}, other ways of fingerprinting censor \item DEFIANCE~\cite{Lincoln2012a} @@ -995,7 +1111,7 @@ Both of these considerations pose challenges. Tor's blocking resistance design~\cite{tor-techreport-2006-11-001}, based on secret proxies called ``bridges,'' was of this kind. Volunteers run bridges, which report themselves to central database -called BridgeDB~\cite{BridgeDB}. +called BridgeDB~\cite{BridgeDB}\index{BridgeDB}. Clients contact BridgeDB through some unblocked out-of-band channel (HTTPS, email, or word of mouth) in order to learn bridge addresses. The BridgeDB server takes steps to prevent easy enumeration of the entire database~\cite{tor-bridgedb-spec}. @@ -1023,7 +1139,7 @@ presumably taking advantage of its greater resources. % I will cover this seeming paradox in more detail in % \autoref{chap:proxy-probe}.) -Tor relies on BridgeDB to provide address blocking resistance +Tor relies on BridgeDB\index{BridgeDB} to provide address blocking resistance for all its transports that otherwise only have content obfuscation. And that is a great strength of such a system. It enables, to some extent, content obfuscation to be developed independently, @@ -1057,7 +1173,7 @@ with the addresses of important servers, blocking which would result in high collateral damage. VPN Gate employed this idea~\cite[\S 4.2]{Nobori2014a}, mixing into the their public proxy list -the addresses of root DNS servers +the addresses of root DNS servers\index{DNS} and Windows Update servers. Apart from ``in-band'' discovery of bridges @@ -1085,7 +1201,7 @@ An alternative way of achieving address blocking resistance is to treat proxies as temporary and disposable, rather than permanent and valuable. This is the idea underlying -flash proxy~\cite{Fifield2012a-local} and Snowflake~\cite{snowflake-wiki}. +flash proxy~\cite{Fifield2012a-local} and Snowflake~\cite{snowflake-wiki}\index{Snowflake}. (Snowflake is the topic of \autoref{chap:snowflake}.) Even proxy distribution strategies that take churn into account have in mind proxies that last on the order of at least days. @@ -1093,7 +1209,7 @@ In contrast, disposable proxies may last only minutes or hours. Setting up a Tor bridge or even something lighter-weight like a SOCKS proxy still requires installing some software on a server somewhere. -Flash proxy and Snowflake proxies have a low set-up and tear-down cost: +Flash proxy and Snowflake\index{Snowflake} proxies have a low set-up and tear-down cost: you can run one just by visiting a web page. These designs do not to need a sophisticated proxy distribution strategy as long as the rate of proxy creation is kept higher than the censor's @@ -1117,7 +1233,7 @@ which redirects from its apparent destination to some other, covert destination. The censor has to induce routes that avoid the special routers~\cite{Schuchard2012a}, which is costly~\cite{Houmansadr2014a}. -Domain fronting~\cite{Fifield2015a-local} +Domain fronting~\cite{Fifield2015a-local}\index{domain fronting} has similar properties. Rather than a router, it uses another kind of network intermediary: a content delivery network. @@ -1160,9 +1276,13 @@ despite the use of address spoofing. % proxies only in one direction. % [no spoofing]. +\index{detection!by address|)} + \section{Spheres of influence and visibility} +\index{spheres of influence/visibility|(} + \begin{itemize} \item Deniable Liaisons~\cite{Narain2014a} \end{itemize} @@ -1180,18 +1300,18 @@ but not block it, Sometimes it is useful to consider this possibility when modeling. Khattak, Elahi, et~al.~\cite{Khattak2016a} express it nicely by subdividing the censor's network into a -\emph{sphere of influence}\index{sphere of influence (of a censor)} +\emph{sphere of influence} within which the censor has active control, -and a potentially larger \emph{sphere of visibility}\index{sphere of visibility (of a censor)} +and a potentially larger \emph{sphere of visibility} within which the censor may only observe, not act. A landmark example of this kind of thinking is the 2006 research on ``Ignoring the Great Firewall of China'' by Clayton et~al.~\cite{Clayton2006a}. -They found that the firewall would block connections by injecting -phony TCP RST\index{RST (TCP flag)} packets +They found that the firewall would block connections by injecting\index{packet injection} +phony TCP\index{TCP} RST\index{RST (TCP flag)} packets (which cause the connection to be torn down) -or SYN/ACK\index{SYN (TCP flag)}\index{ACK (TCP flag)}\index{SYN/ACK} packets +or SYN/ACK\index{SYN (TCP flag)}\index{ACK (TCP flag)}\index{SYN/ACK (TCP flags)} packets (which cause the client to become unsynchronized), and that simply ignoring the anomalous packets rendered blocking ineffective. @@ -1250,7 +1370,7 @@ conflicting goals of of sensitivity (recording all that is relevant) and selectivity (recording \emph{only} what is relevant) give rise to an unavoidable ``eavesdropper's dilemma.'' -% risks of flow blocking (Telex/TapDance~\cite{Frolov2017a}) +% risks of flow blocking (Telex/TapDance~\cite{Frolov2017a-local}) % http://www.icir.org/vern/papers/activemap-oak03.pdf % http://www.icir.org/vern/papers/norm-usenix-sec-01.pdf @@ -1263,16 +1383,16 @@ using IP fragmentation to prevent keyword matching (splitting keywords across fragments). In 2008 and 2009, Park and Crandall~\cite{Park2010a} explicitly characterized the Great Firewall as a network intrusion detection system -and found that a lack of TCP reassembly allowed evading keyword matching. +and found that a lack of TCP reassembly\index{TCP!reassembly} allowed evading keyword matching. Winter and Lindskog~\cite{Winter2012a} found that the Great Firewall still did not do TCP segment reassembly in 2012, in the course of studying the firewall's proxy-discovery probes. (Such probes are the subject of \autoref{chap:active-probing}.) They released a tool, brdgrd~\cite{brdgrd}, -that by manipulating the TCP window size, +that by manipulating the TCP window size\index{TCP!window size}, prevented the censor's scanners from receiving a full response in the first packet, thereby foiling active probing. -They reported that the tool stopped working in 2013. +They reported that the tool stopped working in 2013\cite[\S Software]{Winter2012a-webpage}. Anderson~\cite{Anderson2012splinternet} gave technical information on the implementation of the Great Firewall as it existed in 2012, and observed that it is implemented as an ``on-the-side'' monitor. @@ -1283,6 +1403,8 @@ identifying classes of working evasions and estimating the cost to counteract them. \todo{Your State is Not Mine~\cite{Wang2017a}} +\index{spheres of influence/visibility|)} + \section{Early censorship and circumvention} @@ -1314,7 +1436,7 @@ technology originally developed for personal firewalls. In the wake of the first signs of blocking by ISPs, % DFN/Radikal? people were thinking about how to bypass filters. The circumvention systems of that era were largely -HTML-rewriting web proxies: +HTML-rewriting web proxies\index{HTML-rewriting proxy}: essentially a form on a web page into which a client would enter a URL. The server would fetch the desired URL on behalf of the client, and before returning the response, rewrite all the links @@ -1336,7 +1458,7 @@ Circumvention designers deployed some countermeasures; for example Circumventor had a mailing list~\cite[\S 7.4]{tor-techreport-2006-11-001} which would send out fresh proxy addresses every few days. A 1996 article by Rich Morin~\cite{Morin1996Rover} -presented a prototype HTML-rewriting proxy called Rover, +presented a prototype HTML-rewriting proxy\index{HTML-rewriting proxy} called Rover, which eventually became CGIProxy. The article predicted the failure of censorship based on URL or IP address, @@ -1357,11 +1479,11 @@ censor capabilities. The first censors would be considered weak by today's standards, mostly easy to circumvent by simple countermeasures, -such as tweaking a protocol or using an alternative DNS server. +such as tweaking a protocol or using an alternative DNS server.\index{DNS} (We see the same progression play out again when countries begin to experiment with censorship, -such as in Turkey in 2014, where alternative DNS servers -briefly sufficed to circumvent a block of Twitter~\cite{theguardian-how-to-get-around-turkeys-twitter-ban}.) +such as in Turkey in 2014, where alternative DNS servers\index{DNS} +briefly sufficed to circumvent a block of Twitter~\cite{theguardian-how-to-get-around-turkeys-twitter-ban}.\index{DNS!blocking}) Not only censors were changing---the world around them was changing as well. In this field that is so heavily affected by concerns @@ -1374,7 +1496,7 @@ that TLS would not suffice as a cover protocol~\cite[\S 3.2]{Feamster2002a}, because the relatively few TLS-using services at that time could \emph{all} be blocked without much harm. Certainly the circumstances are different today---domain -fronting and all refraction networking schemes require +fronting\index{domain fronting} and all refraction networking schemes require the censor to permit TLS. As long as circumvention remains relevant, it will have to change along with changing times, @@ -1387,8 +1509,6 @@ just as censors do. % 'The "human shield" fallacy': seems to discount collateral damage, but then says 'the Chinese would probably never block [Web traffic and email], at least not without rendering the Internet essentially useless' % Also discounts possibility of SSL. -% \cite{dit-hj} first report on DNS hijacking? - \chapter{Understanding censors} \label{chap:censor-modeling} @@ -1424,9 +1544,10 @@ 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 control of default DNS servers\index{DNS} +\item blocking DNS queries\index{DNS!blocking} +\item injection of false DNS responses\index{DNS!poisoning} +\item injection of TCP\index{TCP} RSTs\index{RST (TCP flag)} \item pattern matching / keyword filtering \item application protocol parsing (``deep packet inspection'') \item participation in a circumvention system as a client @@ -1444,10 +1565,10 @@ 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 blunt instrument. -The Great Firewall of China, +The Great Firewall of China (GFW)\index{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 +There has indeed been more research focused on China\index{China} than any other country. But the GFW is in many ways an outlier, and not representative of other censors. @@ -1480,6 +1601,15 @@ A~worldwide view is needed. % In general, contemporary threat models tend to ignore % resource limitations on the part of the censor. +\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-local}. +Crandall et~al.\ ``Forgive Us our SYNs: Technical and Ethical Considerations for Measuring Internet Filtering''~\cite{Crandall2015a}. +} + \section{Censorship measurement studies} \label{sec:measurement-surveys} @@ -1515,7 +1645,7 @@ Aase et~al.\ ``Whiskey, Weed, and Wukan on the World Wide Web: On Measuring Cens 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}. +Dalek et~al.\ ``A Method for Identifying and Confirming the Use of URL Filtering Products for Censorship''~\cite{Dalek2013a-local}. 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}. @@ -1525,18 +1655,21 @@ Gwagwa ``A study of {Internet}-based information controls in {Rwanda}''~\cite{Gw \subsection*{One-shot studies} One of the earliest technical studies of censorship occurred -in a place you might not expect, in the German state of +in a place you might not expect, 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 +The most popular implementation used DNS tampering,\index{DNS!poisoning} +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 time period seems to be near the onset of DNS tampering in general; +Dong~\cite{Dong2002a} had reported it in China in late~2002. Clayton~\cite{Clayton2006b} in 2006 studied a ``hybrid'' blocking system, CleanFeed by the British ISP BT, @@ -1549,7 +1682,7 @@ 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. +return false DNS\index{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. @@ -1562,7 +1695,7 @@ 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 +caused the firewall to inject RST packets\index{RST (TCP flag)} towards both the client and server. Simply ignoring RST packets (on both ends) rendered the blocking mostly ineffective. @@ -1580,24 +1713,23 @@ or intrusion detection system, one that can passively monitor and inject packets, but cannot delay or drop them. -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. +Nearly contemporary studies by Wolfgarten~\cite{Wolfgarten2006a} +and Tokachu~\cite{Tokachu2006a} found cases of +DNS tampering, search engine filtering, and RST injection\index{RST (TCP flag)} +caused by keyword detection. +In 2007, Lowe, Winters, and Marcus~\cite{Lowe2007a} +did detailed experiments on DNS tampering in China.\index{DNS!poisoning} 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. +a whois lookup placed them in Australia, Canada, China, Hong Kong, and the U.S.\index{United States of America} 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, +of DNS tampering\index{DNS!poisoning} and injection occurred in 2014, giving remarkable insight into the internal structure of the censorship machines. DNS injection happens only at border routers. @@ -1618,20 +1750,20 @@ 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. +without a preceding SYN\index{SYN (TCP flag)} 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 +Injecting RST packets\index{RST (TCP flag)} into responses is more difficult than doing the same to requests, because of the greater uncertainty in predicting -TCP sequence numbers +TCP\index{TCP} sequence numbers once a session is well underway. -In fact, RST injection into responses was hit or miss, +In fact, RST injection\index{RST (TCP flag)} 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. +that it, one sent outside of an established TCP\index{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 @@ -1640,7 +1772,7 @@ 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. +triggered by an HTTP request outside an established TCP\index{TCP} connection. Much filtering occurs at smaller regional providers, rather than on the network backbone. @@ -1663,7 +1795,7 @@ 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. +DNS tampering\index{DNS!poisoning}, and throttling. The most usual method was HTTP request filtering. DNS tampering (directing to a blackhole IP address) affected only three domains: @@ -1675,7 +1807,7 @@ 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. +forcing TCP's\index{TCP} usual recovery. Khattak et~al.~\cite{Khattak2013a} evaluated the Great Firewall from the perspective that it works like @@ -1686,7 +1818,7 @@ 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 +The firewall is vulnerable to a variety of TCP-\index{TCP} and HTTP-based evasion techniques, such as overlapping fragments, TTL-limited packets, and URL encodings. @@ -1694,7 +1826,7 @@ 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; +Over half of the sites on the list were blocked by DNS tampering\index{DNS!poisoning}; less than 2\% were additionally blocked by HTTP filtering (an injected redirection before April 2013, or a static block page after that). @@ -1705,7 +1837,7 @@ 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 +The hybrid idle scan allows one to test TCP\index{TCP} connectivity between two Internet hosts, without needing to control either one. They selected roughly uniformly geographically distributed sites @@ -1720,7 +1852,7 @@ 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. +on Amazon CloudFront and GitHub\index{GitHub}. The unwitting participants in the attack were web browsers located outside of China, who began their attack when the cannon injected @@ -1783,8 +1915,8 @@ 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, +by injecting a TCP\index{TCP} RST packet\index{RST (TCP flag)} to tear down the connection, +then injecting a zero-sized TCP window\index{TCP!window size}, which would prevent any communication with the same server for a short time. Using technical tricks, the authors inferred @@ -1821,7 +1953,7 @@ 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, +18.2\% DNS tampering,\index{DNS!poisoning} 33.3\% IP address blocking, and 48.5\% HTTP keyword filtering. The system was not run on a continuing basis. @@ -1867,23 +1999,23 @@ 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, +Atlas allows 4 types of measurements: ping, traceroute, DNS resolution\index{DNS}, and X.509 certificate fetching. -Anderson et~al.~\cite{Anderson2014a} +Anderson et~al.~\cite{Anderson2014a-local} 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, +the authorities first poisoned DNS\index{DNS!poisoning} for twitter.com, +then blocked the IP addresses of the Google public DNS servers\index{DNS}, 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}. +Pearce et~al.\ ``Global Measurement of DNS Manipulation''~\cite{Pearce2017b-local}. } @@ -1950,447 +2082,554 @@ 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 +\index{active probing|(textbf} + +The Great Firewall of China\index{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. +are added to a blacklist\index{blocking!by address} +so that access to them will be blocked in the future. +The input to the active probing subsystem, a set of suspected addresses, +comes from passive observation\index{detection!by content} of the content of client connections. +The censor sees a client connect to a destination +and tries to determine, by content inspection, +what protocol is in use. +When the censor's content classifier is unsure +whether the protocol is a proxy protocol, +it passes the destination address to the active probing subsystem. +Active prober then checks, +by connecting to the destination, +whether it actually is a proxy. \autoref{fig:active-probing} illustrates the process. \begin{figure} \centering -\placeholder{2in} +\includegraphics{figures/active-probing} \caption{ The censor watches a connection between a client and a destination. -If content inspection does not definitively indicate a circumvention protocol, +If content inspection\index{detection!by content} does not definitively indicate +the use of 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. +the censor passes the destination's address to an active prober. +The active prober attempts connections using various proxy protocols. If any of the proxy connections succeeds, the censor adds the destination -to an address blacklist. +to an address blacklist\index{blocking!by address}. } \label{fig:active-probing} \end{figure} Active probing makes good sense for the censor, -whose main restriction is the risk of false-positive classifications -that result in collateral damage. -Any classifier based purely on passive content inspection +whose main restriction is the risk of false-positive\index{false positives} classifications +that result in collateral damage\index{collateral damage}. +Any classifier based purely on passive content inspection\index{detection!by content} must be very precise (have a low rate of false positives). -Active probing increases the precision, -by only blocking those servers determined through active inspection -to be proxies. -With active probing, -the censor can get away with a mediocre content-based classifier, -one that returns a rough superset of actual proxy connections, -because active probes will weed out any false positives it might have had. -The content-based classifier only has to reduce the total connections -to a small enough number that the active probing subsystem can handle them. -Another benefit, from the censor's point of view, -is that active probing can be run as a batch job, -separate from the the firewall's responsibilities that require +Active probing increases precision +by blocking only those servers that are determined, through active inspection, +to really be proxies. +The censor can get away with a mediocre content classifier---it +can return a superset +of the set of actual proxy connections, +and active probes will weed out its false positives. +A~further benefit of active probing, from the censor's point of view, +is that it can run asynchronously, +separate from the firewall's other responsibilities that require a low response time. +\index{port scanning|(} +\index{active probing!reactive vs.\ proactive|(} Active probing, as I~use the term in this chapter, -is distinguished by being reactive, +is distinguished from other types of active scans by being reactive, driven by observation of client connections. It is distinct from proactive, wide-scale port scanning, -in which a censor regularly scans likely ports on the Internet +in which a censor regularly scans likely ports across the Internet to find proxies, independent of client activity. The potential for the latter kind of scanning has been appreciated for over a decade. -Dingledine and Mathewson~\cite[\S 9.3]{tor-techreport-2006-11-001} -raised scanning resistance as an issue -in Tor's initial bridge design document. -McLachlan and Hopper~\cite[\S 3.2]{McLachlan2009a} -observed that the tendency of bridges to run on +Dingledine and Mathewson~\indexauthors{\cite[\S 9.3]{tor-techreport-2006-11-001}} +raised scanning resistance as a consideration +in the design document for Tor bridges\index{Tor bridges}. +McLachlan and Hopper~\indexauthors{\cite[\S 3.2]{McLachlan2009a}} +observed that the bridges' tendency to run on a handful of popular ports -would make them discoverable in an Internet-wide scan, -which they estimated would take weeks. -Dingledine~\cite[\S 6]{tor-techreport-2011-10-002} +would make them more discoverable in an Internet-wide scan, +which they estimated would take weeks using then-current technology. +Dingledine~\indexauthors{\cite[\S 6]{tor-techreport-2011-10-002}} mentioned indiscriminate scanning as one of ten ways to discover Tor -bridges---while also bringing up the possibility of active probing -in the sense of the present chapter, -then just beginning to be used by the Great Firewall. -Durumeric et~al.~\cite[\S 4.4]{Durumeric2013a} +bridges---while also bringing up the possibility of reactive probing +which the Great Firewall\index{Great Firewall of China} +was then just beginning to use. +Durumeric et~al.~\indexauthors{\cite[\S 4.4]{Durumeric2013a}} demonstrated the effectiveness of Internet-wide scanning, -discovering about 80\% of public bridges in a matter of hours, -targeting only two ports, 9001 and 443. -Tsyrklevich~\cite{tor-dev-internet-wide-bridge-scanning} and -Matic et~al.~\cite[\S V.D]{Matic2017a} -later showed how to existing public repositories of Internet scan data -could reveal many bridges, without even the necessity -of manually running a new scan. - -The Great Firewall of China is the only censor known +targeting only two ports to +discover about 80\% of public Tor bridges\index{Tor bridges} in only a few hours, +Tsyrklevich~\indexauthors{\cite{tor-dev-internet-wide-bridge-scanning}} and +Matic et~al.~\indexauthors{\cite[\S V.D]{Matic2017a}} +later showed how existing public repositories of Internet scan data +could reveal bridges, without even the necessity +of running one's own scan. +\index{active probing!reactive vs.\ proactive|)} +\index{port scanning|)} + +The Great Firewall of China\index{Great Firewall of China} +is the only censor known to employ active probing. -Its sophistication has increased over time, -with the addition of new protocols -and a reduction in the delay before new servers get probed. +It has increased in sophistication over time, +adding support for new protocols +and reducing the delay between a client's connection +and the sending of probes. The Great Firewall has the documented ability -to active-probe plain Tor and some of its pluggable transports, -certain VPN protocols, -as well as certain HTTPS-based proxies. -The probing takes place +to probe the plain Tor protocol\index{Tor!protocol} +and some of its pluggable transports\index{pluggable transports}, +as well as certain VPN protocols\index{VPN} +and certain HTTPS-based\index{HTTPS} proxies. +Probing takes place only seconds or minutes after a connection by a legitimate client, and the active-probing connections come from a large range of source IP addresses. The experimental results in this chapter -all have to do with China. +all have to do with China\index{China}. -Active probing lies somewhere in the middle of the dichotomy, +Active probing occupies a space somewhere in the middle of the dichotomy, put forward in \autoref{chap:principles}, -of blocking by content and blocking by address. -The censor's active probing subsystem takes -addresses as input and produces addresses as output -(to be added to a blacklist). +of detection by content\index{detection!by content} +and detection by address\index{detection!by address}. +An active probing system takes +suspected addresses as input and produces +to-be-blocked addresses as output\index{blocking!by address}. But it is content-based classification that -produces the list of input addresses. -Active probing only became an issue because -content obfuscation had gotten better: -if a censor could easily identify -circumvention protocols by passive inspection, -it would not go to the extra trouble of active probing. +produces the list of suspected addresses in the first place. +The existence of active probing is +The use of active probing is, in a sense, +a good sign for circumvention: it only became relevant +content obfuscation had gotten better. +If a censor could easily identify +the use of circumvention protocols +by mere passive inspection, +then it would not go to the extra trouble of active probing. Contemporary circumvention systems must be designed to resist active probing attacks. -The look-like-nothing systems -ScrambleSuit~\cite{Winter2013b}, -obfs4~\cite{obfs4}, -and Shadowsocks~\cite{Shadowsocks-AEAD,BlessingStudio-why-do-shadowsocks-deprecate-ota} -do it by having the proxy authenticate client connections, -using a per-proxy password or private key. -Domain fronting (\autoref{chap:domain-fronting}) -and Snowflake (\autoref{chap:snowflake}) -deal with active probing differently. +The strategy of the look-like-nothing systems\index{look-like-nothing transport} +ScrambleSuit~\cite{Winter2013b}\index{ScrambleSuit}, +obfs4~\cite{obfs4}\index{obfs4}, +and Shadowsocks~\cite{Shadowsocks-AEAD,BlessingStudio-why-do-shadowsocks-deprecate-ota}\index{Shadowsocks} +is to authenticate\index{authentication} clients +using a per-proxy password or public key; +i.e., to require some additional secret information +beyond just an IP address and port number. +Domain fronting\index{domain fronting} (\autoref{chap:domain-fronting}) +deals with active probing by co-locating proxies +with important web services: +the censor can tell that circumvention is taking place +but cannot block the proxy without unacceptable collateral damage\index{collateral damage}. +In Snowflake\index{Snowflake} (\autoref{chap:snowflake}), +proxies are web browsers running ordinary peer-to-peer protocols, +authenticated using a per-connection shared secret. +Even if a censor discovers one of Snowflake's proxies, +it cannot verify that the proxy is running Snowflake or something else, +without having first negotiated a shared secret +through Snowflake's broker\index{Snowflake!broker} mechanism.\index{Snowflake!rendezvous} \section{History of active probing research} -Active probing research has primarily -had to do with Tor and its pluggable transports. -There is also some work on Shadowsocks. +Active probing research has mainly +focused on Tor\index{Tor!protocol} +and its pluggable transports\index{pluggable transports}. +There is also some work on Shadowsocks\index{Shadowsocks}. \autoref{tab:active-probing-timeline} -summarizes the research of this section. +summarizes the research covered in this section. \begin{table} +\centering \begin{tabular}{lp{5 in}} 2010 August & -Nixon notices strange, random-looking connections from China in his SSH logs~\cite{Nixon-sshprobes}. +Nixon notices unusual, random-looking connections from China\index{China} in SSH\index{SSH} logs~\indexauthors{\cite{Nixon-sshprobes}}. \\ 2011 May--June & Nixon's random-looking probes are temporarily replaced -by TLS probes before changing back again~\cite{Nixon-sshprobes}. +by TLS\index{TLS} probes before changing back again~\indexauthors{\cite{Nixon-sshprobes}}. \\ 2011 October & -hrimfaxi reports that Tor bridges are quickly detected by the GFW~\cite{tor-trac-4185}. +hrimfaxi\index{hrimfaxi} reports that Tor bridges\index{Tor bridges} are quickly detected by the GFW~\cite{tor-trac-4185}\index{Great Firewall of China}. \\ 2011 November & -Nixon publishes observations and hypotheses about the strange SSH connections~\cite{Nixon-sshprobes}. +Nixon publishes observations and hypotheses about the strange SSH connections~\indexauthors{\cite{Nixon-sshprobes}}. \\ 2011 December & -Tim Wilde investigates Tor probing~\cite{WildeGFW,tor-blog-knock-knock-knockin-bridges-doors,tor-trac-4744}. -He finds two kinds of probe: ``garbage'' random probes +Wilde\index{Wilde, Tim} investigates Tor probing\index{Tor!protocol}~\cite{WildeGFW,tor-blog-knock-knock-knockin-bridges-doors,tor-trac-4744}. +He finds two kinds of probe: ``garbage'' random probes\index{garbage probes} and Tor-specific ones. \\ 2012 February & -The obfs2 transport becomes available~\cite{tor-blog-obfsproxy-next-step-censorship-arms-race}. -The Great Firewall is initially unable to active-probe it. +The obfs2\index{obfs2} transport becomes available~\cite{tor-blog-obfsproxy-next-step-censorship-arms-race}. +The Great Firewall is initially unable to probe for it. \\ 2012 March & -Winter and Lindskog investigate Tor probing in detail~\cite{Winter2012a}. +Winter and Lindskog investigate Tor probing in detail~\indexauthors{\cite{Winter2012a}}. \\ 2013 January & The Great Firewall begins to active-probe obfs2~\cites{tor-trac-8591}[\S 4.3]{Ensafi2015b}. -The obfs3 transport becomes available~\cite{tor-blog-combined-flash-proxy-pyobfsproxy-browser-bundles}. +The obfs3\index{obfs3} transport becomes available~\cite{tor-blog-combined-flash-proxy-pyobfsproxy-browser-bundles}. \\ 2013 June--July & Majkowski observes TLS and garbage probes -and identifies fingerprintable features of the probers~\cite{Majkowski-fun-with-the-great-firewall}. +and identifies fingerprintable features of the probers~\indexauthors{\cite{Majkowski-fun-with-the-great-firewall}}. \\ 2013 August & The Great Firewall begins to active-probe obfs3~\cite[Figure~8]{Ensafi2015b}. \\ 2014 August & -The ScrambleSuit transport (resistant to active probing) +The ScrambleSuit\index{ScrambleSuit} transport, which is resistant to active probing, becomes available~\cite{tor-blog-tor-browser-40-released}. \\ 2015 April & -The obfs4 transport (resistant to active probing) +The obfs4\index{obfs4} transport (resistant to active probing) 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}. +BreakWa11\index{BreakWa11} discovers an active-probing vulnerability in +Shadowsocks\index{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 +Ensafi et~al.~\indexauthors{\cite{Ensafi2015b}} publish results of multi-modal experiments on active probing. \\ 2017 February & -Shadowsocks changes its protocol against active probing~\cite{github-shadowsocks-org-issue-42}. +Shadowsocks\index{Shadowsocks} changes its protocol to better resist active probing~\cite{github-shadowsocks-org-issue-42}. \end{tabular} \caption{ -Timeline of active probing research. +Timeline of research on active probing. } \label{tab:active-probing-timeline} \end{table} -Nixon~\cite{Nixon-sshprobes} in late 2011 published -an analysis of suspicious connections from IP addresses in China -that his servers had been receiving for a year. -The connections were to the SSH port, but did not follow the SSH protocol; +Nixon~\indexauthors{\cite{Nixon-sshprobes}} published in late 2011 +an analysis of suspicious connections from IP addresses in China\index{China} +that his servers had at that point been receiving for a year. +The connections were to the SSH\index{SSH} port, but did not follow the SSH protocol; rather they contained apparently random bytes, resulting in error messages in the log file. -Nixon discovered a pattern: the random-looking probes +Nixon discovered a pattern: the random-looking ``garbage'' probes\index{garbage probes} were preceded, at an interval of 5--20 seconds, -by a legitimate SSH login from some other IP address in China. +by a legitimate SSH login from some other IP address in China\index{China}. The same pattern was repeated at three other sites. Nixon supposed that the probes were triggered by legitimate SSH users, as their connections traversed the firewall; and that the random payloads were a simple form of service identification, -sending non-protocol-conforming data to see how the server would respond. +sent only to see how the server would respond to them. For a few weeks in May and June 2011, -the probes did not look random, but looked like TLS. +the probes did not look random, but instead looked like TLS\index{TLS}. -In October 2011, Tor user hrimfaxi reported that -a newly set up, unpublished Tor bridge -would be blocked within 10~minutes of first +In October 2011, Tor user hrimfaxi\index{hrimfaxi} reported that +a newly set up, unpublished Tor bridge\index{Tor bridges} +would be blocked within 10~minutes of their first being accessed from China~\cite{tor-trac-4185}. -Moving the bridge's address to another port +Moving the bridge to another port on the same IP address would work temporarily, -but then be blocked again before another 10~minutes. -Wilde systematically investigated the phenomenon and +but the new address would also be blocked within another 10~minutes. +Wilde systematically investigated the phenomenon +in December 2011 and published an extensive analysis -of active probing behavior caused by -making a connection from inside China to outside~\cite{WildeGFW,tor-blog-knock-knock-knockin-bridges-doors}. +of active probing that was triggered by +connections from inside China\index{China} to outside~\indexauthors{\cite{WildeGFW,tor-blog-knock-knock-knockin-bridges-doors}}. There were two kinds of probes: -``garbage'' random probes like those Nixon had described, -and specialized Tor probes that established a TLS session -and inside the session sent the Tor protocol. -The garbage probes were sent in response -to TLS connections to port 443 only, -and followed the triggering connection within moments. -The Tor probes were sent in response -to TLS connections on any port that shared -characteristics with Tor's client handshake~\cite{tor-trac-4744}, -and were not sent immediately, -but batched to the next quarter hour. -The probes came from diverse IP addresses in China: +``garbage''\index{garbage probes} random probes like those Nixon had described, +and specialized Tor probes that established a TLS\index{TLS} session +and inside the session sent the Tor protocol\index{Tor!protocol}. +The garbage probes were triggered by +TLS connections to port 443, +and were sent immediately following the original connection. +The Tor probes, in contrast, were triggered +by TLS connections to any port, +as long as the TLS client handshake matched\index{TLS!fingerprinting} +that of Tor's implementation\index{Tor!protocol}~\cite{tor-trac-4744}. +The Tor probes were not sent immediately, +but in batches of 15~minutes. +The probes came from diverse IP addresses in China\index{China}: 20 different /8 networks~\cite{WildeProberIPs}. -Bridges using the obfs2 transport were +Bridges using the obfs2\index{obfs2} transport were, +at that time, neither probed nor blocked. Winter and Lindskog revisited the question of Tor probing -a few months later in 2012~\cite{Winter2012a}. -They used open proxies and a VPS in China -to reach bridges and relays in Russia, Singapore, and Sweden -(configured so that ordinary users would not -connect to them by accident). -They confirmed Wilde's finding that the blocking +a few months later in 2012~\indexauthors{\cite{Winter2012a}}. +They used open proxies\index{open proxy} and a server in China\index{China} +to reach bridges and relays in Russia\index{Russia}, Singapore\index{Singapore}, and Sweden\index{Sweden}. +The bridges and relays were configured so that ordinary users would not +connect to them by accident. +They confirmed Wilde's\index{Wilde, Tim} finding that the blocking of one port did not affect other ports on the same IP address. -Blocks expired after 12 hours. +Blocked ports became reachable again 12 hours. By simulating multiple Tor connections, -they collected over 3,000 active probe samples in 17~days +they collected over 3,000 active probe samples in 17~days. During that time, there were about 72 hours which where mysteriously free of active probing. Half of the probes came from a single IP address, 202.108.181.70\index{202.108.181.70 (active prober)}; the other half were almost all unique. -Reverse-scanning the source IP addresses of probes -after a few minutes sometimes found a live host, -though usually with a different IP TTL than +Reverse-scanning the probes' source IP addresses, +a few minutes after the probes were received, +sometimes found a live host, +though usually with a different IP TTL\index{TTL} than was used during the probing, -which the authors suggest may be a sign of +which the authors suggested may be a sign of address spoofing by the probing infrastructure. % diurnal pattern in scanning delay -Because probing was triggered by patterns in the TLS client handshake, +Because probing was triggered by patterns in the TLS client handshake\index{TLS!fingerprinting}, they developed a server-side tool, brdgrd~\cite{brdgrd}\index{brdgrd}, -that rewrote the TCP window so that -the client's handshake would be split across packets. -The tool sufficed, at the time, to prevent active probing. +that rewrote the TCP window\index{TCP!window size} so that +the client's handshake would be split across packets\index{fragmentation}. +The tool sufficed, at the time, to prevent active probing, +but the authors reported that it stopped working in 2013\indexauthors{\cite[\S Software]{Winter2012a-webpage}}. -The obfs2 pluggable transport, +The obfs2\index{obfs2} pluggable transport, first available in February 2012~\cite{tor-blog-obfsproxy-next-step-censorship-arms-race}, worked against active probing for about a year. -The first report of its active probing arrived in March~2013~\cite{tor-trac-8591}. -By analyzing the logs of my web server, -I~found evidence for an even earlier onset: -January~2013~\cite[\S 4.3]{Ensafi2015b}. +The first report of its being probing arrived in March~2013~\cite{tor-trac-8591}. +I~found evidence for an even earlier onset, +in January 2013, +by analyzing the logs of my web server~\cite[\S 4.3]{Ensafi2015b}. At about the same time, -the obfs3 pluggable transport became available~\cite{tor-blog-combined-flash-proxy-pyobfsproxy-browser-bundles}. -It was as vulnerable to active probing as obfs2 was, -but the firewall did not gain the ability -to active-probe it until August~2013~\cite[Figure~8]{Ensafi2015b}. +the obfs3\index{obfs3} pluggable transport became available~\cite{tor-blog-combined-flash-proxy-pyobfsproxy-browser-bundles}. +It was, in principle, as vulnerable to active probing as obfs2\index{obfs2} was, +but the firewall\index{Great Firewall of China} did not gain the ability +to probe for it until August~2013~\cite[Figure~8]{Ensafi2015b}. -Majkowski~\cite{Majkowski-fun-with-the-great-firewall} -observed a change in active-probing behavior +Majkowski~\indexauthors{\cite{Majkowski-fun-with-the-great-firewall}} +documented a change in active-probing behavior between June and July~2013. In June, he reproduced the observations -of Winter and Lindskog, -eliciting pairs of TLS probes, -one from +of Winter\index{Winter, Philipp} and Lindskog\index{Lindskog, Stefan}: +pairs of TLS\index{TLS} probes, one from 202.108.181.70\index{202.108.181.70 (active prober)} -and one from another IP address. -He also provided TLS fingerprints for the probers, -which were distinct from the fingerprints of ordinary Tor clients. +and one from some other IP address. +He also provided TLS fingerprints\index{TLS!fingerprinting} for the probers, +which were distinct from the fingerprints of ordinary Tor\index{Tor} clients. In July, he began to see pairs of probes with apparently random contents, -like the garbage probes Wilde described. -The TLS fingerprints of probes in July +like the garbage probes\index{garbage probes} Wilde\index{Wilde, Tim} described. +The TLS fingerprints of the July probes differed from those seen earlier, -but were still identifiable. +but were still distinctive. -The ScrambleSuit transport, +The ScrambleSuit\index{ScrambleSuit} transport, designed to be immune to active-probing attacks, -first shipped with Tor Browser~4.0 +first shipped with Tor Browser~4.0\index{Tor Browser} in October~2014~\cite{tor-blog-tor-browser-40-released}. -The successor transport obfs4, similarly immune, -shipped in Tor Browser~4.5 in +The successor transport obfs4\index{obfs4}, similarly immune, +shipped in Tor Browser~4.5\index{Tor Browser} in April 2015~\cite{tor-blog-tor-browser-45-released}. In August 2015, -developer BreakWa11 described an active-probing vulnerability -in the Shadowsocks protocol~\cites{github-shadowsocks-rss-issue-38}[\S 2]{BlessingStudio-why-do-shadowsocks-deprecate-ota}. -The flaw had to do with a lack of authentication of ciphertext, -allowing a prober to introduce errors and watch -how the server responds. -The Shadowsocks developers deployed a modified protocol, -a stopgap measure that proved to have its own vulnerabilities to probing. -Shadowsocks deployed another protocol change in -February~2017 fixing the problem~\cite{github-shadowsocks-org-issue-42}. +developer BreakWa11\index{BreakWa11} described an active-probing vulnerability +in the Shadowsocks\index{Shadowsocks} protocol~\cites{github-shadowsocks-rss-issue-38}[\S 2]{BlessingStudio-why-do-shadowsocks-deprecate-ota}. +The flaw had to do with a lack of integrity protection\index{integrity}, +allowing a prober to introduce errors into ciphertext and watch +the server's reaction. +As a stopgap, the Shadowsocks developers deployed protocol modifications +that proved to have separate vulnerabilities to probing. +They deployed another protocol change in +February~2017, adding cryptographic integrity protection +and fixing the problem~\cite{github-shadowsocks-org-issue-42}. Despite the long window of vulnerability, -there is no evidence that the Great Firewall -tried to active-probe Shadowsocks servers~\cite{ProgramThink-comment1508314948860}. +there is no evidence that the Great Firewall\index{Great Firewall of China} +tried to active-probe Shadowsocks servers. -Ensafi et~al. (including me)~\cite{Ensafi2015b} did the largest +Ensafi et~al. (including me)~\indexauthors{\cite{Ensafi2015b}} did the largest controlled study of active probing to date throughout early 2015. We collected data from a variety of sources: a private network of our own bridges, isolated so that only we and active probers would connect to them; induced intensive probing of a single bridge -over a short time period, in the manner of Winter and Lindskog; +over a short time period, in the manner of Winter\index{Winter, Philipp} and Lindskog\index{Lindskog, Stefan}; analysis of server log files going back to 2010; -and back-scanning active prober source IP addresses -using tools such as ping, traceroute, and Nmap\index{Nmap}. +and reverse-scanning active prober source IP addresses +using tools such as ping\index{ping}, traceroute\index{traceroute}, and Nmap\index{Nmap}. Using these sources of data, we investigated many aspects of active probing, -such as the types of probes the firewall is capable of sending, +such as the types of probes the firewall was capable of sending, the probers' source addresses, -and potentially fingerprintable peculiarities of the probers' -implementation of protocols. +and potentially fingerprintable\index{fingerprinting} +peculiarities of the probers' +protocol implementations. Observations from this research project appear in the remaining sections of this chapter. \section{Types of probes} -Our experiments confirmed the existence of certain probe types -that had been documented in previous research, -and other types that had not been previously documented. -Of the probe types that had been documented before, -our observations were mostly consistent, -with some differences in the details. -Our research found, at varying times, these kinds of probes: +Our experiments confirmed the existence of known probe types +from prior research, +and new types that had not been documented before. +Our observations of the known probe types +were consistent with previous reports, +with only minor differences in some details. +We found, at varying times, these kinds of probes: \begin{description} \item[Tor] -We expected to find probing for Tor, and so we did. +We found probing of the Tor protocol\index{Tor!protocol}, +as expected. The probes we observed in 2015, however, -differed from those Wilde described in 2011: -ours had a lighter-weight check inside the TLS layer -that did not require building a circuit. -Also, in contrast to what Winter and Lindskog found in 2012, -our Tor probes were sent seconds after a connection, -no longer batched to a multiple of 15~minutes. +differed from those Wilde\index{Wilde, Tim} described in 2011, +which proceeded as far as building a circuit. +The ones we saw used less of the Tor protocol: +after the TLS\index{TLS} handshake they only +queried the server's version and disconnected. +Also, in contrast to what Winter\index{Winter, Philipp} +and Lindskog\index{Lindskog, Stefan} found in 2012, +the probes were sent immediately after a connection, +not batched to a multiple of 15~minutes. \item[obfs2] -The obfs2 protocol has a weakness that makes it trivial to identify, -passively or retroactively, -as long as you have at least the first 20 bytes sent by the client. -We turned the weakness to our advantage. -The ready identifiability of obfs2 allowed us to distinguish it -from other random-looking contents and -isolate a set of connections that -could only belong to legitimate circumventors or active probers. +The obfs2\index{obfs2} protocol +is meant to look like a random stream\index{look-like-nothing transports}, +but it has a weakness that makes it trivial to identify, +passively and retroactively\index{detection!by content}, +needing only the first 20 bytes sent by the client. +We turned the weakness of obfs2 to our advantage. +It allowed us to distinguish obfs2 from other +random-looking payloads, +isolating a set of connections that +could belong only to legitimate circumventors or to active probers. \item[obfs3] -Unlike obfs2, the obfs3 protocol is not easily identified passively, -except by general characteristics like its random payloads -and certain bounds on message sizes during the initial handshake. -In certain of our experiments, we were running an obfs3 server +The obfs3\index{obfs3} protocol is also meant +to look like a random stream\index{look-like-nothing transports}; +but unlike obfs2\index{obfs2}, it is not trivially identifiable passively. +It is not possible to retroactively recognize +obfs3 connections (from, say, a packet capture) with certainty: +sure classification requires active participation in the protocol. +In some of our experiments, we ran an obfs3 server that was able to participate in the handshake and so confirm -that what was being sent was really obfs3. -In others, such as the passive log analysis, we called ``obfs3'' -those probes that looked random and were not obfs2. +that the protocol really was obfs3. +In the passive log analysis, we labeled ``obfs3'' +any probes that looked random but were not obfs2. \item[SoftEther] -We were initially only looking for Tor-related active probing, -but in the process we inadvertently found other kinds of probes. -One of these was an HTTPS request, -``\texttt{POST /vpnsvc/connect.cgi HTTP/1.1}'', -which resembles the client handshake of the SoftEther VPN software -that underlies the VPN Gate circumvention system~\cite{Nobori2014a}. +We unexpectedly found evidence of probe types +other than Tor-related ones. +One of these was an HTTPS request: +\begin{verbatim} +POST /vpnsvc/connect.cgi HTTP/1.1 +Connection: Keep-Alive +Content-Length: 1972 +Content-Type: image/jpeg + +GIF89a... +\end{verbatim} +\index{HTTP} +\index{HTTPS} +\index{POST (HTTP method)} +\index{Connection (HTTP header)} +\index{Content-Length (HTTP header)} +\index{Content-Type (HTTP header)} +Both the path ``/vpnsvc/connect.cgi'', +and the body being a GIF\index{GIF} image despite having +a Content-Type\index{Content-Type (HTTP header)} +of ``image/jpeg''\index{JPEG}, +are characteristic of the client handshake of the SoftEther VPN software\index{SoftEther VPN} +that underlies the VPN Gate\index{VPN Gate} circumvention system~\cite{Nobori2014a}. \item[AppSpot] -This type of probe is an HTTPS request, +This type of probe is an HTTPS\index{HTTPS} request: +{ +\small \begin{verbatim} GET / HTTP/1.1 +Accept-Encoding: identity +Connection: close Host: webncsproxyXX.appspot.com +Accept: */* +User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like + Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36 \end{verbatim} +} +\index{HTTP} +\index{GET (HTTP method)} +\index{Accept-Encoding (HTTP header)} +\index{Connection (HTTP header)} +\index{Host (HTTP header)} +\index{Accept (HTTP header)} +\index{User-Agent (HTTP header)} +\index{Chrome web browser} +\index{Safari web browser} where the `\texttt{XX}' is a number that varies. The intent of this probe seems to be the discovery -of servers that are capable of domain-fronting for Google services. +of servers that are capable of domain fronting\index{domain fronting} for Google\index{Google} services, +including Google App Engine\index{Google App Engine}, which runs at \nolinkurl{appspot.com}. +% \cite[Table~2(a)]{Anonymous2014a} has "appspot.com" as a top-10 DNS poisoning pattern. (See \autoref{chap:domain-fronting} for more on domain fronting.) At one time, there were simple proxies running at -\nolinkurl{webncsproxyXX.appspot.com}. +\nolinkurl{webncsproxyXX.appspot.com}\index{Google App Engine}. \item[urllib] -\todo[inline]{describe; this one is new since the 2015 paper} +This probe type is new since our 2015 paper. +I~discovered it while re-analyzing my server logs +in order to update \autoref{fig:active-probing-http}. +It is a particular request that was sent over both +HTTP\index{HTTP} and HTTPS\index{HTTPS}: +\begin{verbatim} +GET / HTTP/1.1 +Accept-Encoding: identity +Host: 69.164.193.231 +Connection: close +User-Agent: Python-urllib/2.7 +\end{verbatim} +\index{GET (HTTP method)} +\index{Accept-Encoding (HTTP header)} +\index{Host (HTTP header)} +\index{Connection (HTTP header)} +\index{User-Agent (HTTP header)} +\index{Python} +The urllib\index{urllib} requests are unremarkable except for having been sent +from an IP address that at some other time send another kind +of active probe. +The User-Agent ``Python-urllib/2.7'' +and appears many other places in my logs, +not in an active probing context. +I~cannot guess what the purpose of this probe type may be, +except to observe that Nobori and Shinjo also +caught a ``Python-urllib'' client scraping +the VPN Gate\index{VPN Gate} server list~\cite[\S 6.3]{Nobori2014a}. \end{description} -This is not an exhaustive list of the Great Firewall's -active probing capability; -these are just the probes we were able to document comprehensively. -The purpose of the random ``garbage'' probes that Nixon and Wilde -had described is still not known; -they were not obfs2 and were too early to be obfs3, -so they must have been something else. +These probe types are not necessarily exhaustive. +The purpose of the random ``garbage'' probes\index{garbage probes} +is still not known; +they were not obfs2\index{obfs2} and were too early to be obfs3\index{obfs3}, +so they must have had some other purpose. \begin{figure} \centering \includegraphics{figures/active-probing-http} \caption{ Active probes received at my web server +(ports 80 and~443)\index{HTTP}\index{HTTPS} over five years. This is an updated version of Figure~8 -from the paper ``Examining How the Great Firewall +from the paper ``Examining How the Great Firewall\index{Great Firewall of China} Discovers Hidden Circumvention Servers''~\cite{Ensafi2015b}; the vertical blue stripe divides old and new data. The ``short'' probes are those that looked random but did not provide enough data (20~bytes) -for the obfs2 test; it is likely that they, -along with the ``empty'' probes, are really obfs2, obfs3, or Tor probes -that were truncated at the first -`\textbackslash 0' or `\textbackslash n' byte. -\todo[inline]{urllib} +for the obfs2\index{obfs2} test; it is likely that they, +along with the ``empty'' probes, +are really truncated obfs2\index{obfs2}, obfs3\index{obfs3}, or Tor\index{Tor!protocol} probes. +The traffic from the IP addresses represented in this chart +was overwhelmingly composed of active probes, +but there were also 97~of what looked like genuine client browser requests. Active probing activity---at least against this server---has subsided since 2016. } @@ -2399,31 +2638,33 @@ subsided since 2016. Most of our experiments were designed around exploring known Tor-related probe types: -plain Tor (without pluggable transports), obfs2, and obfs3. +plain Tor\index{Tor!protocol}, obfs2\index{obfs2}, and obfs3\index{obfs3}. The server log analysis, however, unexpectedly turned up the other probe types. The server log data set consisted of application-layer logs -from my personal web/mail server, -which was also a Tor bridge. -Application-layer logs lack much of the fidelity you would want +from my personal web and mail\index{email} server, +which was also a Tor bridge\index{Tor bridge}. +Application-layer logs lack much of the fidelity you would normally want in a measurement experiment; they do not have precise timestamps or transport-layer headers, for example, and web server logs truncate the client's payload -at a `\textbackslash 0' or `\textbackslash n' byte. -But they make up for all that with time coverage. +at the first `\textbackslash 0' or `\textbackslash n' byte. +But they make up for that with time coverage. \autoref{fig:active-probing-http} shows the history of probes received at my server since 2013 (there were no probes before that, though the logs go back to 2010). -We started by searching the logs for likely probes: -those that passed the obfs2 test or otherwise looked like random garbage. -Then we looked at what else appeared in the logs -for the IP addresses that had sent the certain probes. +We began by searching the logs for definite probes: +those that were classifiable as obfs2\index{obfs2} +or otherwise looked like random garbage\index{garbage probes}. +Then we looked for what else appeared in the logs +for the IP addresses that had, at any time, sent a probe. In a small fraction of cases, the other logs lines -appeared to be genuine HTTP requests from legitimate clients; +appeared to be genuine HTTP\index{HTTP} requests from legitimate clients; but usually they were other probe-like payloads. We continued this process, adding new classifiers -for likely probes, until reaching a fixed point. +for likely probes, until reaching a fixed point +with the probe types described above. \section{Probing infrastructure} \label{sec:active-probing-infrastructure} @@ -2432,129 +2673,150 @@ for likely probes, until reaching a fixed point. \centering \includegraphics{figures/active-probing-tsval} \caption{ -TCP timestamp values from active probes. +TCP timestamp\index{TCP!timestamps} values of active probes. +A~TCP timestamp +is a 32-bit counter that increases +at a constant rate~\cite[\S 5.4]{rfc7323}; +a sequence of timestamps is characterized +by its rate and starting offset. % figures/active-probing.R: % Total number of probes in http_tcpdump and https_tcpdump: 4239 % Number of unique IP addresses in http_tcpdump and https_tcpdump: 3797 -Depicted are 4,239 probes from 3,797 distinct source IP addresses, -sharing however only a few TCP timestamp sequences. -The shaded area -{\color{gray!60}\rule{1em}{1em}} +There are 4,239 probes from 3,797 different source IP addresses +depicted in the graph; +however there are only a few distinct TCP timestamp sequences. +There are three rates of +increase (different slopes): 100~Hz, 200~Hz, and 1,000~Hz. +The shaded area~{\color{lightgray!60}\rule{0.9em}{0.9em}} marks a gap in packet capture. } \label{fig:active-probing-tsval} \end{figure} -The most salient feature of active probes, -when considered all together, +The most striking feature of active probes is the large number of source addresses -from which they are sent. -The 13,089 probes received by the HTTP and HTTPS ports +from which they are sent, or appear to be sent. +The 13,089 probes received by the HTTP\index{HTTP} and HTTPS\index{HTTPS} ports of my server came from 11,907 distinct IP addresses, -96\% of them appearing only once. +representing +% $ xz -dc figures/active-probing/garbage.http.csv.xz | figures/netblocks/netblocks -prefixlen 16 | sort | uniq -c | wc -l +% 358 +% $ xz -dc figures/active-probing/garbage.http.csv.xz | figures/netblocks/netblocks -prefixlen 8 | sort | uniq -c | wc -l +% 47 +47~/8 networks and +% figures/active-probing.R: +% Number of unique ASNs in x.http: 26 +26~autonomous systems\index{autonomous system}. +96\% of the addresses appeared only once. There is one extreme outlier, the address 202.108.181.70\index{202.108.181.70 (active prober)}, which by itself accounted for 2\% of the probes. +(Even this large fraction stands in contrast to previous studies, +where that single IP address accounted for roughly half the probes~\cite[\S 4.5.1]{Winter2012a}.) Among the address ranges are ones belonging to residential ISPs. -Despite these many source addresses, -the sending of probes seems to be controlled +Despite the many source addresses, +the probes seems to be managed by only a few underlying processes. -The evidence for this lies in shared metadata patterns: -TCP initial sequence numbers -and TCP timestamps. -\autoref{fig:active-probing-tsval} shows patterns -in TCP timestamps +The evidence for this lies in shared patterns in metadata: +TCP\index{TCP} initial sequence numbers +and TCP timestamps\index{TCP!timestamps}. +\autoref{fig:active-probing-tsval} shows clear patterns +in TCP timestamps, from about six months during which we ran a full packet capture -on the web server, in addition to application-layer logging. +on my web server, in addition to application-layer logging. -Wilde, and Winter and Lindskog, -had found that random ``garbage'' probes -were sent immediately after the client activity -that triggered them, -while Tor probes were batched and sent only every 15 minutes. -The Tor probing behavior had changed by 2015, -so that Tor probes were also sent immediately. - -We tried connecting back to the source address of probes. +We tried connecting back\index{port scanning} to the source address of probes. Immediately after receiving a probe, -the probing IP address was completely unresponsive +the probing IP address would be completely unresponsive to any stimulus we could think to apply. -In some cases though, within an hour the address would become responsive. +In some cases though, within an hour the address became responsive. The responsive hosts looked like what you would expect to find -if you scanned such address ranges: -a variety of operating systems and open ports. +if you scanned such address ranges, +with a variety of operating systems and open ports. \section{Fingerprinting the probers} -A potential countermeasure against active probing is to have each proxy, -when it receives a connection, somehow decide whether the connection -come from a legitimate client or a prober, -Of course, the right way to distinguish legitimate clients -is with proper cryptographic authentication, -whether at the transport layer (like BridgeSPA~\cite{Smits2011a}) -or at the application layer (like ScrambleSuit, obfs4, and Shadowsocks). -Failing that, one might hope to distinguish probers by their fingerprints, +\index{fingerprinting|(} + +A potential countermeasure against active probing is for each proxy, +when it receives a connection, to somehow decide whether the connection +comes from a legitimate client, or from a prober. +Of course, the right way to identify legitimate clients +is with cryptographic authentication\index{authentication}, +whether at the transport layer (like BridgeSPA~\cite{Smits2011a}\index{BridgeSPA}) +or at the application layer (like +ScrambleSuit\index{ScrambleSuit}, +obfs4\index{obfs4}, +and Shadowsocks\index{Shadowsocks}). +But when that is not possible, one might hope to distinguish probers by their fingerprints, idiosyncrasies in their implementation -that make them stand out from legitimate clients. -In the case of the Great Firewall, source IP address alone -does not suffice -because---apart from the special address 202.108.181.70\index{202.108.181.70 (active prober)}---the -probers' source addresses -come from many networks, including those where we might expect +that make them stand out from ordinary clients. +In the case of the Great Firewall\index{Great Firewall of China}, +the source IP address +does not suffice as a fingerprint because of the great diversity +of source addresses the system makes use of. +And in a reversal of the usual collateral damage\index{collateral damage}, +the source addresses include those where we might expect legitimate clients to reside. -There are, however, certain fingerprints at the application layer. +The probes do, however, exhibit certain fingerprints at the application layer. While none of the ones we found were robust enough to effectively exclude active probers, they do hint at how the probing is implemented. -The active probers have an unusual TLS fingerprint, -TLSv1.0 with a peculiar list of ciphersuites. -Tor probes sent only a VERSIONS cell~\cite[\S 4.1]{tor-spec}, +The active probers have an unusual TLS fingerprint\index{TLS!fingerprinting}, +TLSv1.0\index{TLS} with a peculiar list of ciphersuites. +Tor probes sent only a VERSIONS cell~\cite[\S 4.1]{tor-spec}\index{VERSIONS (Tor cell)}, waited for a response, then closed the connection. -The VERSIONS cell corresponded to a ``v2'' Tor handshake -that had been superseded since 2011 -(though one that was still in use by a small number of real clients). -The Tor probes described by Wilde in 2011 +The format of the VERSIONS cell was that of a ``v2'' Tor handshake\index{Tor!protocol} +that has been superseded since 2011, +though still in use by a small number of real clients. +The Tor\index{Tor} probes described by Wilde\index{Wilde, Tim} in 2011 went further into the protocol. It hints at the possibility that at one time, the active probers used a (possibly modified) Tor client, -and later switched to a lighter-weight custom implementation. +and later switched to a custom implementation. -The obfs2 probes were conformant with the protocol +The obfs2\index{obfs2} probes were conformant with the protocol specification, and unremarkable except for the fact that sometimes payloads were duplicated. obfs2 clients are supposed to use fresh randomness for each connection, but a small fraction, about 0.65\%, of obfs2 probes -shared an identical payload with another probe. +shared an identical payload with one other probe. The two probes in a pair came from different source IP addresses and arrived within a second of each other. -The apparently separate probers therefore share some state -or a pseudorandom number generator. +The apparently separate probers must therefore share some state---at +least a shared pseudorandom number generator. -The obfs3 protocol calls for the client to send -random padding, the amount of padding being randomly distributed. -The active probers' implementation of obfs3 protocol -gets the distribution wrong, +The obfs3\index{obfs3} protocol calls for the client to send +a random amount of random bytes as padding. +The active probers' implementation of the protocol +gets the probability distribution wrong, half the time sending too much padding. This feature would be difficult to exploit for detection, though, -because it would rely on the application-layer proxy code -being able to infer TCP segment boundaries. +because it would rely on application-layer proxy code +being able to infer TCP\index{TCP} segment boundaries. -The SoftEther probes seemed to have been based on an earlier -version of the official SoftEther probe than was current at the time, -lacking an HTTP Host header. +The SoftEther\index{SoftEther VPN} probes seem to have been based on an earlier +version of the official SoftEther client software than was current at the time, +differing from current version in that +they lack an HTTP Host header\index{Host (HTTP header)}. They also differed from the official client -in that they were not preceded by a GET request. -The TLS fingerprint of the official client +in that their POST\index{POST (HTTP method)} +request was not preceded by a GET\index{GET (HTTP method)} request. +The TLS fingerprint\index{TLS!fingerprinting} of the official client is much different from that of the probers, again hinting at a custom implementation. -The AppSpot probes have a User-Agent header -that claims to be a specific version of Chromium; +The AppSpot probes have a User-Agent header\index{User-Agent (HTTP header)} +that claims to be a specific version of the Chrome browser\index{Chrome web browser}; however the rest of the header, -and the TLS fingerprint are inconsistent with Chromium. +and the TLS fingerprint\index{TLS!fingerprinting} are inconsistent with Chrome. + +\index{fingerprinting|)} + +\index{active probing|)} \chapter{Time delays in censors' reactions} @@ -2609,7 +2871,7 @@ 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, +from probe sites in China\index{China}, Iran\index{Iran}, and Kazakhstan\index{Kazakhstan}, we uncovered previously undocumented behaviors of censors that hint at how they operate at a deeper level. @@ -2634,10 +2896,29 @@ 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} +Zhu et~al.~\cite{Zhu2013a-local} studied the question +of censor reaction time in a different context: +deletion of posts on the Chinese microblogging service Sina Weibo. +Through frequent polling, +they were able to measure---down to the minute---the +delay between when a user made a post +and when a censor deleted it. +About 90\% of deletions happened within 24~hours, +and 30\% within 30~minutes---but there was a long tail of +posts that survived several weeks before being deleted. +The authors used their observations to make educated guesses +about the inner workings of the censors. +Posts on trending topics tended to be deleted more quickly. +Posts made late at night had a longer average lifetime, +seemingly reflecting workers arriving in the morning +and clearing out a nightly backlog of posts. +King et~al.~\cite{King2012a} examined six months +of deleted posts on Chinese social networks. +The pattern of deletions seemed to give a view +into the goal of the censor: +not to prevent criticism of the government, +as might be expected, +but to forestall collective public action. Nobori and Shinjo give a timeline~\cite[\S 6.3]{Nobori2014a} of circumventor and censor actions and reactions @@ -2664,15 +2945,6 @@ 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 @@ -2681,24 +2953,32 @@ 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, +(The bridges then were blocked by RST injection\index{RST (TCP flag)}, 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}. +\todo[inline]{ +we are used to making conservative assumptions +if an attacker gets code execution, it's game over +but what really \emph{does} happen when someone gets code execution? +similarly, it is prudent to assume that default bridges are immediately blocked +but what really \emph{does} happen? +} + \section{The experiment} Our experiment primarily involved frequent, active measurements of the reachability of default bridges -from probe sites in China, Iran, and Kazakhstan +from probe sites in China\index{China}, Iran\index{Iran}, and Kazakhstan\index{Kazakhstan} (countries well known to censor the network), -as well as a control site in the U.S. +as well as a control site in the U.S.\index{United States of America} We used a script that, every 20~minutes, -attempted to make a TCP connection +attempted to make a TCP\index{TCP} connection to each default bridge. The script recorded, for each attempt, whether the connection was successful, @@ -2706,59 +2986,59 @@ 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 +The control site in the U.S.\index{United States of America}\ enables to distinguish temporary bridge failures from actual blocking. -The script only tests whether it is possible to make a TCP connection, +The script only tests whether it is possible to make a TCP\index{TCP} connection, which is necessary but not sufficient to actually make a Tor connection through the bridge. -In Kazakhstan, we additionally deployed measurements +In Kazakhstan\index{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 +we ran from China\index{China}, Iran\index{Iran}, and Kazakhstan\index{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 +We began at a time when Tor\index{Tor Project} 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 +coordinating with Tor Browser\index{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. +We were only concerned with default bridges, not secret ones\index{Tor bridges}. 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}, +We focused on bridges using the obfs4 pluggable transport~\cite{obfs4}\index{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, +We could not have done the experiment with obfs3\index{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. +Bridges are identified by a nickname and a port number\index{nickname (Tor bridges)}\index{Tor bridges!nicknames}. 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, +So, for example, ``ndnop3:24215''\index{ndnop3 (Tor bridge)} is one bridge, +and ``ndnop3:10527''\index{ndnop3 (Tor bridge)} is another bridge on the same IP address. +We pulled the list of bridges from Tor Browser\index{Tor Browser} +and Orbot, which is the port of Tor for Android\index{Android}. +Tor Browser and Orbot\index{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 +Along with the new obfs4\index{obfs4} bridges, we tested some existing bridges. \begin{table} @@ -2818,6 +3098,27 @@ Each bridge is identified by a nickname Each nickname represents a distinct IP address. Port numbers are in chronological order of release. } +\index{obfs4} +\index{FTE} +\index{Tor Browser} +\index{Orbot} +\index{Tor bridge!default} +\index{ndnop3 (Tor bridge)} +\index{ndnop5 (Tor bridge)} +\index{riemann (Tor bridge)} +\index{noether (Tor bridge)} +\index{Mosaddegh (Tor bridge)} +\index{MaBishomarim (Tor bridge)} +\index{GreenBelt (Tor bridge)} +\index{JonbesheSabz (Tor bridge)} +\index{Azadi (Tor bridge)} +\index{Lisbeth (Tor bridge)} +\index{NX01 (Tor bridge)} +\index{LeifEricson (Tor bridge)} +\index{cymrubridge31 (Tor bridge)} +\index{cymrubridge33 (Tor bridge)} +\index{fdctorbridge01 (Tor bridge)} +\index{ndnop4 (Tor bridge)} \label{tab:proxy-probe-destinations} \end{table} @@ -2845,9 +3146,10 @@ from the source code repository, or downloads nightly builds, could discover bridges at this stage. \item[Testing release] +\index{Tor Browser!releases} Just prior to a public release, Tor Browser developers send candidate builds -to a public mailing list to solicit +to a public mailing list\index{tor-qa mailing list} to solicit quality assurance testing. A~censor that follows testing releases would find ready-made executables with bridges embedded @@ -2856,7 +3158,7 @@ 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. +and announced on the Tor Blog\index{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 @@ -2864,7 +3166,7 @@ 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}, +According to Tor Metrics~\cite{tor-metrics-webstats-tb}\index{Tor Metrics}, stable downloads outnumber alpha downloads by a factor of about 30~to~1. \end{description} @@ -2872,7 +3174,7 @@ 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, +BridgeDB~\cite{BridgeDB}\index{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, @@ -2882,6 +3184,7 @@ and not a side effect of some other detection system. \section{Results from China} \label{sec:proxy-probe-china} +\index{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, @@ -2913,7 +3216,7 @@ 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. +their color shows whether the attempted TCP\index{TCP} connection was successful. Blocking events appear as a transition from narrow blue (success, agrees with control) to wide gray (timeout, disagrees with control). @@ -2921,6 +3224,21 @@ The notation ``//~NX01:443'' means that the bridge was commented out for that re Points marked with circled letters \cnref{a}, \cnref{b}, etc., are explained in the text. } +\index{ndnop3 (Tor bridge)} +\index{ndnop5 (Tor bridge)} +\index{riemann (Tor bridge)} +\index{noether (Tor bridge)} +\index{Mosaddegh (Tor bridge)} +\index{MaBishomarim (Tor bridge)} +\index{GreenBelt (Tor bridge)} +\index{JonbesheSabz (Tor bridge)} +\index{Azadi (Tor bridge)} +\index{Lisbeth (Tor bridge)} +\index{NX01 (Tor bridge)} +\index{LeifEricson (Tor bridge)} +\index{fdctorbridge01 (Tor bridge)} +\index{ndnop4 (Tor bridge)} +\index{China} \label{fig:proxy-probe-timelines-china1} \end{figure} @@ -3114,7 +3432,7 @@ 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. +while connection attempts were timing out not only from China, but also from the U.S.\index{United States of America} 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, @@ -3350,13 +3668,17 @@ As expected, they were already blocked at the beginning, and remained so 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. +nor in BridgeDB\index{BridgeDB}. As expected, it was never blocked. +\index{China|)} + \section{Results from Iran} \label{sec:proxy-probe-iran} +\index{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. @@ -3370,6 +3692,19 @@ We found no evidence of blocking of default bridges in Iran. What connection failures there were, were also seen from our control site. } +\index{Iran} +\index{ndnop3 (Tor bridge)} +\index{ndnop5 (Tor bridge)} +\index{riemann (Tor bridge)} +\index{noether (Tor bridge)} +\index{Mosaddegh (Tor bridge)} +\index{MaBishomarim (Tor bridge)} +\index{GreenBelt (Tor bridge)} +\index{JonbesheSabz (Tor bridge)} +\index{Azadi (Tor bridge)} +\index{LeifEricson (Tor bridge)} +\index{fdctorbridge01 (Tor bridge)} +\index{ndnop4 (Tor bridge)} \label{fig:proxy-probe-timelines-iran} \end{figure} @@ -3388,19 +3723,23 @@ 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, +However, in Kazakhstan\index{Kazakhstan} we found exactly that situation, with bridges being effectively blocked -despite the firewall allowing TCP connections to them. +despite the firewall allowing TCP\index{TCP} connections to them. + +\index{Iran|)} \section{Results from Kazakhstan} \label{sec:proxy-probe-kazakhstan} +\index{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, +It was in AS~203087, which belongs to GoHost.kz\index{GoHost.kz}, a Kazakh hosting provider. The flakiness of the VPN left us with two extended gaps in measurements. @@ -3409,44 +3748,69 @@ gaps in measurements. \centering \includegraphics{figures/proxy-probe-timelines-kazakhstan} \caption{ -Tor Browser default bridge reachability from Iran. -Judging by TCP reachability alone, +Tor Browser default bridge reachability from Kazakhstan. +Judging by TCP\index{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. } +\index{Kazakhstan} +\index{ndnop3 (Tor bridge)} +\index{ndnop5 (Tor bridge)} +\index{Mosaddegh (Tor bridge)} +\index{GreenBelt (Tor bridge)} +\index{Lisbeth (Tor bridge)} +\index{NX01 (Tor bridge)} +\index{LeifEricson (Tor bridge)} +\index{cymrubridge31 (Tor bridge)} +\index{cymrubridge33 (Tor bridge)} +\index{fdctorbridge01 (Tor bridge)} +\index{ndnop4 (Tor bridge)} \label{fig:proxy-probe-timelines-kazakhstan} \end{figure} \begin{figure}[p] \centering -\placeholder{3in} +\includegraphics{figures/proxy-probe-bridgetest-kazakhstan} \caption{ -Tor connection progress in the U.S.\ and Kazakhstan. -These measurements show that even though bridges accepted TCP connections, +Tor connection progress in the U.S.\index{United States of America}\ and Kazakhstan. +These measurements show that even though bridges accepted TCP\index{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. } +\index{United States of America} +\index{Kazakhstan} +\index{ndnop3 (Tor bridge)} +\index{ndnop5 (Tor bridge)} +\index{Mosaddegh (Tor bridge)} +\index{GreenBelt (Tor bridge)} +\index{Lisbeth (Tor bridge)} +\index{NX01 (Tor bridge)} +\index{LeifEricson (Tor bridge)} +\index{cymrubridge31 (Tor bridge)} +\index{cymrubridge33 (Tor bridge)} +\index{fdctorbridge01 (Tor bridge)} +\index{ndnop4 (Tor bridge)} \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 +than that which we observed in China\index{China}. +At a TCP\index{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. +a short time after the TCP\index{TCP} handshake. We deployed an additional probe script in Kazakhstan. -This one did not only try to establish a TCP connection, +This one did not only try to establish a TCP\index{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; @@ -3460,6 +3824,8 @@ 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. +\index{Kazakhstan|)} + % \section{Other cases of delay} % \label{sec:proxy-probe-other} @@ -3474,160 +3840,185 @@ after public release, depending on which release you compare to. \chapter{Domain fronting} \label{chap:domain-fronting} +\index{domain fronting|(textbf} + Domain fronting is a general-purpose circumvention technique -based on HTTPS. +based on HTTPS\index{HTTPS}. It disguises the true destination of a client's messages by routing them through a large web server or -content delivery network that hosts +content delivery network\index{content delivery network} that hosts many web sites. -The messages appear to go not to their actual destination -but to some \emph{front domain}, -one whose blocking would result in high collateral damage. +From the censor's point of view, +messages appear to go not to their actual (presumably blocked) destination, +but to some other \emph{front domain}\index{front domain}, +one whose blocking would result in high collateral damage\index{collateral damage}. Because (with certain caveats) the censor cannot distinguish domain-fronted HTTPS requests from ordinary HTTPS requests, -it cannot block circumvention without blocking the front domain. -Active probing primarily addresses the problem -of detection by address, -but also deals with detection by content and active probing. +it cannot block circumvention without also blocking the front domain. +Domain fronting primarily addresses the problem +of detection by address\index{detection!by address} (\autoref{sec:address-strategies}), +but also deals with detection by content\index{detection!by content} (\autoref{sec:obfuscation-strategies}) +and active probing\index{active probing} (\autoref{chap:active-probing}). Domain fronting is today an important component of many circumvention systems. The core idea of domain fronting is the use of different domain names at different protocol layers. -When you make an HTTPS request, the domain name +When you make an HTTPS\index{HTTPS} request, the domain name of the server you're trying to access normally appears in three places that are visible to the censor: \begin{itemize} -\item the DNS query -\item the client's TLS Server Name Indication (SNI) extension~\cite[\S 3]{rfc6066} -\item the server's TLS certificate~\cite[\S 7.4.2]{rfc5246} +\item the DNS query\index{DNS} +\item the client's TLS\index{TLS} Server Name Indication (SNI) extension~\cite[\S 3]{rfc6066}\index{Server Name Indication (SNI)} +\item the server's TLS\index{TLS} certificate\index{certificate}~\cite[\S 7.4.2]{rfc5246}\index{common name (X.509)} \end{itemize} and in one place that is not visible to the censor, because it is encrypted: \begin{itemize} -\item the HTTP Host header~\cite[\S 5.4]{rfc7230} +\item the HTTP\index{HTTP} Host header~\cite[\S 5.4]{rfc7230}\index{Host (HTTP header)} \end{itemize} In a normal request, the same domain name appears in all four places, -and all of them except for the Host header afford the censor -an easy basis for blocking by address. -The only difference in a domain-fronted request is that -the domain name that appears in -the Host header, on the ``inside'' of the request, +and all of them except for the Host header\index{Host (HTTP header)} afford the censor +an easy basis for blocking\index{blocking!by address}. +The difference in a domain-fronted request is that +the domain name in +the Host header\index{Host (HTTP header)}, on the ``inside'' of the request, is not the same as the domain that appears in the other places, on the ``outside.'' -\autoref{fig:domain-fronting} illustrates. +\autoref{fig:domain-fronting} shows the first steps +of a client making a domain-fronted request. \begin{figure} \centering -\includegraphics[height=1.5in]{figures/domain-fronting} +\includegraphics{figures/domain-fronting} \caption{ Domain fronting uses different names at different protocol layers. -The forbidden destination domain is hidden under -ordinary TLS encryption. -The censor only sees a front domain, -one chosen to be expensive to block. +The forbidden destination domain is encrypted within +the TLS\index{TLS} layer. +The censor sees only a front domain\index{front domain}, +one chosen to be expensive to block\index{collateral damage}. +Not shown here, the server's certificate\index{certificate} +will also expose only the front domain\index{common name (X.509)}, +because the certificate is a property of the TLS layer, +not the HTTP\index{HTTP} layer. } \label{fig:domain-fronting} \end{figure} -The SNI extension and the Host header serve similar purposes: -they both enable virtual hosting, -where one server handles requests for multiple domains. -Both fields allow the client to inform the server -of which domain it wants to access. -The SNI works at the TLS layer, -telling the server which certificate to send; -and the Host header works at the HTTP layer, +The SNI extension\index{Server Name Indication (SNI)} +and the Host header\index{Host (HTTP header)} serve similar purposes. +They both enable virtual hosting\index{virtual hosting}, +which is when one server handles requests for multiple domains. +Both fields allow the client to tell the server +which domain it wants to access, but they work +at different layers. +The SNI works at the TLS\index{TLS} layer, +telling the server which certificate\index{certificate} to send. +The Host header works at the HTTP\index{HTTP} layer, telling the server what contents to serve. -It is something of an accident that these +It is something of an accident that these two partially redundant fields both exist. -Before TLS, virtual hosting only required the Host header. -When HTTP is combined with TLS, -the client cannot send the Host header until the TLS handshake is complete, -and the TLS handshake cannot complete without the server knowing +Before TLS\index{TLS}, virtual hosting required only the Host header\index{Host (HTTP header)}. +The addition of TLS creates a chicken-and-egg problem: +the client cannot send the Host header\index{Host (HTTP header)} +until the TLS\index{TLS} handshake is complete, +and the server cannot complete the TLS handshake without knowing which certificate to send. -The SNI extension resolves the deadlock by sending -the domain name in plaintext at the beginning of the handshake. +The SNI extension\index{Server Name Indication (SNI)} +resolves the deadlock by sending +the domain name in plaintext in the TLS layer. Domain fronting takes advantage of decoupling the two normally coupled values. It relies on the server decrypting the TLS layer and throwing it away, -then routing requests internally string according to the Host header. - -Virtual hosting, in the form of content delivery networks (CDNs), is now common. -A~CDN works by placing an ``edge server'' between -the client and the destination, called an ``origin server'' in this context. -When an edge server receives a request, -it forwards the request to the origin server according to the Host header. -The edge server receives the response, -optionally caches it, and forwards it back to the client. +then routing requests according to the Host header\index{Host (HTTP header)}. + +Virtual hosting\index{virtual hosting}, +in the form of content delivery networks\index{content delivery network} (CDNs), is now common. +A~CDN works by placing an ``edge server''\index{edge server} between +the client and the destination, called an ``origin server''\index{origin server} in this context. +When the edge server receives an HTTP\index{HTTP} request, +it forwards the request to the origin server named by the Host header\index{Host (HTTP header)}. +The edge server receives the response from the origin server\index{origin server} +and forwards it back to the client. The edge server is effectively a proxy: -the client never contacts the destination directly. +the client never contacts the destination directly, +but only through the intermediary CDN, +which foils address-based blocking\index{blocking!by address} of the destination +the censor may have imposed. +Domain fronting also works on application hosting services +like Google App Engine\index{Google App Engine}, +because one can upload a simple application that emulates a CDN. The contents of the client's messages, -as well as their true destination, -are protected by TLS encryption. -If the censor active-probes the server, -all it gets is whatever the edge server would return normally. -The censor may block edge servers or the front domain, +as well as the domain name of the true destination, +are protected by TLS\index{TLS} encryption\index{encryption}. +The censor may, +in an attempt to block domain fronting, +block CDN edge servers\index{edge server} or the front domain\index{front domain}, but only at the cost of blocking all other, -non-circumvention-related traffic -to the CDN or domain, -with the collateral damage that entails. - -Domain fronting may be an atypical use of HTTPS, -but it is not a way to get free CDN service. -The CDN will not forward requests to arbitrary destinations, -only to the domains of its customers. +non-circumvention-related traffic to those addresses, +with whatever collateral damage\index{collateral damage} that entails. + +Domain fronting may be an atypical use of HTTPS\index{HTTPS}, +but it is not a way to get free CDN\index{content delivery network} service. +A~CDN does not forward requests to arbitrary domains, +only to domains belonging to one of its customers. Setting up domain fronting requires -paying for CDN service---and the costs can be high, +becoming a customer of a CDN\index{content delivery network} +and paying for service---and the cost can be high\index{domain fronting!costs of}, as \autoref{sec:meek-history} shows. -It might seem at first that domain fronting is -only useful for accessing HTTPS resources, -and only when they are hosted on a service that supports fronting. -But extending to general-purpose circumvention -only requires a minor extra step: -host an HTTP-based tunneling proxy on the web service in question. +It may seem at first that domain fronting is +only useful for accessing HTTPS\index{HTTPS} web sites, +and then only when they are hosted on a CDN\index{content delivery network}. +But extending the idea to work with +arbitrary destinations +only requires the minor additional step +of running an HTTPS-based proxy server +and hosting it on the web service in question. +The CDN forwards to the proxy, which +then forwards to the destination. Domain fronting shields the address of the proxy, -which then provides access to arbitrary destinations. -HTTP tunneling underlies meek, -a circumvention system based on domain fronting, -discussed further in \autoref{sec:meek-impl}. +which does not pose enough risk of collateral damage\index{collateral damage}, +on its own, to resist blocking\index{blocking!by address}. +Exactly this sort of HTTPS tunneling underlies meek\index{meek}, +a circumvention system based on domain fronting +that is discussed further in \autoref{sec:meek-impl}. One of the best features of domain fronting is that it does not require any secret information, -completely bypassing the proxy distribution problem -(\label{sec:address-strategies}). -The address of the CDN edge server, +completely bypassing the proxy distribution problem\index{proxy distribution problem} +(\autoref{sec:address-strategies}). +The address of the CDN\index{content delivery network} edge server\index{edge server}, the address of the proxy hidden behind it, -the fact that some fraction of traffic to the edge server is circumventing---all -of these may be known by the censor. +the fact that some fraction of traffic to the edge server\index{edge server} is circumvention---all +of these may be known by the censor, +without diminishing the system's blocking resistance. This is not to say, of course, that domain fronting is impossible to block---as always, a censor's capacity to block depends on its -tolerance for collateral damage. -But the lack of secrecy makes the censor's choice especially stark: -either allow circumvention, or block a domain. -This is how we should think of all circumvention: -not ``can it be blocked,'' -but ``what does it cost to block.'' +tolerance for collateral damage\index{collateral damage}. +But the lack of secrecy makes the censor's choice stark: +allow circumvention, or block a domain. +This is the way to think about circumvention in general: +not ``can it be blocked?'' +but ``what does it cost to block?'' \section{Work related to domain fronting} -Neither I~nor my coauthors invented the technique -of domain fronting. -We did, however, give it a name, -popularize its use, +I~did not invent domain fronting. +I~did, however, give it a name, +help popularize its use, and produce an important implementation. -As far as I know, +As far as I~have been able to find out, the first implementation of domain fronting -in a circumvention system was in GoAgent circa 2012. -GoAgent employed a variant where -the SNI is omitted completely, -rather than being faked. +was in GoAgent\index{GoAgent}, a circumvention system, circa 2012. +GoAgent employed a variant of fronting where +the SNI\index{Server Name Indication (SNI)} +is omitted, rather than being faked. % GoAgent 2.0 began sending HTTPS requests: % b4ab1f83f57b91eda34ae1743021fbb60ecd2f60 is the first bad commit % commit b4ab1f83f57b91eda34ae1743021fbb60ecd2f60 @@ -3636,88 +4027,90 @@ rather than being faked. % % merge 2.0 code Earlier in 2012, -Bryce Boe wrote a blog post~\cite{Boe2012a} -outlining how to use Google App Engine as a proxy, -and suggested that sending a false SNI could -bypass SNI whitelisting. -Way back in 2004, -in an era when HTTPS and CDNs were less common -than they are today, -Köpsell and Hillig foresaw -the possibilities~\cite[\S 5.2]{Koepsell2004a}: -``Imagine that all web pages of the United States are only +Bryce Boe wrote a blog post~\indexauthors{\cite{Boe2012a}} +outlining how to use Google App Engine\index{Google App Engine} as a proxy, +and suggested that sending a false SNI\index{Server Name Indication (SNI)} +could bypass SNI whitelisting\index{whitelisting}. +Even farther back, in 2004, +when HTTPS\index{HTTPS} and CDNs\index{content delivery network} were less common, +Köpsell and Hillig~\indexauthors{\cite[\S 5.2]{Koepsell2004a}} +foresaw the possibilities +of a situation such as exists today: +``Imagine that all web pages of the United States\index{United States of America} are only retrievable (from abroad) by sending encrypted requests to one and only one special node. Clearly this idea belongs to the `all or nothing' concept because a blocker has to block -all requests to this node.'' +all requests to this node\index{blocking!by address}.'' +\index{refraction networking|(} Refraction networking is the name for -a class of circumvention techniques, -similar in spirit to domain fronting. +a class of circumvention techniques +that share similarities with domain fronting. The idea was introduced in 2011 with the designs -Cirripede~\cite{Houmansadr2011a}, -CurveBall~\cite{Karlin2011a}, -and Telex~\cite{Wustrow2011a}. +Cirripede\index{Cirripede}~\cite{Houmansadr2011a}, +CurveBall\index{CurveBall}~\cite{Karlin2011a}, +and Telex\index{Telex}~\cite{Wustrow2011a}. In refraction networking, it is network routers that act as proxies, lying at the middle of network paths rather than at the ends. The client ``tags'' its messages in a way that the censor cannot detect -(analogously to the way the Host header +(analogously to the way the Host header\index{Host (HTTP header)} is encrypted in domain fronting). When the router finds a tagged message, it shunts the message away from its nominal destination and towards some other, covert destination. Refraction networking derives its blocking resistance -from the collateral damage that would result -from blocking the cover channel (typically TLS) +from the collateral damage\index{collateral damage} that would result +from blocking the cover channel (typically TLS\index{TLS}) or the refraction-capable network routers. Refraction networking has the potential to be the basis of exceptionally high-performance circumvention, -as a test deployment in Spring 2017 demonstrated~\cite{Frolov2017a}. +as a test deployment in Spring 2017 demonstrated~\cite{Frolov2017a-local}. +\index{refraction networking|)} -CloudTransport~\cite{Brubaker2014a}, proposed in 2014, -is similar to domain fronting in many respects. -It uses HTTPS to a shared server +CloudTransport\index{CloudTransport}~\cite{Brubaker2014a}, proposed in 2014, +is like domain fronting in many respects. +It uses HTTPS\index{HTTPS} to a shared server (in this case a cloud storage server). The specific storage area being accessed---what the censor would like to know---is encrypted, -so the censor cannot block CloudTransport +so the censor cannot block CloudTransport\index{CloudTransport} without blocking the storage service completely. -In 2015 I~published a paper on domain fronting~\cite{Fifield2015a-local} +In 2015 I~published a paper on domain fronting~\indexauthors{\cite{Fifield2015a-local}} with Chang Lan, Rod Hynes, Percy Wegmann, and Vern Paxson. In it, we described the experience of deploying -domain fronting on Tor, -Lantern~\cite{lantern}, -and Psiphon~\cite{psiphon}, -and began an investigation of the -side channels, such as packet size and timing, +domain fronting on Tor\index{Tor}, +Lantern\index{Lantern}~\cite{lantern}, +and Psiphon\index{Psiphon}~\cite{psiphon}, +and began an investigation into +side channels, such as packet size and timing\index{packet size and timing}, that a censor might use to detect domain fronting. -The Tor deployment, called meek, +The Tor deployment, called meek\index{meek}, is the subject of Sections~\ref{sec:meek-impl} and~\ref{sec:meek-history}. -Later in 2015 there were a couple of papers on the detection -of circumvention transports, including meek. -Tan et~al.~\cite{Tan2015a} measured the -Kullback--Leibler divergence\index{Kullback--Leibler divergence}\index{relative entropy|see Kullback--Leibler divergence} -between the distributions of packet size and packet timing +Later in 2015 there were a couple of papers on the detection\index{detection} +of circumvention transports, including meek\index{meek}. +Tan et~al.~\indexauthors{\cite{Tan2015a}} measured the +Kullback--Leibler divergence\index{Kullback--Leibler divergence} +between the distributions of packet size and packet timing\index{packet size and timing} in different protocols. -(The paper is written in Chinese +(The paper is written in Chinese\index{Chinese} and my understanding of it is based on an imperfect translation.) -Wang et~al.~\cite{Wang2015a} -built classifiers for meek +Wang et~al.~\indexauthors{\cite{Wang2015a}} +built classifiers for meek\index{meek} among other protocols -using entropy, timing, +using entropy\index{entropy}, timing\index{packet size and timing}, and transport-layer features. They emphasized practical classifiers -and tested their false-classification rates +and tested their false-classification\index{false positives}\index{false negatives} rates against real traffic traces. @@ -3730,18 +4123,18 @@ against real traffic traces. \section{A pluggable transport for Tor} \label{sec:meek-impl} -I~am the main author and maintainer of meek, -a pluggable transport for Tor based on domain fronting. -meek uses domain-fronted HTTP POST requests +I~am the main author and maintainer of meek\index{meek}, +a pluggable transport\index{pluggable transports} for Tor based on domain fronting. +meek uses domain-fronted HTTP\index{HTTP} POST\index{POST (HTTP method)} requests as the primitive operation to send or receive chunks of data up to a few kilobytes in size. -The intermediate CDN forwards requests -to a bridge. +The intermediate CDN\index{content delivery network} +receives domain-fronted requests and forwards them to a Tor bridge\index{Tor bridge}. Auxiliary programs on the client and the bridge -convert between a sequence of HTTP requests -and the byte stream expected by Tor. +convert the sequence of HTTP requests +to the byte stream expected by Tor. The Tor processes at either end are oblivious -to the domain-fronted transport between them. +to the domain-fronted that is going on between them. \autoref{fig:meek} shows how the components and protocol layers interact. @@ -3750,40 +4143,45 @@ and protocol layers interact. \includegraphics[width=\textwidth]{figures/meek-architecture} \caption{ Putting it together: -domain fronting as the basic tool in a circumvention system. -The CDN acts as a limited sort of proxy, -capable of proxying only to destinations -within its own network -(one of which we control). -The node we control is a Tor bridge, -equipped with a plugin to interface -between the HTTP tunnel and the Tor protocol. +how to build a circumvention system around domain fronting. +The CDN\index{content delivery network} acts as a limited proxy, +only capable of forwarding to destinations +within its own network---one of which +is a bridge, which we control. The bridge acts as a general-purpose proxy, -granting access to any destination. +capable of reaching access to any destination. +Fronting through the CDN +hides the bridge's address, +which is presumably blocked\index{blocking!by address}. } +\index{Tor bridge} +\index{Server Name Indication (SNI)} +\index{Host (HTTP header)} +\index{meek} \label{fig:meek} \end{figure} When the client has something to send, -it issues a POST request with the data in the body. -Because in HTTP/1.1 there is no way -for an HTTP server to preemptively push data +it issues a POST\index{POST (HTTP method)} request with data in the body; +the server sends data back in the body of its responses. +HTTP/1.1\index{HTTP} does not provide a way +for a server to preemptively push data to a client, -the meek server buffers data waiting to be sent -until it receives a client's request, +so the meek server buffers its outgoing data +until it receives a request, then includes the buffered data in the body of the HTTP response. The client must poll the server periodically, even when it has nothing to send, -to enable the server to send whatever buffered data it may have. -The meek server must handle multiple simultaneous clients. +to give the server an opportunity to send back whatever buffered data it may have. +The meek\index{meek} server must handle multiple simultaneous clients. Each client, at the beginning of a session, -generates a random session identifier string, -and includes it with its requests -in a special X-Session-Id HTTP header. +generates a random session identifier string +and sends it with its requests +in a special X-Session-Id\index{X-Session-Id (HTTP header)} HTTP header. The server maintains separate connections to the local Tor process for each session identifier. -\autoref{fig:meek-tunnel} shows a pattern of -request--response pairs. +\autoref{fig:meek-tunnel} shows a sequence of +requests and responses. \begin{figure} \centering @@ -3855,40 +4253,45 @@ The second POST is an example of an empty polling request, sent only to give the server an opportunity to send data downstream. } +\index{200 (HTTP status code)} +\index{HTTP} +\index{meek} +\index{Host (HTTP header)} +\index{Content-Length (HTTP header)} +\index{X-Session-Id (HTTP header)} +\index{POST (HTTP method)} \label{fig:meek-tunnel} \end{figure} +\index{TLS!fingerprinting|(} Even with domain fronting to hide the destination request, -a censor may try to distinguish circumventing HTTPS connections +a censor may try to distinguish circumventing HTTPS\index{HTTPS} connections by their TLS fingerprint. TLS implementations have a lot of latitude in composing their handshake messages, enough that it is possible to distinguish different TLS implementations through passive observation. -For example, the Great Firewall had used -Tor's TLS fingerprint for detection~\cite{tor-trac-4744}. -For this reason, meek strives to make its TLS fingerprint +For example, the Great Firewall\index{Great Firewall of China} used +Tor's\index{Tor} TLS fingerprint for detection as early as 2011~\cite{tor-trac-4744}. +For this reason, meek\index{meek} strives to make its TLS fingerprint look like that of a browser. -It does this by relaying its HTTPS requests through +It does this by relaying its HTTPS\index{HTTPS} requests through a local headless browser (which is completely separate from the browser that the user interacts with). +\index{TLS!fingerprinting|)} -meek first appeared in Tor Browser in October 2014, -and continues to be used to the present. -It is Tor's second-most-used transport -behind obfs4. -The next section is a detailed history of deployment. +meek\index{meek} first appeared in Tor Browser\index{Tor Browser} +in October 2014~\cite{tor-blog-tor-browser-40-released}, +and continues in operation to the present. +It is Tor's\index{Tor} second-most-used transport +(behind obfs4\index{obfs4})~\cite{tor-metrics-userstats-bridge-transport}. +The next section is a detailed history of its deployment. \section{An unvarnished history of meek deployment} \label{sec:meek-history} -\begin{itemize} -\item First release of Orbot that had meek? -\item Funding/grant timespans -\item origin of the name -\item ``Research and Realization of Tor Anonymous Communication Identification Method Based on Meek''? 2016 \url{http://cdmd.cnki.com.cn/Article/CDMD-10004-1016120870.htm} -\end{itemize} +\index{meek!history of|(} \begin{figure}[p] \centering @@ -3899,8 +4302,12 @@ of the meek pluggable transport, with selected events. This graph is an updated version of Figure~5 from the 2015 paper -``Blocking-resistant communication through domain fronting''~\cite{Fifield2015a-local}. +``Blocking-resistant communication through domain fronting''~\cite{Fifield2015a-local}; +the vertical blue stripe divides old and new data. +The user counts come from Tor Metrics~\cite{tor-tr-2012-10-001}. } +\index{meek} +\index{Tor Metrics} \label{fig:metrics-clients-meek} \end{figure} @@ -3916,7 +4323,7 @@ meek ran on three different web services: Google App Engine, Amazon CloudFront, and Microsoft Azure. The notation `{\color{gray} ---}' means meek wasn't deployed on that service in that month; -for example, we stopped using Google after May 2016 +for example, we stopped using App Engine after May 2016 following the suspension of the service (see discussion on p.~\pageref{para:meek-suspension}). The notation `{\color{gray} ?}' marks the months @@ -3924,152 +4331,182 @@ after I~stopped handling the invoices personally. I~don't know the costs for those months, so certain totals are marked with `\raisebox{.3ex}{\smaller +}' to indicate that they are higher -than what is shown, -but I~don't know by how much. +than the values shown. } +\index{meek!costs of|textbf} +\index{domain fronting!costs of} +\index{Google App Engine} +\index{Amazon CloudFront} +\index{Microsoft Azure} \label{tab:meek-costs} \end{table} -Fielding a circumvention and keeping it running is full of unexpected challenges. +Fielding a circumvention system and keeping it running is full of unexpected challenges. At the time of the publication of the domain fronting paper~\cite{Fifield2015a-local} in 2015, -meek had been deployed only a year and a half. -Here I will recount the entire history of the deployment project, -from inception to the present, a period of over three years. -I have been the main developer and project leader -of meek over its entire existence. -I hope to share the benefit of my experience -by commentating the history with surprises -and lessons learned. +meek had been deployed for only a year and a half. +Here I~will recount the history of the project +from its inception to the present, a period of four years. +As the main developer and project leader, +I~have a unique perspective that I~hope to share. +As backdrops to the narrative, \autoref{fig:metrics-clients-meek} shows the estimated concurrent number of users -of meek over its entire existence. -The counts come from Tor Metrics~\cite{tor-tr-2012-10-001}. +of meek over its existence, +and \autoref{tab:meek-costs} shows the monthly +cost to run it. \subsection*{2013: Precursors; prototypes} -The prehistory of meek begins in 2013 with flash proxy. -Flash proxy clients need a secure way to register their address -to a central facilitator, in order that flash proxies can connect back to them. -Initially we had only two means of registration: -flashproxy-reg-http, sending client registrations directly over HTTP; -and flashproxy-reg-email, sending client registrations to a special email address. +The prehistory of meek begins in 2013 with flash proxy\index{flash proxy}~\cite{Fifield2012a}. +Flash proxy clients need a secure rendezvous, +a way to register their address +to a central facilitator\index{flash proxy!facilitator}, +so that flash proxies may connect back to them. +Initially there were only two means of registration: +flashproxy-reg-http\index{flashproxy-reg-http}, +which sent client registrations as HTTP\index{HTTP} requests; +and flashproxy-reg-email\index{flashproxy-reg-email}, +which sent client registrations to a distinguished email\index{email} address. We knew that flashproxy-reg-http was easily blockable; flashproxy-reg-email had good blocking resistance but was somewhat slow and complicated, requiring a server to poll for new messages. -At some point, Jacob Appelbaum showed me an example of using +At some point, Jacob Appelbaum\index{Appelbaum, Jacob} +showed me an example of using domain fronting---though we didn't have a name for it then---to -access a simple HTTP-rewriting proxy on App Engine. -I eventually realized that the same trick would work for flash proxy rendezvous. -I proposed a design~\cite{tor-trac-8860} in May 2013 -and within a month Arlo Breault had written flashproxy-reg-appspot, -which worked just like flashproxy-reg-http, -but fronted through \nolinkurl{www.google.com} rather than -contacting the registration server directly. -The fronting-based registration became flash proxy's preferred method, -being faster and simpler than the email-based one. - -The development into a full-fledged bidirectional transport seems slow, in retrospect. -All the pieces were there; it was only a matter of putting them together. -I did not appreciate the potential of domain fronting when I saw it for the first time. -Even after the introduction of flashproxy-reg-appspot, -months passed before the beginning of meek. -The whole idea behind flash proxy registration was that the registration channel -could be of low quality---unidirectional, low-bandwidth, and high-latency---because -it was only used to bootstrap into a more capable channel (WebSocket). -Email fits well into this model: +access a simple HTML-rewriting proxy\index{HTML-rewriting proxy} +based on Google App Engine\index{Google App Engine}. +I~eventually realized that the same trick would work for flash proxy rendezvous\index{flash proxy!rendezvous}. +I~proposed a design~\cite{tor-trac-8860} in May 2013 +and within a month Arlo Breault\index{Breault, Arlo} had written +flashproxy-reg-appspot\index{flashproxy-reg-appspot}, +which worked just like flashproxy-reg-http\index{flashproxy-reg-http}, +except that it fronted through \nolinkurl{www.google.com}\index{www.google.com@\nolinkurl{www.google.com}} +rather than contacting the registration server directly. +The fronting-based registration became flash proxy's\index{flash proxy} preferred registration method, +being faster and simpler than the email-based\index{email} one. + +The development of domain fronting, from a simple rendezvous technique, +into a full-fledged bidirectional transport, seems slow in retrospect. +All the pieces were there; it was a matter of putting them together. +I~did not immediately appreciate the potential of domain fronting when I~first saw it. +Even after the introduction of flashproxy-reg-appspot\index{flashproxy-reg-appspot}, +months passed before the beginning of meek\index{meek}. +The whole idea behind flash proxy rendezvous\index{flash proxy!rendezvous} +is that the registration channel +can be of low quality---unidirectional, low-bandwidth, and high-latency---because +it is only used to bootstrap into a more capable channel +(WebSocket\index{WebSocket}, in flash proxy's case). +Email\index{email} fits this model well: not good for a general-purpose channel, -just good enough for rendezvous. -The fronting-based HTTP channel, however, -was much more capable, -bidirectional with reasonably high performance. -Rather than handing off the client to a flash proxy, +but just good enough for rendezvous. +The fronting-based HTTP\index{HTTP} channel, however, +was more capable than needed for rendezvous, +being bidirectional and reasonably high-performance. +Rather than handing off the client to a flash proxy\index{flash proxy}, it should be possible to carry all the client's traffic through the same domain-fronted channel. -It was during this time that I first became aware of GoAgent -through the ``Collateral Freedom'' report of Robinson et~al.~\cite{Robinson2013a}. -According to the report, GoAgent, -which used a less secure form of domain fronting than what meek would have, +It was around this time that I~first became aware of +the circumvention system GoAgent\index{GoAgent} +through the ``Collateral Freedom''\index{collateral freedom@``collateral freedom''}~\indexauthors{\cite{Robinson2013a}} +report of Robinson et~al. +GoAgent used an early form of domain fronting, +issuing HTTP\index{HTTP} requests directly from a Google App Engine\index{Google App Engine} server. +According to the report, GoAgent was the most used circumvention tool among -a group of users in China. -I read the source code of GoAgent in October 2013 -and wrote ideas about writing a similar pluggable transport~\cite{goagent-wiki} +a group of users in China\index{China}. +I~read the source code of GoAgent\index{GoAgent} in October 2013 +and wrote ideas about writing a similar pluggable transport~\cite{goagent-wiki}, which would become meek. -I lost time in premature optimization of meek's network performance. -I was thinking about the request--response nature of HTTP, +I~dithered for a while over what to call the system I~was developing. +Naming things is the worst part of software engineering. +My main criteria were that the name should not sound macho, +and that it should be easier to pronounce than ``obfs.'' +I~was self-conscious that the idea at the core of the system, +domain fronting +was a simple one and easy to implement. +Not wanting to oversell it, I~settled on the name ``meek,'' +in lower case for extra meekness. + +I~lost time in the premature optimization of meek's network performance. +I~was thinking about the request--response nature of HTTP\index{HTTP}, and how requests and responses could conceivably arrive out of order -(even if reordering was unlikely to occur in practice, because of the +(even if reordering was unlikely to occur in practice, because of keepalive connections and HTTP pipelining). -I made several attempts at a TCP-like reliability and sequencing layer, +I~made several attempts at a TCP-like\index{TCP} reliability and sequencing layer, none of which were satisfactory. -I wrote a simplified experimental prototype called ``meeker,'' -which simply prepended an HTTP header before the client and server streams, +I~wrote a simplified experimental prototype called ``meeker\index{meeker},'' +which simply prepended an HTTP\index{HTTP} header before the client and server streams, but meeker only worked for direct connections, -not through an HTTP-aware intermediary like App Engine. -When I explained these difficulties to George Kadianakis in December 2013, +not through an HTTP-aware intermediary like App Engine\index{Google App Engine}. +When I~explained these difficulties to +George Kadianakis\index{Kadianakis, George} in December 2013, he advised me to forget the complexity and implement the simplest thing that could work, which was good advice. -I started working on a version that strictly serialized request--response pairs, -which architecture meek still uses today. - +I~started implementing a version that strictly serialized +HTTP\index{HTTP} requests and responses. \subsection*{2014: Development; collaboration; deployment} -According to the Git revision history, -I started working on the source code of meek proper on January 26, 2014. -I made the first public announcement on January 31, 2014, +According to the Git\index{Git} revision history, +I~started working on the source code of meek proper on January 26, 2014. +I~made the first public announcement on January 31, 2014, in a post to the \mbox{tor-dev} mailing list\index{tor-dev mailing list} titled ``A simple HTTP transport and big ideas''~\cite{tor-dev-meek-announcement}. (If the development time seems short, -it's only because months of prototypes and false starts.) -In the post, I linked to the source code, +it's only because months of prototypes and false starts +cleared the way.) +In the post, I~linked to the source code, described the protocol, and explained how to try it, -using an App Engine instance I had set up shortly before. -At this time there was no web browser TLS camouflage, +using an App Engine\index{Google App Engine} instance I~set up shortly before. +At this time there was no web browser TLS camouflage\index{TLS!fingerprinting}, and only App Engine was supported. -I was not yet using the term ``domain fronting.'' -The ``big ideas'' of the title were as follows: +I~was not yet using the term ``domain fronting.'' +The big ideas of the title were as follows: we could run one big public bridge rather than relying on multiple smaller bridges as other transports did; -a web server with a PHP ``reflector'' script could do the same forwarding as a CDN, +a web server with a PHP\index{PHP} ``reflector'' script +could take the place of a CDN\index{content delivery network}, providing a diversity of access points even without domain fronting; -we could combine meek with authentication and serve a 404 +we could combine meek with authentication\index{authentication} and serve a 404\index{404 (HTTP status code)} to unauthenticated users; -and Cloudflare and other CDNs are alternatives to App Engine. +and Cloudflare\index{Cloudflare} and other CDNs\index{content delivery networks} +are alternatives to App Engine\index{Google App Engine}. We did end up running a public bridge for public benefit -(and worrying over how to pay for it), -and deploying on platforms other than App Engine -(with Tor we never used Cloudflare specifically, but did others). -Arlo Breault would write a PHP reflector, +(and later worrying over how to pay for it), +and deploying on platforms other than App Engine\index{Google App Engine} +(with Tor we use other CDNs, but not Cloudflare\index{Cloudflare} specifically). +Arlo Breault\index{Breault, Arlo} would write a PHP\index{PHP} reflector, though there was never a repository of public meek reflectors -as there were for other types of Tor bridge. -Combining meek with authentication never happened; +as there were for other types of Tor bridges\index{Tor bridges}. +Combining meek with authentication\index{authentication} never happened; it was never needed for our public domain-fronted instances because active probing doesn't help the censor in those cases anyway. During the spring 2014 semester (January--May) -I was enrolled in Vern Paxson's Internet/Network Security course -along with fellow student Chang Lan. +I~was enrolled in Vern Paxson's\index{Paxson, Vern} +Internet/Network Security\index{Internet/Network Security} course +along with fellow student Chang Lan\index{Lan, Change}. We made the development and security evaluation of meek our course project. -During this time we built browser TLS camouflage extensions, +During this time we built browser TLS camouflage extensions\index{TLS!fingerprinting}, tested and polished the code, and ran performance tests. Our final report, ``Blocking-resistant communication through high-value web services,'' -was the kernel of our later paper on domain fronting. +became the kernel of our later research paper. I~began the process of getting -meek integrated into Tor Browser in February 2014~\cite{tor-trac-10935}. +meek integrated into Tor Browser\index{Tor Browser} in February 2014~\cite{tor-trac-10935}. The initial integration would be completed in August 2014. In the intervening time, along with much testing and debugging, -Chang Lan and I~wrote browser extensions -for Chrome and Firefox in order to hide -the TLS fingerprint of the base meek client. -I~placed meek's code in the public domain -(Creative Commons CC0~\cite{cc0}) +Chang Lan\index{Lan, Chang} and I~wrote browser extensions +for Chrome\index{Chrome web browser} and Firefox\index{Firefox web browser} in order to hide +the TLS fingerprint\index{TLS!fingerprinting} of the base meek client. +I~placed meek's code in the public domain\index{public domain} +(Creative Commons CC0~\cite{cc0})\index{Creative Commons}\index{CC0} on February~8, 2014. The choice of (non-)license was a strategic decision to @@ -4079,164 +4516,198 @@ encourage adoption by projects other than Tor. % and the volunteers on the \mbox{tor-qa} mailing list\index{tor-qa mailing list} % for their assistance during this time especially. -In March 2014, I met some developers of Lantern -at a one-day hackathon sponsored by OpenITP~\cite{openitp-usability-hackathon}. -Lantern developer Percy Wegmann and I realized that the meek code I had been working on -could act as a glue layer between Tor and the HTTP proxy exposed by Lantern, -in effect allowing you to use Lantern as a pluggable transport for Tor. +In March 2014, I~met some developers of Lantern\index{Lantern} +at a one-day hackathon sponsored by OpenITP\index{OpenITP}~\cite{openitp-usability-hackathon}. +Lantern developer Percy Wegmann\index{Wegmann, Percy} +and I~realized that the meek code I~had been working on +could act as a glue layer between Tor\index{Tor} and the HTTP\index{HTTP} proxy exposed by Lantern, +in effect allowing you to use Lantern as a pluggable transport\index{pluggable transports} for Tor. We worked out a prototype and wrote a summary of the process~\cite{tor-dev-howto-use-lantern-pt}. -Even though our specific application that day did not use domain fronting, -the early contact with other circumvention developers was valuable. +In that specific application, we used meek not for its +domain-fronting properties but for its HTTP-tunneling properties; +but the early contact with other circumvention developers was valuable. June 2014 brought a surprise: -the Great Firewall of China blocked all Google services~\cite{google-transparency-cn-201405,greatfire-google-block-cn}. -It would be hubris to think that it was in response -to the nascent deployment of meek on App Engine; -a more likely cause was Google's decision to start using HTTPS +the Great Firewall of China\index{Great Firewall of China} +blocked all Google\index{Google} services~\cite{google-transparency-cn-201405,greatfire-google-block-cn}. +It would be vain to think that it was in response +to the nascent deployment of meek on App Engine\index{Google App Engine}; +a much more likely cause was Google's decision to begin using HTTPS\index{HTTPS} for web searches, -which would foil URL keyword filtering. +which would foil keyword-based URL\index{URL} filtering\index{detection!by content}\index{keywords}. Nevertheless, the blocking cast doubt on the feasibility of domain fronting: -I had believed that blocking all of Google would be too costly +I~had believed that blocking all of Google\index{Google} would be too costly in terms of collateral damage to be sustained for long -by any censor, even the Great Firewall, +by any censor, even the Great Firewall\index{Great Firewall of China}, and that belief was wrong. -At least, we now needed fronts other than Google -in order to have any claim of effective circumvention in China. -For that reason, I set up additional backends: -Amazon CloudFront and Microsoft Azure. -When meek made its debut in Tor Browser, -it would offer three modes: meek-google, meek-amazon, and meek azure. - -Google sponsored a summit of circumvention researchers -in June 2014. -I presented domain fronting there. -(By this time I had started using the term ``domain fronting,'' -realizing that what I had been working on needed a specific name. -I tried to separate the idea ``domain fronting'' +In any case, we now needed fronts other than Google\index{Google} +in order to have any claim of effective circumvention in China\index{China}. +I~set up additional backends: +Amazon CloudFront\index{Amazon CloudFront} +and Microsoft Azure\index{Microsoft Azure}. +When meek made its debut in Tor Browser\index{Tor Browser}, +it would offer three modes: meek-google\index{meek!meek-google}, +meek-amazon\index{meek!meek-amazon}, +and meek-azure\index{meek!meek-azure}. + +Google\index{Google} sponsored a summit of circumvention researchers +in June 2014, at which I~presented domain fronting. +(By this time I~had started using the term ``domain fronting,'' +realizing that what I~had been working on needed a specific name. +I~have tried to the idea ``domain fronting'' separate from the implementation ``meek,'' -but the terms have sometimes gotten confused in discourse.) -Developers from Lantern and Psiphon where there---I was -pleased to learn that Psiphon had already implemented and deployed -domain fronting, after reading my mailing list posts. -The meeting started a fruitful collaboration: -Percy Wegmann from Lantern -and Rod Hynes from Psiphon -would later be among my coauthors on the paper -on domain fronting~\cite{Fifield2015a-local}. - -Chang, Vern, and I submitted a paper on domain fronting to the -Network and Distributed System Security Symposium (NDSS) +but the two terms have sometimes gotten confused.) +Developers from Lantern\index{Lantern} and Psiphon\index{Psiphon} where there---I~was +pleased to learn that Psiphon\index{Psiphon} had already implemented and deployed +domain fronting after reading my mailing list posts. +The meeting started a fruitful collaboration +between the developers of Tor\index{Tor}, Lantern, and Psiphon. + +Chang\index{Chang, Lan}, Vern\index{Paxson, Vern}, and I\index{Fifield, David}~submitted +a paper on domain fronting to the +Network and Distributed System Security Symposium\index{Network and Distributed System Security Symposium} in August 2014, whence it was rejected. +One reviewer said the technique was already well known; +the others generally wanted to see more on the experience of deployment, +and a deeper investigation into resistance against +traffic analysis attacks +based on packet sizes and timing\index{packet size and timing}. -The first public release of Tor Browser that had +The first public release of Tor Browser\index{Tor Browser} that had a built-in easy-to-use meek client was version 4.0-alpha-1 on August 12, 2014~\cite{tor-blog-tor-browser-364-and-40-alpha-1-are-released}. -This was an alpha release, used by fewer users than the stable release. -I made a blog post explaining how to use it a few days later~\cite{tor-blog-how-use-meek-pluggable-transport}. +This was an alpha release\index{Tor Browser!alpha release}, +used by fewer users than the stable release\index{Tor Browser!stable release}. +I~made a blog post explaining how to use it a few days later~\cite{tor-blog-how-use-meek-pluggable-transport}. The release and blog post had a positive effect on the number of users, -however the absolute numbers are uncertain, -because of a configuration error I had made on the meek bridge. -I was running the meek bridge and the flash proxy bridge -on the same instance of Tor; +however the absolute numbers from around this time are uncertain, +because of a mistake I~made in configuring the meek bridge\index{Tor bridge}. +I~was running the meek bridge and the flash proxy\index{flash proxy} bridge +on the same instance of Tor\index{Tor}; and because of how Tor's statistics are aggregated, -the counts were spuriously correlated~\cite{tor-dev-user-counting-confusion}. -I switched the meek bridge to a separate instance of Tor +the counts of the two transports were spuriously correlated~\cite{tor-dev-user-counting-confusion}. +I~switched the meek bridge to a separate instance of Tor on September 15; numbers after that date are more trustworthy. In any case, the usage before this first release was tiny: -the App Engine bill (\$0.12/GB, with one~GB free each day) +the App Engine~\index{Google App Engine} bill, +at a rate of \$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, +\index{meek!costs of} +In August, the cost began to be nonzero every day, and would continue to rise from there. 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} +Tor Browser\index{Tor Browser} 4.0~\cite{tor-blog-tor-browser-40-released} was released on October 15, 2014. -It was the first stable (not alpha) release to have meek, +It was the first stable\index{Tor Browser!stable release} +(not alpha\index{Tor Browser!alpha release}) release to have meek, and it had an immediate effect on the number of users: -the estimate jumped from 50 to~500 within a week. +which jumped from 50 to~500 within a week. (The increase was partially conflated with -a failure of the meek-amazon bridge to publish statistics -before that date, but the other bridge, -servicing meek-google and meek-azure, +a failure of the meek-amazon\index{meek-amazon} bridge to publish statistics +before that date, but the other bridge\index{Tor bridge}, +servicing both meek-google\index{meek-google} and meek-azure\index{meek-azure}, individually showed the same increase.) It was a lesson in user behavior: -although there had been a working implementation -in the alpha release for two months already, +although meek had been available +in an alpha release\index{Tor Browser!alpha release} for two months already, evidently a large number of users did not know of it -or chose not to try it. +or chose not to try it +until the first stable release\index{Tor Browser!stable release}. At that time, the other transports available were -obfs3, FTE, ScrambleSuit, and flash proxy. +obfs3\index{obfs3}, +FTE\index{FTE}, +ScrambleSuit\index{ScrambleSuit}, +and flash proxy\index{flash proxy}. \subsection*{2015: Growth; restraints; outages} Through the first part of 2015, the estimated number of simultaneous users continued to grow, reaching about 2,000, -as we fixed bugs and Tor Browser had further releases. +as we fixed bugs and Tor Browser\index{Tor Browser} had further releases. +The first release of Orbot\index{Orbot} that included meek +appeared in February~\cite{guardian-dev-orbot-v15-alpha-3}. -We submitted a revised version of the domain fronting~\cite{Fifield2015a-local}, -now with contributions from Psiphon and Lantern, -to the Privacy Enhancing Technologies Symposium, +We submitted a revised version of the domain fronting paper~\indexauthors{\cite{Fifield2015a-local}}, +now with contributions from Psiphon\index{Psiphon} and Lantern\index{Psiphon}, +to the Privacy Enhancing Technologies Symposium\index{Privacy Enhancing Technologies Symposium}, where it was accepted and appeared on June~30 at the symposium. The increasing use of domain fronting by various circumvention tools began to attract more attention. A March 2015 article by Eva Dou and Alistair Barr -in the Wall Street Journal~\cite{DouBarrWallStreetJournal} -described domain fronting and ``collateral freedom'' in general, +in the Wall Street Journal\index{Wall Street Journal}~\indexauthors{\cite{DouBarrWallStreetJournal}} +described domain fronting and +``collateral freedom''\index{collateral freedom@``collateral freedom''} in general, depicting cloud service providers as being caught in the crossfire between censors and circumventors. -The journalists had contacted me but I declined to be interviewed. -The CEO of CloudFlare, through whose service Lantern had been fronting, -said that recently they had altered their systems to prevent domain fronting -by enforcing a match between SNI and Host header~\cite{PrinceCloudflareHackerNews}. -GreatFire, an anticensorship organization that had also been mentioned, -shortly thereafter experienced a new type of denial-of-service attack~\cite{greatfire-we-are-under-attack}, -caused by a Chinese network attack system later called the ``Great Cannon''~\cite{Marczak2015a-local}. +The journalists contacted me but I~declined to be interviewed; +I~thought it was not the right time for extra publicity, +and anyway personally did not want to deal with doing an interview. +Shortly thereafter, GreatFire\index{GreatFire}, an anticensorship organization that +was mentioned in the article, +experienced a new type of denial-of-service\index{denial of service} attack~\cite{greatfire-we-are-under-attack}, +caused by a Chinese\index{China} network attack system +later dubbed the Great Cannon\index{Great Cannon}~\cite{Marczak2015a-local}. They blamed the attack on the attention brought by the news article. - -Since initial deployment, the Azure backend +As further fallout, Cloudflare\index{Cloudflare}, +a CDN\index{content delivery network} which Lantern\index{Lantern} +used for fronting +and whose CEO was quoted in the article, +stopped supporting domain fronting~\cite{PrinceCloudflareHackerNews}, +by beginning to enforce a match between the SNI\index{Server Name Indication (SNI)} +and the Host header\index{Host (HTTP header)} + +Since its first deployment, the Azure\index{Microsoft Azure}\index{meek-azure} backend had been slower, with fewer users, than the other two options, -App Engine and CloudFront. -For months I had chalked it up to limitations of the platform. -In April 2015, though, I found the real source of the problem: -the code I had written to run on Azure, -the code that receives domain-fronted HTTP requests and forwards them -to the meek bridge, -was not reusing TCP connections. +App Engine\index{Google App Engine}\index{meek-google} +and CloudFront\index{Amazon CloudFront}\index{meek-amazon}. +For months I~had chalked it up to limitations of the platform. +In April 2015, though, I~found the real source of the problem: +the component I~wrote that runs on Azure, +receives domain-fronted HTTP\index{HTTP} requests and forwards them +to the meek bridge\index{Tor bridge}, +was not reusing TCP\index{TCP} connections. For every outgoing request, -the Azure code was doing a fresh TCP and TLS handshake---causing a bottleneck -at the CPU of the bridge, coping with all the incoming TLS. -When I fixed the Azure code to reuse connections~\cite{tor-dev-meek-azure-persistent}, -the number of users (overall, not only for Azure) -had a sudden jump, reaching 6,000 in less than a week. +the code was doing a fresh TCP\index{TCP} and TLS\index{TLS} handshake---causing a bottleneck +at the bridge as its CPU tried to cope with all the incoming TLS. +When I~fixed the code to reuse connections~\cite{tor-dev-meek-azure-persistent}, +the number of users (overall, not only for Azure\index{Microsoft Azure}) +had a sudden jump, increasing from 2,000 to reaching 6,000 in two weeks. Evidently, we had been leaving users on the table by having one of the backends not run as fast as possible. The deployment of domain fronting was being partly supported by a -\$500/month grant from Google. -Already the February 2015, the monthly cost for App Engine alone +\$500/month grant from Google\index{Google}. +Already in February 2015, the monthly cost for App Engine\index{Google App Engine} alone began to exceed that amount~\cite[\S Costs]{meek-wiki}. -In an effort to control costs, in May 2015 we began to rate-limit the -App Engine and CloudFront bridges, +In an effort to control costs, in May 2015 we began to rate-limit\index{rate limiting} the +App Engine\index{Google App Engine}\index{meek-google} +and CloudFront\index{Amazon CloudFront}\index{meek-amazon} bridges\index{Tor bridge}, deliberately slowing the service so that fewer would use it. -Until October 2015, the Azure bridge was on a research grant -provided by Microsoft, so we allowed it to run as fast as possible, -but when the grant expired, we rate-limited the Azure bridge as well. -The rate-limiting explains the relative flatness of the user graph +Until October 2015, the Azure\index{Microsoft Azure}\index{meek-azure} +bridge was on a research grant +provided by Microsoft\index{Microsoft}, so we allowed it to run as fast as possible. +When the grant expired, we rate-limited the Azure bridge as well. +This rate-limiting\index{rate limiting} explains the relative flatness of the user graph from May to the end of~2015. -Google changed the terms of service governing App Engine in 2015, -adding a paragraph that seemed to prohibit running a proxy service~\cite{google-cloud-service-terms-20150326000133}: +Google\index{Google} changed the terms of service\index{terms of service} governing +App Engine\index{Google App Engine} in 2015. +(I~received a message announcing the change in May, but it seems +the changes had been changed online since March.) +The updated terms included a paragraph +that seemed to prohibit running a proxy\index{proxy} service~\cite{google-cloud-service-terms-20150326000133}: % I and Yawning got notice of the change on 2015-05-20. The notice said: % • Add a restriction against using the Google Cloud Platform services to % provide network transport or sell bandwidth % Yawning quoted paragraph 10.2, while for me it was paragraph 13.2. -% However the Wayback Machine version of 2015-03-26 already has the new paragraph (numbere 10.2). +% However the Wayback Machine version of 2015-03-26 already has the new paragraph (numbered 10.2). % The version of 2015-01-14 does not have it. https://web.archive.org/web/20150114140104/https://cloud.google.com/terms/service-terms % The later version of 2015-04-06 also has it as paragraph 10.2. https://web.archive.org/web/20150406172008/https://cloud.google.com/terms/service-terms % The still later version of 2015-07-14 has it as paragraph 13.2. https://web.archive.org/web/20150714102030/https://cloud.google.com/terms/service-terms @@ -4244,321 +4715,349 @@ adding a paragraph that seemed to prohibit running a proxy service~\cite{google- \emph{Networking}. Customer will not, and will not allow third parties under its control to: (i)~use the Services to provide a service, Application, or functionality of network transport or transmission -(including, but not limited to, IP transit, virtual private networks, -or content delivery networks); or (ii)~sell bandwidth from the +(including, but not limited to, IP transit, virtual private networks\index{VPN}, +or content delivery networks\index{content delivery network}); or (ii)~sell bandwidth from the Services. \end{quote} -This was an uncomfortable time: -we seemed to have the support of Google, +This was a stressful time: +we seemed to have Google's\index{Google} support, but the terms of service said otherwise. -I contacted Google and asked for clarification or guidance, -in the meantime leaving meek-google running; -however I never got an answer to my questions. +I~contacted Google\index{Google} to ask for clarification or guidance, +in the meantime leaving meek-google\index{meek-google} running; +however I~never got an answer to my questions. The point became moot a year later, -when Google shut down our App Engine project, -for another reason altogether. +when Google\index{Google} shut down our App Engine\index{Google App Engine} project, +for another reason altogether; see below. -By this time we had not received any reports of any type of blocking of domain fronting. +By this time we had not received reports of any attempts to block domain fronting. We did, however, suffer a few accidental outages -(which look just like blocking, from a user's point of view). +(which are just as bad as blocking, from a client's point of view). Between July~20 and August~14, an account transition error -left the Azure configuration broken~\cite{tor-dev-meek-azure-outage-201508}. -I set up another configuration on Azure and published instructions on how to use it, -but it would not be available to the majority of users until the next release of Tor Browser, +left the Azure\index{meek-azure} +configuration broken~\cite{tor-dev-meek-azure-outage-201508}. +I~set up another configuration on Azure and published instructions on how to use it, +but it would not be available to the majority of users until the next release of Tor Browser\index{Tor Browser}, which happened on August~11. -Between September~30 and October~9, the CloudFront-fronted bridge -was effectively down because of an expired TLS certificate. +Between September~30 and October~9, the CloudFront\index{meek-amazon} bridge +was effectively down because of an expired TLS\index{TLS} certificate\index{certificate}. When it rebooted on October~9, an administrative oversight caused its Tor relay identity fingerprint to change---meaning -that clients expecting the former fingerprint would refuse +that clients expecting the former fingerprint refused to connect to it~\cite{tor-trac-17473}. The situation was not fully resolved until November~4 -with the next release of Tor Browser: +with the next release of Tor Browser\index{Tor Browser}: cascading failures led to over a month of downtime. In October 2015 there appeared a couple of research papers that investigated meek's susceptibility to detection via side channels. -Tan et~al.~\cite{Tan2015a} -(including Binxing Fang, the ``father of the Great Firewall'') +Tan et~al.~\indexauthors{\cite{Tan2015a}} used Kullback--Leibler divergence\index{Kullback--Leibler divergence} to quantify the differences between protocols, with respect to packet size -and interarrival time distributions. -Their paper is written in Chinese, -so I~had to read it in machine translation. -Wang et~al.~\cite{Wang2015a} +and interarrival time distributions\index{packet size and timing}. +Their paper is written in Chinese\index{Chinese}; +I~read it in machine translation. +Wang et~al.~\indexauthors{\cite{Wang2015a}} published a more comprehensive report on detecting meek (and other protocols), emphasizing practicality and precision. They showed that some previously proposed -detections would have untenable false-positive rates, +classifiers would have untenable false-positive rates\index{false positives}, and constructed a classifier for meek -based on entropy and timing features. +based on entropy\index{entropy} and timing features\index{packet size and timing}. It's worth noting that since the first reported efforts to block meek in 2016, -censors have not used techniques like those -described in these papers, -as far as we can tell. +censors have preferred, +as far as we can tell, +to use techniques other than those +described in these papers. -One of the benefits of building a circumvention system for Tor -is the easy integration with Tor Metrics---the source of the user +A~side benefit of building a circumvention system atop Tor\index{Tor} +is easy integration with Tor Metrics\index{Tor Metrics}---the source of the user number estimates in this section. Since the beginning of meek's deployment, we had known about a problem -with the way it integrates with Tor Metrics' data collection. -Tor pluggable transports geolocate the client's IP address +with the way it integrates with Tor Metrics\index{Tor Metrics}. +Tor\index{Tor} pluggable transports\index{pluggable transports} +geolocate\index{geolocation} the client's IP address in order to aggregate statistics by country. -But when a meek bridge receives a connection, the ``client IP address'' -it sees is not that of the true client, but rather is -some cloud server, the intermediary through which the domain-fronted +But when a meek bridge\index{Tor bridge} receives a connection, +the ``client IP address'' +it sees is not that of the true client, but rather that of +some cloud server, the intermediary through which the client's domain-fronted traffic passes. -So the total counts were fine, but the per-country counts were meaningless. -For example, because App Engine's servers were located in the U.S., -every meek-google connection was being counted in the U.S. bucket. -By the end of 2015, meek users were a large enough fraction (about~20\%) -of all bridge users, that they were really starting to skew the overall per-country counts. -I wrote a patch to have the client's true IP address forwarded -through the network intermediary in a special HTTP header, +So the total user counts were fine, but the per-country counts were meaningless. +For example, because App Engine's\index{Google App Engine} servers were located in the U.S.\index{United States of America}, +every meek-google connection was being counted as if it +belonged to a client in the U.S.\index{United States of America}\ By +the end of 2015, meek users were a large enough fraction (about~20\%) +of all bridge users that they were skewing the overall per-country counts. +I~wrote a patch~\cite{tor-trac-13171} to have the client's true IP address forwarded +through the network intermediary in a special HTTP\index{HTTP} header, which fixed the per-country counts from then on. \subsection*{2016: Taking off the reins; misuse; blocking efforts} -In mid-January 2016 the Tor Project asked me to raise -the rate limits on the meek bridges, in anticipation -of rumored attempts to block Tor in Egypt. -(The blocking attempts were in turn rumored to be caused -by Facebook's integration of Tor into their mobile application.) -I had the bridge operators raise the rate limits +In mid-January 2016 the Tor Project\index{Tor Project, The} asked me to raise +the rate limits\index{rate limiting} on the meek bridges, in anticipation +of rumored attempts to block\index{blocking} Tor\index{Tor} in Egypt\index{Egypt}. +I~asked the bridge operators raise the limits from approximately 1~MB/s to 3~MB/s. -The effect of the relaxed rate limits was immediate: +The effect of the relaxed rate limits\index{rate limiting} was immediate: the count shot up as high 15,000 simultaneous users, -briefly becoming Tor's most-used pluggable transport, -before settling in around 10,000. +briefly making meek Tor's\index{Tor} most-used pluggable transport\index{pluggable transports}, +before settling in at around 10,000. The first action that may have been a deliberate attempt to block domain fronting came on January~29, 2016, -when the Great Firewall of China blocked one of the edge servers -of the Azure CDN. -The blocking was by IP address, a severe method: -not only the domain name we were using for domain fronting, -but also thousands of other names, +when the Great Firewall of China\index{Great Firewall of China} +blocked one of the edge servers\index{edge server} +of the Azure\index{Microsoft Azure} CDN\index{content delivery network}. +The blocking was by IP address\index{blocking!by address}, a severe method: +not only the domain name we were using for fronting, +but thousands of other names became inaccessible. The block lasted about four days. -On February~2, the server changed its IP address, -incrementing the final octet from\ .200 to~.201, +On February~2, the server changed its IP address +(simply incrementing the final octet from\ .200 to~.201), causing it to become unblocked. -I am aware of no similar incidents before or since. +I~am aware of no other incidents of edge server blocking. \phantomsection \label{para:meek-suspension} The next surprise was on May~13, 2016. -meek's App Engine backend stopped working and I got a notice: +meek's App Engine\index{Google App Engine} backend\index{meek-google} +stopped working and I~got a notice: \begin{quote} -We've recently detected some activity on your Google Cloud Platform/API Project ID meek-reflect that appears to violate our Terms of Service. Please take a moment to review the Google Cloud Platform Terms of Service or the applicable Terms of Service for the specific Google API you are using. +We've recently detected some activity on your Google Cloud Platform\index{Google Cloud Platform}/API Project ID meek-reflect that appears to violate our Terms of Service\index{terms of service}. Please take a moment to review the Google Cloud Platform Terms of Service or the applicable Terms of Service for the specific Google API you are using. Your project is being suspended for committing a general terms of service violation. We will delete your project unless you correct the violation by filling in the appeals form available on the project page of Developers Console to get in touch with our team so that we can provide you with more details. \end{quote} -My first thought was that it had to do with the changes -to the terms of service that had happened the previous year---but -the true cause was unexpected. -I tried repeatedly to contact Google and learn the nature -of the ``general'' violation, but was stonewalled. -None of my inquiries received so much as an acknowledgement. -It as not until June~18 that I got some insight -as to what happened, -through an unofficial channel. -Some botnet had apparently been misusing meek for command and control purposes; -and its operators hadn't even bothered to set up their own App Engine project. -They were using the service that we had been operating for the public. -Although we may have been able to reinstate the meek-google service, -seeing as the suspension was the result of someone else's botnet, -with the already uncertain standing with regard to the terms of service -I didn't have the heart to pursue it. -meek-google remained off and users migrated to -meek-amazon or meek-azure. -It turned out, later, that it had been no common botnet -misusing meek-google, but an organized political hacker group, -known as Cozy Bear\index{Cozy Bear}\index{APT29|see {Cozy Bear}} +My first thought---which turned out to be wrong---was that it was because of the changes +to the terms of service\index{terms of service} that had been announced the previous year. +I~tried repeatedly to contact Google~\index{Google} and learn the nature +of the violation, +But none of my inquiries received even an acknowledgement. +It was not until June~18 that I~got some insight, +through an unofficial channel, +about what happened. +Some botnet\index{botnet} had apparently been misusing meek for +command and control\index{command and control} purposes. +Its operators had not even bothered to set up their own App Engine\index{Google App Engine} project; +they were freeriding on the service we had been operating for the public. +Although we may have been able to reinstate the meek-google\index{meek-google} service, +seeing as the suspension was the result of someone else's actions, not ours, +with the existing uncertainty around the terms of service\index{terms of service} +I~didn't have the heart to pursue it. +meek-google\index{meek-google} remained off, and users migrated to +meek-amazon\index{meek-amazon} or meek-azure\index{meek-azure}. +It turned out, later, that it had been no common botnet\index{botnet} +misusing meek-google\index{meek-google}, but an organized political hacker group, +known as Cozy Bear\index{Cozy Bear} or APT29. Matthew Dunwoody presented observations to that effect -in a FireEye blog post~\cite{fireeye-apt29_domain_frontin} +in a FireEye blog post~\indexauthors{\cite{fireeye-apt29_domain_frontin}} in March 2017. -He and Nick Carr had presented those findings at DerbyCon -in September 2016~\cite{DunwoodyCarrDerbyCon2016}, -but I was not aware of them until the blog post. -Malware would install a backdoor that operated over a Tor -onion service, and used meek for camouflage. +The malware would install a backdoor that operated over a Tor +onion service\index{onion service}, and used meek for camouflage. +He and Nick Carr had earlier presented those findings at DerbyCon\index{DerbyCon} +in September 2016~\indexauthors{\cite{DunwoodyCarrDerbyCon2016}}, +but I~was not aware of them until the blog post. The year 2016 brought the first reports of efforts to block meek. -These efforts all had in common that they used TLS fingerprinting -in conjunction with SNI inspection. -In May, a Tor user reported that Cyberoam\index{Cyberoam firewall}, -a firewall company, had released an update that enabled detection and blocking -of meek, among other Tor pluggable transports~\cite{tor-dev-cyberoam}. +These efforts all had in common that they used TLS fingerprinting\index{TLS!fingerprinting}\index{blocking!by content} +in conjunction with SNI\index{Server Name Indication (SNI)} inspection\index{blocking!by address}. +In May, a Tor user reported that Cyberoam\index{Cyberoam}, +a firewall company, had released an update that enabled detection\index{detection} and blocking\index{blocking} +of meek, among other Tor pluggable transports\index{pluggable transports}~\cite{tor-dev-cyberoam}. Through experiments we determined that the firewall was detecting meek whenever it saw a combination of two features: a specific client TLS fingerprint, -and an SNI containing any of our three front domains: -\nolinkurl{www.google.com}, \nolinkurl{a0.awsstatic.com}, -or \nolinkurl{ajax.aspnetcdn.com}~\cite{traffic-obf-cyberoam}. -We verified that changing either the TLS fingerprint -or the front domain was sufficient to escape detection. +and an SNI\index{Server Name Indication (SNI)} containing any of our three front domains\index{front domain}: +\nolinkurl{www.google.com}\index{www.google.com@\nolinkurl{www.google.com}}, +\nolinkurl{a0.awsstatic.com}\index{a0.awsstatic.com@\nolinkurl{a0.awsstatic.com}}, or +\nolinkurl{ajax.aspnetcdn.com}\index{ajax.aspnetcdn.com@\nolinkurl{ajax.aspnetcdn.com}}~\cite{traffic-obf-cyberoam}. +We verified that changing either the TLS fingerprint\index{TLS!fingerprinting} +or the front domain\index{front domain} was sufficient to escape detection. Requiring both features to be present was a clever move -by the firewall to limit collateral damage: +by the firewall to limit collateral damage\index{collateral damage}: it did not block those domains for all clients, -but only the subset having a particular TLS fingerprint. -I admit that I had not considered the possibility -of using TLS and SNI together to make a more precise classifier. +but only for the subset having a particular TLS fingerprint\index{TLS!fingerprinting}. +I~admit that I~had not considered the possibility +of using TLS\index{TLS} and SNI\index{Server Name Indication (SNI)} together to make a more precise classifier. We had known since the beginning of the possibility of TLS fingerprinting, -which is why we spent the time to implement browser-based TLS camouflage. -And there was no error in the camouflage: -even an ordinary Firefox~38 -(the base for Tor Browser, and what meek camouflaged itself as) -was blocked by the firewall when accessing one of the three front domains. +which is why we took the trouble to implement browser-based TLS camouflage. +The camouflage was performing as intended: +even an ordinary Firefox~38\index{Firefox web browser} +(the basis of Tor Browser\index{Tor Browser}, and what meek camouflaged itself as) +would be blocked by the firewall when accessing one of the three listed domains\index{front domain}. However, Firefox~38 was by that time a year old. -I found a source saying that it made up only 0.38\% -of desktop browsers, compared to 10.69\% for the then-latest Firefox~45~\cite{traffic-obf-cyberoam}. +I~found a source~\cite{traffic-obf-cyberoam} saying that +at that time, Firefox~38 made up only 0.38\% +of desktop browsers, compared to 10.69\% for the then-latest Firefox~45 My guess is that the firewall makers considered the small amount -of collateral blocking of Firefox~38 users to be acceptable. - -In July I received a report of similar behavior -by a FortiGuard firewall\index{FortiGuard firewall}~\cite{traffic-obf-fortiguard} -from Tor user Kanwaljeet Singh Channey. -The situation was virtually the same: -the firewall would block connections having a specific TLS fingerprint -and a specific SNI. -This time, the TLS fingerprint was that of Firefox~45 -(which by then Tor Browser had upgraded to); -and the specific SNIs were only two, omitting \nolinkurl{www.google.com}. -(This meant that meek-google would have worked, -had it not been deactivated back in May.) -As in the Cyberoam case, -changing either the TLS fingerprint or the front domain +of collateral blocking\index{collateral damage} of +genuine Firefox~38 users to be acceptable. + +In July I~received a report of similar behavior +by a FortiGuard firewall\index{FortiGuard}~\cite{traffic-obf-fortiguard} +from Tor user Kanwaljeet Singh Channey\index{Channey, Kanwaljeet Singh}. +The situation was virtually the same as in the Cyberoam\index{Cyberoam} case: +the firewall would block connections having a specific TLS fingerprint\index{TLS!fingerprint}\index{blocking!by content} +and a specific SNI\index{Server Name Indication (SNI)}\index{blocking!by address}. +This time, the TLS fingerprint was that of Firefox~45\index{Firefox web browser} +(which by then Tor Browser\index{Tor Browser} had upgraded to); +and the specific SNIs were two, not three, omitting +\nolinkurl{www.google.com}\index{www.google.com@\nolinkurl{www.google.com}}. +As in the previous case, +changing either the TLS fingerprint\index{TLS!fingerprinting} or the front domain\index{front domain} was sufficient to get through the firewall. For reasons not directly related to domain fronting or meek, -I had been interested in the blocking situation in Kazakhstan, -ever since Tor Metrics reported a sudden drop of Tor users +I~had been interested in the blocking situation in Kazakhstan\index{Kazakhstan}, +ever since Tor Metrics\index{Tor Metrics} reported a sudden drop in the number of users in that country in June 2016~\cite{kazakhstan-wiki}. -I worked with an anonymous collaborator, who reported +(See \autoref{sec:proxy-probe-kazakhstan} for other results from Kazakhstan.) +I~worked with an anonymous collaborator\index{Anonymous}, who reported that meek was blocked in the country since October 2016 or earlier. -According to them, changing the front domain would evade the block, -but changing the TLS fingerprint didn't help. -I did not independently confirm these reports. -Kazakhstan remains the only case of country-level meek blocking -that I am aware of. +According to them, changing the front domain\index{front domain} would evade the block, +but changing the TLS fingerprint\index{TLS!fingerprinting} didn't help. +I~did not independently confirm these reports. +Kazakhstan\index{Kazakhstan} remains the only case of country-level blocking of meek +that I~am aware of. Starting in July 2016, there was a months-long increase -in the number of meek users reported from Brazil~\cite{tor-metrics-userstats-bridge-combined-br}. +in the number of meek users reported from Brazil\index{Brazil}~\cite{tor-metrics-userstats-bridge-combined-br}. The estimated count went from around 100 to almost 5,000, peaking in September 2016 before declining again. During parts of this time, over half of all reported meek users were from Brazil. We never got to the bottom of why there should be so many -users reported from Brazil in particular. +users reported from Brazil\index{Brazil} in particular. The explanation may be some kind of anomaly; for instance some third-party software that happened to use meek, or a malware infection like the one that caused the shutdown -of meek-google. -The count dropped suddenly, from 1,500 almost to zero, +of meek-google\index{meek-google}. +The count of users from Brazil\index{Brazil} dropped suddenly, +from 1,500 almost to zero, on March~3, 2017, which happened also to be the day -that meek-azure was shut down pending a migration to new infrastructure. -The count would remain low until rising again in June 2017. +that I~shut down meek-azure\index{meek-azure} +pending a migration to new infrastructure. +The Brazil\index{Brazil} count would remain low until rising again in June 2017. -In September 2016, I began mentoring Katherine Li -in making her program GAEuploader~\cite{LiGAEuploader}, -which aims to simplify and automate the process of +In September 2016, I~began mentoring Katherine Li\index{Li, Katherine} +in writing a program GAEuploader\index{GAEuploader}~\cite{LiGAEuploader}, +to simplify and automate the process of setting up domain fronting. The program automatically uploads the necessary code -to Google App Engine, -then outputs a bridge line ready to be pasted into Tor Browser or Orbot. +to Google App Engine\index{Google App Engine}, +then outputs a bridge specification +ready to be pasted into Tor Browser\index{Tor Browser} or Orbot\index{Orbot}. We hoped also that the code would be useful to other projects, -like XX-Net~\cite{xx-net}, -that provide documentation on the complicated process of -uploading code to App Engine. -GAEuploader had a beta release in January 2017~\cite{tor-dev-gaeuploader}; -however the effect on the number of users was not substantial. +like XX-Net\index{XX-Net}~\cite{xx-net}, +that require users to perform the complicated task of +uploading code to App Engine\index{Google App Engine}. +GAEuploader\index{GAEuploader} had beta releases in January~\cite{tor-dev-gaeuploader} +and November~\cite{tor-dev-gaeuploader-windows} 2017; +however the effect on the number of users has so far not been substantial. Between October~19 and November~10, 2016, the number of meek users decreased globally by about a third~\cite{tor-trac-20495}. -Initially I suspected a censorship event, +Initially I~suspected a censorship event, but the other details didn't add up: -the numbers were depressed and later recovered +the numbers decreased and later recovered simultaneously across many countries, including ones not known for censorship. Discussion with other developers revealed the likely cause: -a botched release of Orbot that left some users unable to +a botched release of Orbot\index{Orbot} that left some users unable to use the program~\cite{traffic-obf-meek-decrease-orbot}. Once a fixed release was available, user numbers recovered. -An unanticipated effect of this occurrence was that +As an side effect of this event, we learned that a majority of meek users -were using Orbot rather than Tor Browser. +were using Orbot\index{Orbot} rather than Tor Browser\index{Tor Browser}. \subsection*{2017: Long-term support} -In January 2017, the grant I had been using to pay meek-azure's +In January 2017, a grant I~had been using to pay meek-azure's\index{meek-azure} bandwidth bills ran out. -Lacking the means to keep it running, I announced my intention to +Lacking the means to keep it running, I~announced my intention to shut it down~\cite{tor-dev-meek-azure-run-out}. -Shortly thereafter, Team Cymru offered to stand up -their own instances and pay the CDN fees, -and so we made plans to migrate meek-azure +Shortly thereafter, Team Cymru\index{Team Cymru} offered to set up +their own instances and pay the CDN\index{content delivery network} fees, +and so we made plans to migrate meek-azure\index{meek-azure} to the new setup in the next releases. -For cost reasons, though, I still had to shut down -the old configuration before the new release -of Tor Browser was ready. -I shut down my configuration on March~3. -The next release of Tor Browser was on March~7, -and the next release of Orbot was on March~22: +For cost reasons, though, I~still had to shut down\index{meek!costs of} +the old configuration before the new releases +of Tor Browser\index{Tor Browser} and Orbot were fully ready. +I~shut down my configuration on March~3. +The next release of Tor Browser\index{Tor Browser} was on March~7, +and the next release of Orbot\index{Orbot} was on March~22: so there was a period of days or weeks during which -meek-azure was completely non-functional for users. +meek-azure\index{meek-azure} was non-functional. It would have been better to allow the two configurations to run concurrently for a time, so that users of the old would be able to transparently -upgrade to the new---but in this case it wasn't possible. -Perhaps not coincidentally, the surge of users from Brazil, +upgrade to the new---but for cost reasons it was not possible. +Perhaps not coincidentally, the surge of users from Brazil\index{Brazil}, which had started in July 2016, -ceased on March~3, the same day I shut down meek-azure before its migration. +ceased on March~3, the same day I~shut down meek-azure\index{meek-azure} before its migration. Handing over control of the infrastructure was a relief to me. -I had managed to make sure the monthly bills got paid, -but it took more care and attention than I liked. +I~had managed to make sure the monthly bills got paid\index{meek!costs of}, +but it took more care and attention than I~liked. A negative side effect of the migration was that -I stopped writing monthly summaries of costs, -because I was no longer receiving bills. +I~stopped writing monthly summaries of costs, +because I~was no longer receiving bills. -Also in January 2017, I became aware of the firewall company -Allot Communications, thanks to my anonymous collaborator -in the Kazakhstan work. +Also in January 2017, I~became aware of the firewall company +Allot Communications\index{Allot Communications}, +thanks to my anonymous collaborator +in the work Kazakhstan work\index{Kazakhstan}. 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)'' +including Tor\index{Tor} pluggable transports\index{pluggable transports}, +Psiphon\index{Psiphon}, +and various VPN\index{VPN} services~\cite{traffic-obf-allot}. +They claimed detection of ``Psiphon CDN (Meek mode)'' going back to January 2015, -and for ``TOR (CDN meek)'' going back to April 2015. +and of ``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. +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 +In June 2017, the estimated user count from Brazil\index{Brazil} +began to increase again~\cite{tor-metrics-userstats-bridge-combined-br}, +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. +% 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} +The rest of 2017 was fairly quiet. +Starting in October, there were reports from China\index{China} +of the disruption of look-like-nothing transports +such as obfs4 and Shadowsocks~\cite{traffic-obf-disrupting-shadowsocks}, +perhaps related to the National Congress +of the Communist Party of China\index{National Congress (Communist Party of China)} +that was then about to take place. +The disruption did not affect meek or other systems based on domain fronting; +in fact the number of meek users in China +roughly doubled during that time. + +\index{meek!history of|)} + +\index{domain fronting|)textbf} \chapter{Snowflake} \label{chap:snowflake} +\index{Snowflake|(textbf} + Snowflake is a new circumvention system currently under development. It is based on peer-to-peer connections through lightweight, ephemeral proxies @@ -4585,28 +5084,28 @@ 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} +its use of the TCP-based\index{TCP} WebSocket\index{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}, +but replaces WebSocket\index{WebSocket} with WebRTC~\cite{draft-ietf-rtcweb-overview}\index{WebRTC}, a suite of protocols for peer-to-peer communications. -Importantly, WebRTC is UDP-based +Importantly, WebRTC uses UDP\index{UDP} for communication, 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}.) +the use of WebRTC\index{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 +using WebRTC\index{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 @@ -4616,15 +5115,18 @@ 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. -The name ``Snowflake'' comes from one of WebRTC's subprotocols, +The name ``Snowflake'' comes from one of WebRTC's\index{WebRTC} subprotocols, called ICE (Interactive Connectivity Establishment)~\cite{rfc5245}, and from the temporary proxies, which resemble snowflakes in their impermanence and uniqueness. Snowflake now exists in an experimental alpha release, -incorporated into Tor Browser. +incorporated into Tor Browser\index{Tor Browser}. My main collaborators on the Snowflake project are -Arlo Breault, Mia Gil~Epner, Serene Han, and Hooman Mohajeri. +Arlo Breault\index{Breault, Arlo}, +Mia Gil~Epner\index{Gil Epner, Mia}, +Serene Han\index{Han, Serene}, and +Hooman Mohajeri Moghaddam\index{Moghaddam, Hooman Mohajeri}. \section{Design} @@ -4632,7 +5134,7 @@ Arlo Breault, Mia Gil~Epner, Serene Han, and Hooman Mohajeri. \begin{figure} \centering -\placeholder{3in} +\includegraphics{figures/snowflake} \caption{ Schematic of Snowflake. } @@ -4644,7 +5146,7 @@ Refer to \autoref{fig:snowflake}. \begin{itemize} \item many \emph{snowflake proxies} (``snowflakes'' for short), -which communicate with clients using WebRTC and forward +which communicate with clients using WebRTC\index{WebRTC} and forward their traffic to the bridge \item many \emph{clients}, responsible for @@ -4660,7 +5162,7 @@ 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, +and the nature of WebRTC\index{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, @@ -4671,14 +5173,14 @@ 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. +necessary for a WebRTC\index{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. +metadata needed to establish a WebRTC\index{WebRTC} connection. How the client sends its offer is further explained below. \item At some point, a snowflake comes online @@ -4695,23 +5197,22 @@ 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. +to establish a WebRTC\index{WebRTC} connection to each other. \begin{enumerate}[resume] \item The client and snowflake proxy -connect to each other using WebRTC. +connect to each other using WebRTC\index{WebRTC}. \item The snowflake proxy connects to the bridge -(using WebSocket, though the specific type of channel +(using WebSocket\index{WebSocket}, though the specific type of channel does not matter for this step). -\item -The snowflake proxy copies data back and forth +\end{enumerate} +The snowflake proxy then 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, +the WebRTC\index{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, @@ -4724,8 +5225,8 @@ 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. +The client's single request uses domain fronting\index{domain fronting!as rendezvous for Snowflake}\index{Snowflake!rendezvous} +and those of the snowflakes 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 @@ -4747,28 +5248,7 @@ 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} +\includegraphics{figures/snowflake-rendezvous} \caption{ Snowflake rendezvous. The client makes only one HTTP request--response pair. @@ -4777,17 +5257,24 @@ 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. } +\index{GET (HTTP method)} +\index{POST (HTTP method)} +\index{HTTP} +\index{200 (HTTP status code)} +\index{domain fronting!as rendezvous for Snowflake} +\index{Snowflake!rendezvous} \label{fig:snowflake-rendezvous} \end{figure} 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 +The answer is that it does suffice---that's the idea +behind meek (\autoref{sec:meek-history}). +The disadvantage of building a system +exclusively on domain fronting is high monetary cost (see \autoref{tab:meek-costs} on page~\pageref{tab:meek-costs}). -Snowflake offloads the bulk of data transfer onto WebRTC, +Snowflake offloads the bulk of data transfer onto WebRTC\index{WebRTC}, and uses expensive domain fronting only for rendezvous. There are two reasons why the snowflake proxies @@ -4811,18 +5298,18 @@ This is essentially untrusted messenger delivery~\cite{Feamster2003a}, proposed by Feamster et~al.\ in~2003. -WebRTC offers two features that are necessary for Snowflake: +WebRTC\index{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. +In other respects, though, WebRTC\index{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, +WebRTC\index{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, @@ -4835,6 +5322,8 @@ as discussed in the next section. \section{WebRTC fingerprinting} \label{sec:webrtc-fingerprinting} +\index{WebRTC!fingerprinting|(} + Snowflake primarily tackles the problem of detection by address. The pool of temporary proxies changes too quickly @@ -4848,26 +5337,26 @@ 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. +WebRTC\index{WebRTC} fingerprinting. -Snowflake will always look like WebRTC---that's +Snowflake will always look like WebRTC\index{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. +those other uses of WebRTC\index{WebRTC}. Mia Gil~Epner and I~began an investigation into the potential fingerprintability of -WebRTC~\cite{FifieldGilEpnerWebRTC,snowflake-fingerprinting-wiki}. +WebRTC~\cite{FifieldGilEpnerWebRTC,snowflake-fingerprinting-wiki}\index{WebRTC}. 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, +WebRTC\index{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 @@ -4875,7 +5364,7 @@ to find places where implementation choices could facilitate fingerprinting. \begin{description} \item[Signaling] -Signaling is WebRTC's term for the exchange of +Signaling\index{WebRTC!signaling} is WebRTC's\index{WebRTC} 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}; @@ -4901,7 +5390,7 @@ 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) +WebRTC\index{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, @@ -4929,15 +5418,15 @@ the client's offered ciphersuites, and values in the server's certificate. \end{description} -Snowflake uses a WebRTC library extracted +Snowflake uses a WebRTC\index{WebRTC} library extracted from the Chromium web browser, which mitigates some potential -dead-parrot distinguishers~\cite{Houmansadr2013b}. +dead-parrot distinguishers~\cite{Houmansadr2013b}\index{dead-parrot attacks}. 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 +We conducted a survey of some WebRTC-using\index{WebRTC} applications in order to get an idea of the implementation choices being made in practice. We tested three applications that use media channels, @@ -4970,15 +5459,34 @@ 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 +these results suggest that WebRTC\index{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. +\index{WebRTC!fingerprinting|)} + +\index{Snowflake|)} + + +\chapter{Don't call it a conclusion} -% \chapter{Don't call it a conclusion} +\dragons + +Computer security is already on shaky ground +even when we are dealing with trustworthy endpoints. +How much harder it is when users' +own computers must be counted among the threats they face. +People already have an adversarial relationship +with the hostile apps on their phones +free software + +Let us strive, therefore, +to control the pace, +and spend whatever time remains in the race +winning, not losing. % Probably the circumstances of the world change % and make irrelevant this field of study. @@ -4987,12 +5495,16 @@ because Hangouts does not use DTLS. \backmatter -\printbibliography[heading=bibintoc] +\defbibnote{bibnote}{\todo[inline]{Note about archived URLs.}} +\printbibliography[heading=bibintoc,prenote=bibnote] + +\clearpage +\phantomsection +\addcontentsline{toc}{chapter}{\indexname} + +\setindexprenote{\dragons} -% \clearpage -% \phantomsection -% \addcontentsline{toc}{chapter}{\indexname} -% \printindex +\printindex \end{CJK} \end{document}