-
Notifications
You must be signed in to change notification settings - Fork 0
/
pt-scary.tex
324 lines (302 loc) · 18.8 KB
/
pt-scary.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
% ================================================================================
\documentclass[sigconf, screen]{acmart}
\usepackage{booktabs} % For formal tables
\usepackage{graphicx}
\usepackage{comment}
\usepackage{url}
\usepackage{hyperref}
\usepackage{listings}
\usepackage[n, advantage, operators, sets, adversary, landau, probability, notions, logic, ff, mm, primitives, events, complexity, asymptotics, keys]{cryptocode}
% Copyright
\setcopyright{none}
%\setcopyright{acmcopyright}
%\setcopyright{acmlicensed}
%\setcopyright{rightsretained}
%\setcopyright{usgov}
%\setcopyright{usgovmixed}
%\setcopyright{cagov}
%\setcopyright{cagovmixed}
% ================================================================================
% DOI
%\acmDOI{10.475/123_4}
% ================================================================================
%Conference
%\acmConference[WOODSTOCK'97]{ACM Woodstock conference}{July 1997}{El Paso, Texas USA}
%\acmYear{1997}
%\copyrightyear{2016}
%\acmArticle{4}
%\acmPrice{15.00}
% ================================================================================
% These commands are optional
%\acmBooktitle{Transactions of the ACM Woodstock conference}
%\editor{ABC}
% ================================================================================
\begin{document}
% ================================================================================
\title{Scary: A really scary Pluggable Transport}
% ================================================================================
%\titlenote{Produces the permission block, and copyright information}
\subtitle{... or the magic of obscuration for Tor.}
\subtitlenote{The author believes in the importance of the independence of research and is funded by the public community. If you also believe in this values, you can find ways for supporting the author's work here: \url{https://research.carolin-zoebelein.de/crowdfunding.html}}
% ================================================================================
\author{Carolin Z\"obelein}
\authornote{\url{https://research.carolin-zoebelein.de}, \textit{E-mail address:} [email protected], PGP: D4A7 35E8 D47F 801F 2CF6 2BA7 927A FD3C DE47 E13B}
\affiliation[obeypunctuation=true]{
\institution{Independent mathematical scientist}\\
\streetaddress{Josephsplatz 8},
\postcode{90403}
\city{N\"urnberg},
\country{Germany}
}
% ================================================================================
\begin{abstract} % TODO
STATUS: Draft
%This paper provides a sample of a \LaTeX\ document which conforms,
%somewhat loosely, to the formatting guidelines for
%ACM SIG Proceedings.\footnote{This is an abstract footnote}
\end{abstract}
% ================================================================================
%
% The code below should be generated by the tool at
% http://dl.acm.org/ccs.cfm
% Please copy and paste the code instead of the example below.
%
\begin{comment} % TODO
\begin{CCSXML}
<ccs2012>
<concept>
<concept_id>10010520.10010553.10010562</concept_id>
<concept_desc>Computer systems organization~Embedded systems</concept_desc>
<concept_significance>500</concept_significance>
</concept>
<concept>
<concept_id>10010520.10010575.10010755</concept_id>
<concept_desc>Computer systems organization~Redundancy</concept_desc>
<concept_significance>300</concept_significance>
</concept>
<concept>
<concept_id>10010520.10010553.10010554</concept_id>
<concept_desc>Computer systems organization~Robotics</concept_desc>
<concept_significance>100</concept_significance>
</concept>
<concept>
<concept_id>10003033.10003083.10003095</concept_id>
<concept_desc>Networks~Network reliability</concept_desc>
<concept_significance>100</concept_significance>
</concept>
</ccs2012>
\end{CCSXML}
\ccsdesc[500]{Computer systems organization~Embedded systems}
\ccsdesc[300]{Computer systems organization~Redundancy}
\ccsdesc{Computer systems organization~Robotics}
\ccsdesc[100]{Networks~Network reliability}
\end{comment}
\keywords{Tor, Bridge, Scary, Obscuration, Censorship, Circumvention, Pluggable Transport} % TODO
% ================================================================================
\maketitle
% ================================================================================
\begin{comment}
TODO: Roadmap
=> Introduction
- Why do we need Pluggable Transports?
- History
- Why do we need more/new/other Pluggable Transports? (Problem of censorships (current state/situation))
=> Definitions (Bridge, Pluggable Transport), Notations, Organization/Outline
=> Explaining the most important Pluggable Transports
-------------------
What we learned from the already existing pluggable transports (advantages/disadvantages, what is good/what is bad)?
Main constraints/consequences which follow from this for the design of a new Pluggable Transport!!!
Looking for additional/already done reasearch/paper work. -> Repetition/Review
A sketch of the basic structure for the PT which follows from this.
Going into details for each part (maybe for each one an own section(?))
-------------------
Ideas for "penetration testing" of this PT
Where could it have weaknesses?
Possible ways for an attack
-------------------
Prospect and conclusions for this PT and the design of future ones.
-------------------
\end{comment}
% ================================================================================
\section*{Preamble}
\label{s:preamble}
% --------------------------------------------------------------------------------
This paper was written in the context of a job application as Pluggable Transport Software Developer for Anti-Censorship Team of The Tor Project\footnote{The Tor Project, Inc., is a 501(c)(3) nonprofit organization advancing human rights and freedoms by creating and deploying free and open source anonymity and privacy technologies. \cite{JobDes}}.
% --------------------------------------------------------------------------------
\section{Introduction}
\label{s:introduction}
% --------------------------------------------------------------------------------
In August 2018, The Intercept published a story about plans of Google for launching a censored version of its search engine in China, which will blacklist websites and search terms about human rights, democracy, religion, and peaceful protest \cite{Dragonfly}. This project, with the code-name \textit{Dragonfly}, started in spring prior year, is the newest step in the ongoing work of creating a censored environment of information in China.
If we look back, the story of censorship in China started in 1998. The Communist Party feared that the China Democracy Party would create a powerful new network. The China Democracy Party was immediately banned, members arrested and imprisonment \cite{GreatFirewallWikiEn}. Finally, this resulted in the beginning of the \textit{Great Firewall (GFW)} project, a combination of legislative actions and technologies enforced by the People's Republic of China to regulate the Internet domestically. It blocks access to selected websites, internet tools, mobile apps and slows down cross-border internet traffic.
Since the GFW blocks destinations and inspects the data being transmitted, ways for censorship circumvention need proxy nodes and encrypted data traffic. Typically, this is done these days by the help of foreign proxy servers, regional website mirrors, Tor, virtual private networks (VPNs) and secure shell (SSH).
Over the years, more and more of this circumvention tools have been blocked due to deep packet inspections and the detailed analysis of its content. So now, many VPNs are no longer useable to circumvent the Great Firewall of China and also the access to the Tor anonymity network \cite{Tor}, with its public list of relays, is no longer possible.
To solve the problem of relay blocking, Tor introduced so-called \textit{bridges} \cite{TorBridges} which are non-public relays, to help censored users reach the Tor network. Because of the ability of dynamically blocking bridges by looking for their TLS fingerprint \cite{foci12-winter} \cite{Ensafi2015AnalyzingTG}, packet fragmentation and Tor obfsproxy in combination with private bridges, were added \cite{foci12-winter}.
Finally, this lead us to \textit{Pluggable Transports (PT)} \cite{TorPluggableTransports}, which help to bypass censorship attempts against Tor. PTs transform the Tor traffic between client and bridges, in such a way that it looks like innocent traffic instead of the actual Tor traffic. In this paper, we will talk about this PTs, their general construction constraints and an introducing of an sketch of a new PT called \textit{Scary}.
% ---------------------------------------
\subsection{Outline}
\label{ss:outline}
% ---------------------------------------
% TODO
TODO
% ---------------------------------------
\subsection{Notation}
\label{ss:notation}
% ---------------------------------------
% TODO
TODO
% ================================================================================
\section{TLS fingerprinting}
\label{s:tlsfingerprinting}
% --------------------------------------------------------------------------------
If we look at the previous story of censorship and blocking, this leads us to modern cryptographic protocols to provide communications security in computer networks. \textit{Transport Layer Security (TLS)} \cite{TLS_v1_2} is the one we have to look at here in the context of Tor traffic fingerprinting and its examination.
% ---------------------------------------
\subsection{A brief history of TLS}
\label{ss:abriefhistoryoftls}
% ---------------------------------------
In 1999, the history of Transport Layer Security started when TLS v1.0 was introduced in RFC 2246 \cite{TLS_v1_0} as an upgrade of SSL v3.0. Seven years later, in 2006, TLS v1.1 was definied in RFC 4346 \cite{TLS_v1_1} as an update of TLS v1.0 with significant changes, like e.g. protection against cipher-block chaining (CBC) attacks. Two years later, in 2008 TLS 1.2 was published in RFC 5246 \cite{TLS_v1_2}, which its major differences, like e.g. replacing of MD5-SHA-1 with SHA-256 in the pseudorandom function (PRF) and in the finished message hash. Finally, just in August 2018, the newest version TLS 1.3 was definied in RFC 8446 \cite{TLS_v1_3}, with changes like e.g. separating key agreement and authentication algorithms from the cipher suites, removing support for MD5 and SHA-224 hash functions and much more.
In this papper, we will always assume that we are talking about TLS 1.2, since it was the state-of-the-art, when the PT \textit{Scary}, which will be described in the following, was developed, in 2015.
% ---------------------------------------
\subsection{The TLS Handshake Protocol}
\label{ss:thetlshandshakeprotocol}
% ---------------------------------------
The TLS Handshake Protocol (\cite{TLS_v1_2} Sections 7.3 \& 7.4), which operates on the top of the TLS record layer, is the first interesting part for us. The TLS client and server agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and generate shared secrets.
\begin{comment}
\begin{figure}
\caption{TLS full handshake}
\label{fig:caption}
\procedure{}{%
\textbf{Client} \> \> \textbf{Server} \\
\text{ClientHello} \> \sendmessageright*[1cm]{} \> \\
\> \> \text{ServerHello} \\
\> \> \text{Certificate} \\
\> \> \text{ServerKeyExchange} \\
\> \> \text{CertificateRequest} \\
\> \sendmessageleft*[1cm]{} \> \text{ServerHelloDone} \\
\text{Certificate} \> \> \\
\text{ClientKeyExchange} \> \> \\
\text{[ChangeCipherSpec]} \> \> \\
\text{Finished} \> \sendmessageright*[1cm]{} \> \> \\
\> \> \text{[ChangeCipherSpec]} \\
\> \sendmessageleft*[1cm]{} \> \text{Finished} \\
\text{Application Data} \> \longleftrightarrow \> \text{Application Data}
}
\end{figure}
\end{comment}
We will look at the hello messages, which are used to exchange security enhancement capabilities between client and server, at first.
% ---------------------------------------
\subsubsection{TLS Client Hello}
\label{sss:tlsclienthello}
% ---------------------------------------
During the beginning of the connection between a client and a server, the client sends the \textit{ClientHello} as its first message, at all. It consists of a random structure
\begin{comment}
(See listing \ref{lst:clienthellorandomstructure})
% float
\begin{lstlisting}[language=C, numbers=left, frame=tb, caption = \textit{ClientHallo} random structure \cite{TLS_v1_2}., label = lst:clienthellorandomstructure]
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
\end{lstlisting}
\end{comment}
with gmt\_unix\_time, the current time and date in standard UNIX 32-bit format, and random\_bytes, 28 bytes which are generated by a secure random number gnerator. In addition it includes a variable-length session identifier, so a SessionId becomes valid when the handshake negotiation is completed.
Furthermore, the \textit{ClientHello} consists of the cipher suite list, which contains the combinations of cryptographic algorithms supported by the client in order of the client's preference. The cipher suites define key exchange algorithms, encryption algorithms, a MAC algorithm, and a PRF. The server will choose a cipher suite \lstinline[language=C]{uint8 CipherSuite} from this list.
The \textit{ClientHello} also includes a list of supported compression algorithms, in order according to the client's preferences and optional extensions.
In listing \ref{lst:clienthellostructure} you can see a summary of the full \textit{ClientHello} structure.
%float
\begin{lstlisting}[language=C, tabsize=4, numbers=left, xleftmargin=5.0ex, basicstyle=\footnotesize, breakatwhitespace=false, breaklines=true, frame=tb, caption=\textit{ClientHello} structure \cite{TLS_v1_2}., label=lst:clienthellostructure]
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
\end{lstlisting}
After sending this message, the Client waits for a \textit{ServerHello} response.
% ---------------------------------------
\subsubsection{TLS Server Hello}
\label{sss:tlsserverhello}
% ---------------------------------------
The \textit{ServerHello} is send by the server as response to the \textit{ClientHello} message from the client, when it found an acceptable set of algorithms.
It is very similar to the \textit{ClientHello}, consists of a server\_version, the suggested one by the client, a random structure, independently generated by the server from the ClientHello.random, the session\_id, the single cipher suite selected by the server from the list in ClientHello.cipher\_suite, the single compression algorithm selected by the server from the list in ClientHello.compression\_methods and optional extensions.
In listing \ref{lst:serverhellostructure} you can see a summary of the full \textit{ServerHello} structure.
%float
\begin{lstlisting}[language=C, tabsize=4, numbers=left, xleftmargin=5.0ex, basicstyle=\footnotesize, breakatwhitespace=false, breaklines=true, frame=tb, caption=\textit{ServerHello} structure \cite{TLS_v1_2}., label=lst:serverhellostructure]
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello;
\end{lstlisting}
% ---------------------------------------
\subsection{TODO}
\label{ss:TODO}
% ---------------------------------------
TODO % TODO
% ================================================================================
\section{Tor's Pluggable transports}
\label{s:torspluggabletransports}
% --------------------------------------------------------------------------------
To bypass censorship attempts against Tor, \textit{Pluggable Transports (PT)} were developed \cite{TorPluggableTransports}, to fake Tor traffic in such a way that it looks like ordinary traffic. We want to give a short summary \cite{TorWikiAChildsGardenOfPluggableTransports} of Tor's most important pluggable transports \cite{TorWikiListOfPluggableTransports}.
% ---------------------------------------
\subsection{Ordinary Tor traffic}
\label{ss:ordinarytortraffic}
% ---------------------------------------
In the section above, we already looked at the ordinary TLS Handshake protocol and its \textit{ClientHello} and \textit{ServerHello} message. The interesting parts from this, for us, are the cipher suite list, server name and TLS extensions, which are send by the client and responded by the server.
Tor used a distinctive cipher suite list, until China started to block Tor \cite{foci12-winter} \cite{TorTicket4744}, in 2011. In answer to this, Tor changed its cipher suite list to be the same as Firefox's, but Tor had still a different TLS extension like Firefox because of e.g. other Elliptic curves sets \cite{TorWikiAChildsGardenOfPluggableTransports}. Finally, the server responds with its choosen parameters and a random server name, too.
% ---------------------------------------
\subsection{The obfs family}
\label{ss:theobfsfamily}
% ---------------------------------------
The first pluggable transports originated from the obfs, "look-like-nothing", family and consists of \textit{obfs2} \cite{TorGitWebObfs2Specification}, \textit{obfs3} \cite{TorGitWebObfs3Specification} and \textit{obfs4} \cite{TorGitWebObfs4Specification}.
% ================================================================================
\section{Conclusions}
\label{s:conclusions}
% --------------------------------------------------------------------------------
% TODO
% ================================================================================
\appendix
\section{Appendix}
\label{s:appendix}
% --------------------------------------------------------------------------------
% TODO
% ---------------------------------------
\subsection{Definitions}
\label{ss:definitions}
% ---------------------------------------
\begin{itemize}
\item \textbf{Virtual private network (VPN).} TODO %TODO
\item \textbf{Secure shell (SSH).} TODO %TODO
\item \textbf{Bridges.} TODO %TODO
\item \textbf{Pluggable Transport (PT).} TODO %TODO
\end{itemize}
% ================================================================================
% TODO: entry types and author information, bibliographystyle
%\nocite{*} % TODO
\bibliography{pt-scary}
\bibliographystyle{ACM-Reference-Format}
% ================================================================================
\section*{License}
\label{s:license}
% --------------------------------------------------------------------------------
\begin{center}
\includegraphics{by-nc-nd.png} \\
\url{https://creativecommons.org/licenses/by-nc-nd/4.0/}
\end{center}
% ================================================================================
\end{document}
% ================================================================================