Poking a Hole in the Wall: E�icient Censorship-Resistant

Internet Communications by Parasitizing on WebRTC

Diogo Barradas, Nuno Santos, Luís Rodrigues, Vítor Nunes

INESC-ID, Instituto Superior Técnico, Universidade de Lisboa

{diogo.barradas,nuno.m.santos,ler,vitor.sobrinho.nunes}@tecnico.ulisboa.pt

ABSTRACT

Many censorship circumvention tools rely on trusted proxies that

allow users within censored regions to access blocked Internet con-

tent by tunneling it through a covert channel (e.g,. piggybacking on

Skype video calls). However, building tools that can simultaneously

(i) provide good bandwidth capacity for accommodating the typical

activities of Internet users, and (ii) be secure against trac analysis

attacks has remained an open problem and a stumbling block to

the practical adoption of such tools for censorship evasion.

We present Protozoa, a censorship-resistant tunneling tool fea-

turing both high-performing covert channels and strong trac

analysis resistance. To create a covert channel, a user only needs to

make a video call with a trusted party located outside the censored

region using a popular WebRTC streaming service, e.g., Whereby.

Protozoa can then covertly tunnel all IP trac from unmodied

user applications (e.g., Firefox) through the WebRTC video stream.

This is achieved by hooking into the WebRTC stack and replacing

the encoded video frame data with IP packet payload, while ensur-

ing that the payload of the WebRTC stream remains encrypted, and

the stream’s statistical properties remain in all identical to those

of any common video call. This technique allows for sustaining

enough throughput to enable common-use Internet applications,

e.g., web browsing or bulk data transfer, and avoid detection by

state-of-the-art trac analysis attacks. We show that Protozoa is

able to evade state-level censorship in China, Russia, and India.

CCS CONCEPTS

•Security and privacy !Network security

;

•Social and pro-

fessional topics !Technology and censorship.

KEYWORDS

Censorship circumvention; Trac analysis; WebRTC

ACM Reference Format:

Diogo Barradas, Nuno Santos, Luís Rodrigues, Vítor Nunes. 2020. Poking

a Hole in the Wall: Ecient Censorship-Resistant Internet Communica-

tions by Parasitizing on WebRTC. In Proceedings of the 2020 ACM SIGSAC

Conference on Computer and Communications Security (CCS ’20), Novem-

ber 9–13, 2020, Virtual Event, USA. ACM, New York, NY, USA, 14 pages.

https://doi.org/10.1145/3372297.3417874

Permission to make digital or hard copies of all or part of this work for personal or

classroom use is granted without fee provided that copies are not made or distributed

for prot or commercial advantage and that copies bear this notice and the full citation

on the rst page. Copyrights for components of this work owned by others than ACM

must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,

to post on servers or to redistribute to lists, requires prior specic permission and/or a

fee. Request permissions from permissions@acm.org.

CCS ’20, November 9–13, 2020, Virtual Event, USA

ACM ISBN 978-1-4503-7089-9/20/11. . . $15.00

https://doi.org/10.1145/3372297.3417874

1 INTRODUCTION

State-level censors are known to apply techniques to prevent free ac-

cess to information on the Internet. In fact, many countries have de-

ployed a vast censorship apparatus to exercise control over available

content, namely China [

], Russia [

], Iran [

], Bangladesh [

India [

], Thailand [

], or Syria [

]. For instance, amidst the re-

cent Coronavirus outbreak, the chinese government has shut down

news websites [

] and instructed chinese social media platforms

to censor references and keywords related to the infection [

in an attempt to handle the sharing of negative coverage within and

outside the country. This control can be enforced through various

techniques, such as keyword-based lters [

], image lters [

social platform monitoring [

], and even the entire blocking

of Internet destinations [57] or selected protocols [18].

To evade censorship, many circumvention tools have been pro-

posed for enabling users to freely access/share information on the

Internet [

]. Typically, such tools rely on covert channels to

allow for the stealthy transmission of sensitive data through an

apparently innocuous carrier medium [

], for instance a multi-

media streaming carrier application like Skype. The key idea is to

encode the covert data in such a way that an adversary capable of

inspecting the full packet exchange cannot distinguish between a le-

gitimate transmission and one that subliminally carries covert data.

This general approach, which we call multimedia covert streaming,

can typically be achieved in two ways: i) by entirely mimicking the

carrier’s network-level protocols [

](media protocol mimicking),

or ii) by embedding the covert data into the video (or audio sig-

nal) feed of the carrier application in the course of a regular video

call [3, 36, 44, 46, 50] (raw media tunneling).

Given that all the carrier’s trac is encrypted, one way for an

adversary to counter potential covert channels is to blatantly block

all trac generated by the carrier application. This method, how-

ever, can bring harmful side-eects even for a state-level adversary.

In fact, considering how instrumental many media streaming appli-

cations are for the tissue of economic and social interactions within

censored regions, the costs of shutting down popular applications

can be overwhelming and erode even further the state’s reputa-

tion in the eyes of its international peers. Leveraging on essential

streaming applications can then serve as a strong deterrent for the

enforcement of blocking policies, and constitutes the key insight

that favors the eectiveness of multimedia covert streaming [21].

Nevertheless, an adversary can employ a second class of tech-

niques based on trac analysis. Essentially, it involves probing into

the censored network region, inspecting the trac generated by a

presumable carrier application, and looking for discrepancies in the

trac (e.g., abnormal patterns) that might signal the presence of

covert channels. Hence, it follows that an eective tool for multime-

dia covert streaming must be able to resist these kinds of attacks by

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

exhibiting trac patterns that will ideally be indistinguishable from

legitimate trac. In other words, when picking from two sampled

ows – one legitimate ow and one crafted ow containing covert

data – the adversary must not be able to distinguish them but by

random guessing, i.e., with 50% chance of success.

Unfortunately, the existing tooling support for multimedia covert

streaming is quite bleak. Several studies revealed that the presence

of modulated covert trac can be detected solely based on the

analysis of trac features such as packet sizes and packet inter-

arrival times [

]. In fact, machine learning (ML)-based trac

analysis techniques can eectively detect small changes in the

packet frequency distributions caused by the embedding of covert

data inside carrier video streams, namely deviations in the packet

sizes and inter-packet arrival times when compared with legitimate

trac. Most existing tools fail this test and are prone to be detected

with high accuracy rates [

]. While some tools like DeltaShaper [

]

can tolerate detection to some degree, they do so at the expense of

reducing the amount of covert data embedded into the cover video

stream, severely limiting the covert channel bandwidth capacity

that can be attained. For instance, in DeltaShaper, the maximum

achievable throughput is only 7 Kbps, which is clearly insucient

for sustaining the trac generated by common Internet users, e.g.,

interactive web browsing, media streaming, or bulk data transfers.

This paper presents Protozoa, a new multimedia covert stream-

ing tool that provides good performance for the covert transmission

of arbitrary IP trac while featuring strong resistance to detection

when subjected to ML-based trac analysis by a state-level adver-

sary. In particular, Protozoa allows an Internet user (client) located

in a censored region to access blocked content by leveraging the

help of a trusted user in the free region who will act as a proxy on

the client’s behalf. Protozoa enables then to create a bidirectional

covert tunnel between both endpoints. Henceforth, the client can

start browsing the web freely: the local IP trac will be transpar-

ently redirected through the covert tunnel to its nal destination

host in the free region, e.g., YouTube. This local application is not

restricted to a browser: Protozoa can tunnel IP trac from arbitrary

unmodied applications, e.g., email or BitTorrent clients.

Protozoa advances the state-of-the-art by incorporating two

new ideas in its design. First, to enable the transmission of covert

trac, it uses web streaming applications based on WebRTC which

are very popular and widely disseminated. Concretely, to create a

covert tunnel, all that two users – client and proxy – need to do is

to establish a video call using a WebRTC-enabled web streaming

website, such as Whereby (

https://whereby.com

). Protozoa uses the

video call’s associated WebRTC media stream to tunnel covert IP

trac between both endpoints. Second, to encode the covert signal

into the carrier stream, Protozoa introduces a technique named

encoded media tunneling, which allows for boosting the capacity of

covert channels while oering strong resistance to trac analysis

attacks. It consists of embedding the covert data into encoded video

frames, i.e., right after the lossy compression has been applied by

the video codec. This mechanism is implemented by modifying the

WebRTC stack of Protozoa’s Chromium browser component.

We extensively evaluated our Protozoa prototype both through

a set of microbenchmarks resorting to media sessions established

over Whereby, and by testing it in various realistic usage scenarios

and workloads. Our results showed that, under normal network

ChannelBandwidth

Detection Rate

CeCa

> 99.9%

FeeWae

> 99.9%

50%

Media Pcl Mimicking Ra Media Tnneling

60%

100%

Face

> 99.9%

SkeMh

> 99.9%

CenSfe

> 99.9%

80%

70%

0%

Encded Media Tnneling

Pa

55% - 65%

1  10  100  1 

better

DelaShae

85% - 95%

10 

Rad

Ge

Peec

Ge

Figure 1: Design space of multimedia covert streaming tools

along two dimensions: covert channel capacity (X-axis), and

trac analysis resistance (Y-axis). Darker shades indicate in-

creasing chances of detection, i.e., tools are more insecure.

Protozoa outperforms the existing systems in both dimen-

sions. A detailed analysis of this plot is found in Section 9.1.

conditions, Protozoa can deliver covert channel bandwidth capaci-

ties in the order of 1.4Mbps and channel eciency of 98.8%, while

providing strong resistance to trac analysis using state-of-the-art

ML-based techniques [

]. As illustrated in Figure 1, these results

represent a signicant departure over existing media covert stream-

ing techniques, dramatically improving the detection rate of the

best performing tool, i.e., Facet, from

99.0% to 55%-65%, i.e., from

nearly perfect guess to very close to random guess, while simul-

taneously improving covert channel bandwidth by 3

⇥

. Additional

experiments show that Protozoa can withstand a number of active

network perturbations without jeopardizing its resistance against

trac analysis or breaking the covert channel connection.

To assess the portability of Protozoa, we also tested our system

on alternative WebRTC services:

appr.tc

and

coderpad.io

. Our re-

sults showed that it can consistently achieve similar throughput

and trac analysis resistance properties when used over dierent

applications, which makes it useful in scenarios where specic

applications are blocked (e.g.,

appr.tc

is blocked in China). Lastly,

we tested Protozoa in the wild by deploying Protozoa in three re-

gions that are known to enforce Internet censorship through several

means: the Great Firewall of China (GFW) apparatus in China, and

ISP censorship in Russia and India. We performed several exper-

iments from servers deployed in each of these regions. First, we

accessed blacklisted content without using Protozoa, and checked

that it was indeed inaccessible. Then, using Protozoa, we were able

to access this content, showing that our system can successfully

breach through existing censorship mechanisms deployed in these

regions, and provide free access to blocked Internet content.

2 THREAT MODEL

The general system model of a multimedia covert streaming (MCS)

tool is illustrated in Figure 2. It represents two users, one acting

as client (Alice), and a second acting as proxy (Bob). The client is

located in a censored region controlled by a state-level adversary,

and the proxy is based in a free Internet region. The adversary is

able to observe, store, interfere with, and analyze all the network

ows within its jurisdiction, and block the generalized access to

remote Internet services, such as CNN, Facebook, or Twitter, by

the residents in the censored region. The censorship policies can be

based on the IP address or the domain name of the target destination,

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

MCS

Tool

Carrier

Applicaion

Carrier Sream

Clien

Applicaion

Alice's Compter Bob's Compter

Coer Channel

Text

Ceed Regi Fee Regi

Oe

Iee

Text

Carrier

Applicaion MCS

Tool

Ce

Tafc

Clien Pro

Figure 2: System model of a multimedia covert streaming

tool for censorship-resistant Internet communications.

the protocol used in the communication (e.g., BitTorrent or Tor), or

blacklisted content (e.g., through keyword and image ltering).

An MCS tool aims at enabling the client to overcome the com-

munication restrictions enforced by the adversary by leveraging (i)

the cooperation of a proxy located in the free region operated by a

trusted Internet user (Bob), and (ii) a carrier application consisting

of an encrypted video-streaming service (e.g., Skype) whose trac

the adversary authorizes to cross the boundaries of the censored

region. Both users – client and proxy – must run the MCS software

on their local computers to create a covert tunnel through the media

stream managed by the carrier application. This tunnel will allow

the client to contact remote hosts on the open Internet.

To defeat an MCS tool, the adversary can use deep packet in-

spection for pinpointing trac indicators that lead to the detection

of a covert channel. To increase its chances for successful detection,

it may apply statistical trac analysis techniques over collected

network traces [

]. The adversary may also launch indiscriminate

active network attacks aimed at perturbing the correct behavior

of covert channels lurking under seemingly legitimate ows while

ensuring that legitimate ows maintain a reasonable quality.

However, the adversary will seek only to rapidly disrupt and tear

down those ows which are suspected of carrying covert channels,

and it will refrain from blocking the carrier application altogether if

such an application is reckoned to provide an important service to

the population. The adversary is also deemed to be computationally

bounded, and unable to decrypt encrypted trac generated by the

carrier application. The adversary’s control is also limited to the

network: it has no access to the persistent or volatile state of clients,

proxies, or carrier application provider, and enjoys no privileges

over the software that can be executed by each party.

3 PARASITIZING ON WEBRTC STREAMS

In designing Protozoa, we elected WebRTC media streams as the

carrier medium for deploying practical, ecient, and secure covert

channels. WebRTC [

] is a W3C standardization initiative for

protocols and APIs for enabling secure real-time communication

between web browsers. All major browsers have built-in WebRTC

implementations enabling the generalized use of this technology.

WebRTC creates new opportunities for building MCS services

that can simultaneously be widely available and easy to use. By act-

ing at this layer, any WebRTC-powered application can be transpar-

ently used for covert data transmission. WebRTC has been currently

adopted by numerous services that integrate real-time communica-

tion capabilities

. This integration has been greatly facilitated by

There are many dierent WebRTC-based web streaming applications, such as social

applications like Whereby or Facebook Messenger, the gaming-focused chat Discord,

the simplicity of the JavaScript WebRTC API [

]. The generalized

usage of web conferencing for professional dealings, in particular,

will make it very deterring for a state-level adversary to block all

WebRTC trac due to the extensive collateral damage to the coun-

try’s own sustainability [

]. This profusion of WebRTC services

also gives Protozoa users a great deal of exibility and options to

choose from when it comes to picking the carrier medium for covert

transmission. Creating covert sessions is in itself a user-friendly

operation since establishing a Protozoa connection is in no way

dierent from making a video call on a web streaming application

(including the process of joining a chatroom URL).

Given that a widely-used WebRTC stack is openly available (in

the Chromium web browser), we have full access to the WebRTC

video streaming pipelines which allows us to develop a new ecient

and secure covert data encoding technique named encoded media

tunneling. In existing raw media tunneling tools, the covert data is

encoded as pixels of the carrier video frames. Unfortunately, given

that the raw input signal undergoes lossy compression by the video

codec of the carrier application, a signicant amount of redundancy

must be included to enable the covert data recovery by the receiver

which degrades the utilization eciency of the covert channel.

Moreover, using up all possible pixel area of the carrier frames

for encoding covert data reduces the video codec’s compression

eciency, which increases the network packet sizes and deforms

the packet size frequency distribution when compared to that of

legitimate ows. Because this discrepancy can be detected by an

adversary, the covert channel tools must be parsimonious at using

up the video stream’s pixel area thereby throttling even further the

bandwidth capacity of the covert channel. Encoded media tunneling

overcomes these limitations and allows for boosting the capacity of

covert channels while oering strong resistance to trac analysis

attacks. Next, we describe our technique as we present Protozoa.

4 PROTOZOA

This section presents Protozoa, a system that provides covert chan-

nels over WebRTC media sessions

. Next, we present its architec-

ture and then describe its most relevant technical details.

4.1 Architecture

Figure 3 depicts the architecture of Protozoa. It follows the sys-

tem model of a general multimedia covert streaming (MCS) tool

presented in Figure 2. In Protozoa, the carrier application consists

of a web application that uses the WebRTC framework for pro-

viding a point-to-point live streaming service between its users,

e.g., Whereby. Typically, such an application consists of a backend

that handles the signaling and session establishment of video calls

between participants, and client-side JavaScript & HTML code that

initiates video calls and manages the video transmission via the

WebRTC API provided by the browser. The resulting media stream

will be used by Protozoa as the carrier for a covert channel.

The MCS tool (see Figure 2) is materialized by the Protozoa

software bundle which targets the Linux platform, and it is set up

dierently to work as client or proxy by two participating parties.

professional video conferencing services like Amazon Chime and Slack, remote coding

interview software like Coderpad, or even health monitoring through Vidyo.

“Protozoa” alludes to parasitic biological organisms which feed on other organisms.

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

Ceed Regi Fee Regi

cnncom

Cie

Clien Neok Nameace

IP: 10.10.10.10

IP acke IP acke

Poooa

Meage

Poooa

Meage

Ueam

Hook

SOCKS Pro

Po Neok Nameace

IP: 20.20.20.20

P

Boing Windo

WebRTC

Doneam

Hook

Boing Windo

WebRTC

Aca-deed

a

herebcomchatroomIDherebcomchatroomID

Poooa Meage

SIPservers

Poooa Gaea Poooa Gaea

Clien Applicaion

Decode

Doneam

Hook

Encode

Ueam

Hook Encode

Decode

2. 3.

.

.

.

10.

IP acke

WebRTC eda ea

(SRTP ace)

Aice Bb

Figure 3: Architecture of Protozoa: The components of our system are highlighted in a darker shade.

The client will be able to execute unmodied IP applications whose

trac can seamlessly be routed through the WebRTC covert channel

by the proxy to destination hosts anywhere in the free Internet

region. Figure 3 shows Alice (client) executing a local application

for accessing cnn.com using Bob’s computer as proxy.

The Protozoa software bundle comprises four main components:

gateway server, encoder service, decoder service, and SOCKS proxy

server. Both client and proxy run the gateway server and the en-

coder and decoder services. The proxy also runs the SOCKS proxy

server. Both endpoints leverage network namespaces for transpar-

ent interception and manipulation of IP packets. All these compo-

nents cooperate in forwarding covert IP trac by implementing

three cross-cutting functional layers. Next, we explain how these

layers operate by introducing them in a bottom-up fashion.

1. WebRTC layer:

This layer is responsible for the setup and man-

agement of a point-to-point WebRTC covert channel between two

parties, and it is implemented by the gateway servers running on

each communication endpoint. The covert channel is piggybacked

on a WebRTC media stream instantiated by a carrier web stream-

ing application. This channel supports full-duplex bidirectional

communication and exchanges Protozoa messages dened in a spe-

cic format. These messages can contain arbitrary IP payload. The

gateway server is built out of a modied Chromium browser, and

instrumented with the placement of two hooks – upstream and

downstream – in the WebRTC stack. We leverage Chromium’s func-

tionality to provide a web browsing UI and runtime environment

which will allow for the execution of the client-side WebRTC ap-

plication code. The hooks intercept the WebRTC streams so as to

replace the payload of the WebRTC video frames with covert Pro-

tozoa messages. The gateway server opens two pipes for receiving

upstream and downstream messages from the codec layer.

2. Codec layer:

This layer performs two complementary encoding

and decoding operations. The former is responsible for encoding

streams of IP packets generated by local networked applications.

Packets are read from a

libnetfilter

queue [

], and encapsulated

into Protozoa messages, which are forwarded to the local gateway

server and then delivered to the remote endpoint. Decoding per-

forms the reverse operation, i.e., reads incoming Protozoa messages

from the local gateway server, extracts the enclosed IP packets, and

writes them to a raw socket to be routed to their nal destination.

These operations are coordinated by the encoder and decoder at

both endpoints to sustain simultaneously two IP packet ows, i.e.,

upstream and downstream. Internally, these components maintain

packet and message queues, and implement packet fragmentation

and reassembly so as to eciently use the covert channel capacity.

3. SOCKS layer:

This layer enables the exchange of IP packets

between the networked applications running on the client, and a

remote Internet host through a SOCKS v5 proxy server running on

the proxy. This is achieved by the use of Linux’s network names-

paces and conguration of

iptables

. Namespaces are implemented

by the Linux kernel and allow for the creation of virtual network

interfaces. In our context, we use namespaces for creating a virtual

network environment for the client application and a second one

for the SOCKS proxy server. Each environment features a virtual

network interface that is exposed to the local processes with a spe-

cic IP address, e.g., 10.10.10.10, or 20.20.20.20, respectively (see

Figure 3). Protozoa then congures the local

iptables

so as to route

all (upstream) IP packets with destination address 20.20.20.20 to

the namespace of the proxy, and all (downstream) IP packets with

destination address 10.10.10.10 to the namespace of the client. Thus,

by conguring a client application to use the IP address 20.20.20.20

as SOCKS proxy, all its IP connections will be transparently de-

livered to the SOCKS server proxy, which in turn will deliver the

packets to its remote destination. So, for instance, the web request

cnn.com

depicted in Figure 3 can be performed by running the

curl command on a Linux terminal as follows:

$ ip netns exec PROTOZOA_ENV_CLIENT

curl -x socks5h://20.20.20.20:1080 https://cnn.com

This means that, in order to use Protozoa’s covert tunnels, the

user must congure the client application to use a SOCKS proxy. For

client applications that do not natively support the use of SOCKS

proxy servers, the user can use an additional tool,

proxychains

[

which provides the client application with SOCKS proxy support.

4.2 Execution Workow

This section describes the execution workow involved in a com-

plete communication using Protozoa covert tunnels. Using the ex-

ample depicted in Figure 3, we describe the full message exchange

sequence that takes place in order for Alice to fetch a web page

from

cnn.com

through a WebRTC covert tunnel facilitated by Bob,

who is an individual volunteer trusted by Alice. This tunnel is cre-

ated through a WebRTC video call between Alice and Bob using

Whereby in the course of a Protozoa covert session, which is di-

vided into two stages: covert session establishment, and covert data

transmission. Figure 4 represents the messages exchanged.

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

1. Covert session establishment:

The covert tunnel is set up

between client and proxy, requiring both participants to agree on

a common rendezvous point for a WebRTC media connection. In

our example, Alice and Bob use the web browsing interface of their

Protozoa gateway to join a common video chatroom. They begin by

bootstrapping the Protozoa software: Alice in client mode (A1), and

Bob in proxy mode (B1). Then, Alice accesses

whereby.com

, creates

a password-protected chatroom, and obtains the chatroom URL

(A2). Similarly to using alternative MCS tools [

], Alice uses an

out-of-band channel, e.g., email, social network web site, or mobile

app (e.g., Whatsapp) to share the chatroom URL and password with

Bob (A3 and B2). Both users can now join the chatroom (A4 and B3)

and initiate a video call by feeding a carrier video stream from their

local cameras or (optionally) from a prerecorded video; this video

will be replaced by covert payload. As the WebRTC video stream is

initiated, Protozoa hooks into it, and sets up the covert tunnel.

2. Covert data transmission:

Once the covert tunnel is ready,

Alice can access remote Internet services. For instance, to access

cnn.com

, Alice can simply run the

curl

command listed in the sec-

tion above to issue an HTTP GET request to

cnn.com

. The IP trac

generated from this request will be transparently tunneled through

the covert channel. Protozoa will continuously stream video until

the termination of the covert session, even when there is no covert

trac to be transmitted; in this case, dummy payload (cha) is sent.

4.3 Network-level Security of Covert Sessions

At covert data transmission, standard WebRTC ensures that all

exchanged packets are integrity-protected and the message payload

containing sensitive video data is encrypted. Thus, an adversary

cannot read its content, or modify it without detection. Nevertheless,

we must ensure that the covert session has been securely established.

In particular, an adversary may attempt a man-in-the-middle or

an impersonation attack during the session negotiation phase (see

Figure 4) enabling it to decrypt the message payload and inspect

the covert data. To prevent these attacks, Protozoa leverages the

security mechanisms implemented by WebRTC and by the carrier

WebRTC web streaming application, namely the following ones:

a) HTTPS:

Client and proxy run client-side code of the WebRTC

web application which connects to its backend servers through

HTTPS. This means that all messages involving interactions with

the backend (i.e., A2, A4, B3) will be exchanged over TLS-enabled

secure channels. In particular, this prevents an adversary from

obtaining the URL that would allow it to join the chatroom, or to

mount a MITM by advertising dierent URLs to client and proxy.

b) SIP / DTLS-SRTP:

To establish a media session, WebRTC lever-

ages the Session Initiation Protocol (SIP) to signal one endpoint’s

intention (e.g., the client’s) to connect to its corresponding peer

(e.g., the proxy). This protocol involves the communication between

each endpoint (client/proxy) and a SIP server run by the WebRTC

application provider (see Figure 3). This server is used to exchange

media session parameters between endpoints, and it is combined

with the DTLS-SRTP protocol [

] to perform an initial key

exchange so as to oer protection against man-in-the-middle at-

tacks. The WebRTC application provider also runs a STUN server

which helps the endpoints located behind a NAT to determine their

respective public (NAT’ed) IP addresses, and share them with their

Cie P Oe Iee

WebRTC eice

A2. Regie

cha URL

A4. Acce cha URL

B3. Acce

cha URL

A3. Shae cha URL

B2. Lea cha URL

Media Sein

A5. GET h://.c.c

GET h://c.c

200 OK

Sigaig Sigaig

Pa Ce Chae

A1. Sa Pa cie B1. Sa Pa 

Ceed Regi Fee Regi

Coer Seion Eablihmen

Coer Daa Tranmiion

Aice Bb

Figure 4: Covert session: gear symbol denotes user actions.

peers. To ensure that the media sessions between endpoints are not

hijacked and pointed to dierent IP locations, the connection at-

tempts to the IP addresses of target endpoints are secured by a MAC,

which is computed using the key exchanged in the signaling chan-

nel [

]. Once a WebRTC session has been established, WebRTC

leverages the Secure Real-time Transport Protocol (SRTP) [

] for

encrypting and authenticating the content of the media in transit.

4.4 Encoded Media Tunneling

Protozoa uses the video streams generated by client and proxy as

a medium for carrying covert IP packet data in both directions.

To this end, we employ a new approach named encoded media

tunneling. Similar to existing raw media tunneling techniques [

], our method replaces carrier video information with a covert

message. However, instead of replacing the pixels of the raw input

video, it replaces the bits of the encoded video signal, i.e., after the

input video has been compressed by the WebRTC video codec. This

technique helps increase not only the capacity of the channel but

also its resistance to trac analysis. In our system, it is implemented

by instrumenting the WebRTC stack of the Protozoa gateway.

Upstream and downstream hooks:

Figure 5 illustrates the Web-

RTC stack as it is implemented in the Protozoa gateway. It is based

on the WebRTC stack bundled into the Chromium browser. The

WebRTC stack contains a built-in codec (VP8), which processes the

video signal of local web applications that use the WebRTC API. To

access the video frames generated by the WebRTC application and

implement encoded media tunneling, the WebRTC stack includes

two hooks that can intercept the processing of the media stream

in dierent directions, i.e., upstream or downstream. The upstream

hook intercepts outgoing frame data, i.e., from a local camera device

to the network. It is placed after the raw video signal has been pro-

cessed by the video engine, and right before the frame data is passed

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

WebRTC

WebRTC API (C++)

Session managemen/signalling

Web API (JaaScrip)

WebRTC Applicaion (e.g.,wherebcom)

TransporVideo EngineVoice Engine

Video Codec

Jitter Bffer

Image Enhance

Protooa Hooks

SRTP

Mltipleing

STUN

TURN

ICE

Adio Codec

Jitter Bffer

Echo Cancelling

Noise Redction

Figure 5: WebRTC software stack and Protozoa’s hooks.

over to the transport layer where SRTP packets are created, and sent

to the network. The downstream hook intercepts incoming frame

data, i.e., from the network to the local screen. It is placed right

after the transport layer has nished reconstructing an encoded

frame sent in multiple network packets, and right before handing

it over to the video engine to be decoded and rendered on screen.

We strategically placed hooks in the WebRTC stack in order to

manipulate a special data structure, named encoded frame bitstream

partitions (EFBP), where we can embed Protozoa messages.

Using EFBP as a covert data mule:

To help understand how the

covert data is embedded into the carrier frame data, Figure 6 depicts

the format of the SRTP packets, which is the means through which

video data is exchanged. The bulk of SRTP packet space is reserved

for the transmission of media payload in the eld named encoded

frame bitstream (EFB). This eld contains the bits of an encoded

(compressed) video frame as it is generated by VP8, the default

WebRTC codec. An encoded frame contains a small (3-10 bytes)

uncompressed header, and two partitions which carry compressed

bitstreams containing actual carrier video data. We call EFBP the

contiguous space occupied by these partitions. The EFBP has ve

extremely interesting properties for our problem domain:

(1)

The EFBP consists of a blob of bits that contains the actual

video data of the carrier stream. Since this information is

irrelevant for us, we can eectively use this eld for carrying

covert data by overwriting it with covert data.

(2)

The EFBP, once it is generated by VP8, is no longer modi-

ed by the WebRTC downstream pipeline. This means that

the covert data bits placed in this eld are not going to be

corrupted, e.g., due to compression or other destructive op-

erations, before being sent to the network.

(3)

The EFBP will be used as payload of the SRTP packet, and

contains no relevant metadata that inuences the transport

layer logic, hence, modifying this eld will not disturb the

normal functioning of packet transfer over the network.

(4)

The EFBP, prior to being assembled into SRTP packets, will

be encrypted, and protected with authentication markers.

This means that covert data placed inside the EFBP will be

encrypted and integrity-protected for free.

(5)

The EFBP will be encrypted resorting to a stream cipher

that preserves the plaintext size, therefore, embedded covert

messages do not change the size of encrypted EFBPs.

For all these reasons, we use the EFBP as a free storage space for

transmitting covert data in the form of Protozoa messages.

V=2 P X CC MPT seqence nmber

imesamp

snchroniaion sorce (SSRC) idenier

conribing sorce (CSRC) ideniers ...

RTP eension (opional)

RTP pad con

RTP padding

SRTP MKI (opional)

ahenicaion ag (recommended)

Encoded Fame Bieam ...

Encped poion

Ahenicaed poion

0 1 2 3

Packe Lengh Packe ID Packe Frag.

Nmber Las Frag Flag

IP Packe Daa

Uncompressed

Header

Segmen 1 ... Segmen n Terminaor

Pariion IIPariion I

Proooa Message

EFBP Field

SRTP Packe

Encded Fame Bieam

Figure 6: Format of SRTP packets: Protozoa replaces the

EFBP payload containing carrier video bits with covert data.

Protozoa message transmission:

To embed covert IP packets in-

side an EFBP, Protozoa uses the message format depicted in Figure 6.

A single message consists of multiple segments followed by a Ter-

minator (i.e., a zero-length segment) which delimits the EFBP area

occupied by covert data. Each segment carries an entire IP packet

or a packet fragment. IP packet fragmentation may be required at

the sender’s endpoint shall the next available IP packet be larger

than the available EFBP space on the frame; this process will help

to use the covert channel in its maximal capacity. As a result, a

covert IP packet can be transmitted in a single segment or span

across multiple segments. Each segment has a small header that

allows the receiving endpoint to reassemble IP packet fragments.

Message transmission works as follows. For every new frame

generated by the video engine, there is an opportunity for sending

a new message, which causes the upstream hook to be executed

and given access to the encoded frame. The hook accesses the EFBP

data structure, checks its size, and tells the encoder service how

much free space exists in the frame for sending covert data. The

hook waits for the encoder to assemble a new message containing

locally queued IP packets. Then, the hook copies it into the EFBP

and returns, letting the WebRTC pipeline to proceed with its normal

execution until the resulting SRTP packets are transmitted. At the

receiving endpoint, the reverse operation is performed. Whenever

an encoded frame is reassembled, the downstream hook is executed

and extracts the Protozoa message from the EFBP eld. This mes-

sage is sent to the local decoder service, which reassembles the

ingress IP packets and forwards them to their rightful destination.

4.5 Prevent Video Decoding Malfunction

While it is possible to fully replace the content of the EFBP eld,

the undisciplined corruption of a frame bitstream can prevent the

video decoder in the WebRTC downstream pipeline from correctly

decoding video frame data at the receiver’s endpoint. In fact, we

empirically veried that in such situations, WebRTC triggers con-

gestion control mechanisms in the downstream pipeline for ensur-

ing the reception of video. In particular, it advertises a Picture Loss

Indication (PLI) in the accompanying RTCP control channel [

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

aimed at requesting the retransmission of a key frame upon being

unable to decode the corrupted frame data. In particular, VP8 pro-

duces two dierent types of encoded frames. Key frames can be

decoded without any reference to previous frames and provide seek-

ing points within a video stream. Delta frames are encoded with

reference to the prior key frame and ensuing frames. By advertising

PLIs and sending key frames upon detecting corrupted frames, the

resulting trac patterns produced by WebRTC applications would

make Protozoa vulnerable to trac analysis.

To overcome this problem, the downstream hook feeds the Web-

RTC video decoder with a pre-recorded sequence of valid encoded

frames instead of the corrupted frames received over the network.

Since the encoded frames may either be key frames or delta frames,

the downstream hook uses the uncompressed header information

kept intact after covert data embedding (see Figure 6) to decide

which type of frame and corresponding resolution (e.g., 640x480)

should be provided to the native WebRTC video decoder. Then, it

restores the corrupted bitstream with a bitstream of a valid frame.

This allows us to establish a covert channel where the size of egress

frames on the upstream pipeline is maintained, and to deliver the

decoder valid data so that it does not trigger congestion control.

4.6 Implementation and Optimizations

We developed a Protozoa prototype [

] by writing approximately

3,000 lines of C++ code. This includes the instrumentation of the

native WebRTC codebase of the Chromium browser v79.0.3945.117,

a stable release from January 2020. Protozoa requires the proper

establishment of a WebRTC video session for embedding data into

encoded frames sent over the wire. To this end, WebRTC must be

able to access a video feed that can be directly obtained from the

physical camera device available in the system. Alternatively, it

is possible to set up a camera emulator by using the

v4l2loopback

kernel module [

] and feed recorded video with the help of the

ffmpeg

video library [

]. In Section 6, we leverage the latter method

for evaluating Protozoa in light of dierent video proles.

Fine-tuning of IP packet queues:

We performed an important

optimization related to the size of the packet queues maintained

internally by Protozoa’s encoding service. Specically, we refer

to the queue that holds intercepted IP packets generated in the

upstream pipeline network namespace. A typical rule-of-thumb for

managing packet queues suggests the parameterization of a buer

size according to the following formula: Buer Size



RTT *Chan-

nel Bandwidth [

]. According to our experimental results, we con-

servatively assume that each packet in the queue has a size equal

to the MTU. Additionally, we empirically verify that the round-

trip-time experienced by our system is

⇡

200ms when connected in

a LAN network, i.e., when the latency between WebRTC hosts is

sub-millisecond. Conguring our packet queue with the above pa-

rameters yields a queue size of 24 packets for the 200ms round-trip-

time experienced by Protozoa and a bandwidth of approximately

1.4Mbps achieved when sending video at 640x480 resolution.

5 EVALUATION METHODOLOGY

This section describes our evaluation methodology for assessing

the quality and performance of our Protozoa prototype.

VM1

(C)

VM3

(P)

VM4

(O I)

WRTC 

VM2

(C M)

Media Media Web

Trafﬁc

SignallingSignalling

Figure 7: Laboratory setup.

5.1 Evaluation Goals and Approach

The goal of our experiments is twofold: i) evaluate the performance

of Protozoa’s covert channel in face of dierent network conditions,

and ii) assess the ability of our system to resist against detection

from an adversary able to perform statistical trac analysis attacks.

To measure the performance of the covert IP ows tunneled by

Protozoa covert WebRTC session, we leverage

iPerf

. This enables

us to stress the covert channel capacity.

When testing our system’s ability to resist trac analysis at-

tacks, we aim to reproduce the ideal conditions for the adversary.

Essentially, the attacker’s aim is to analyze the statistical properties

of WebRTC’s media (SRTP) and control (RTCP) packet ows so

as to identify Protozoa trac among legitimate WebRTC media

sessions. To this end, we apply a state-of-the-art trac classier [

which leverages two dierent sets of features: i) quantized packet

size distributions, and ii) summary statistics computed from packet

size and inter-arrival time distributions. Then, we collect a balanced

dataset composed of legitimate and Protozoa WebRTC packet traces,

and measure the AUC achieved by the above classier when per-

forming binary classication using 10-fold cross-validation. Note

that, in the wild, class imbalance is expected to be skewed towards

the abundance of legitimate streams and would likely make the

adversary’s task harder than in a controlled lab environment [

To ensure that the collected traces reect realistic convert trac

transmissions, we keep the channel busy by injecting articial cha

into the covert tunnel (using iPerf) while collecting these traces.

5.2 Experimental Testbed and Datasets

Our laboratory testbed, illustrated in Figure 7, is composed of four

64-bit Ubuntu 18.04.5 LTS virtual machines (VMs) provisioned with

two virtual 2,3 GHz Intel Core i5 CPU cores and 16GB of RAM.

VM1 and VM3 execute an instance of our prototype, operating as a

Protozoa client and proxy, respectively. VM2 acts as the gateway

and router for the two Protozoa VMs, and mimics the operation of

a censor middlebox by collecting packet traces required for con-

ducting statistical trac analysis. Finally, VM4 is used to pose as

a server in the open Internet which receives requests from the

Protozoa proxy in VM3 acting on behalf of the client in VM1.

To conduct our experiments, we collected a total of 2000 YouTube

video samples from four dierent categories (500 videos each) la-

beled by hand. These categories focus dierent video proles as-

sumed to be common in WebRTC services, and which we identify

as Chat,Coding,Gaming, and Sports. For generating packet traces

pertaining to legitimate and Protozoa media sessions, we split each

of the four datasets (one for each video prole) in half. Then, we

establish 250 legitimate WebRTC connections and 250 Protozoa

connections while mirroring the video transmitted on each side of

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

the connection. This allows us to avoid the contamination of the

training data by mixing the same video samples in both legitimate

and Protozoa connections. Video is set to be transmitted at 30fps

and at a 640x480 resolution over the

whereby.com

WebRTC service,

unless stated otherwise. Packet traces are collected for a duration of

30 seconds, a time interval shown in prior work to be sucient for

accurate detection of MCS streams using state-of-the-art statistical

trac analysis [

]. As described in Section 6, we validate that the

use of longer traces did not signicantly aect our results.

5.3 Metrics

We adopt a set of metrics for evaluating Protozoa’s covert channel

performance and resistance against statistical trac analysis:

Performance metrics:

In order to be able to compare Protozoa to

existing work, we leverage throughput as the metric of performance

of the covert channel. Additionally, we are interested in measuring

Protozoa’s covert channel eciency, which provides the ratio be-

tween the total amount of data transmitted in the covert channel

and the total available space in encoded video frame bitstreams.

Security metrics:

Akin to earlier studies on the resistance of MCS

systems to trac analysis attacks, we use the following metrics

to evaluate Protozoa’s trac analysis resistance capability: true

positive rate (TPR), false positive rate (FPR), and the area under the

ROC curve (AUC). The TPR measures the fraction of Protozoa ows

that are correctly identied as such, while the FPR measures the

proportion of legitimate ows erroneously classied as Protozoa

ows. An adversary aims at obtaining a high TPR and a low FPR

when performing covert trac classication. The Receiver Operat-

ing Characteristic (ROC) curve plots the TPR against the FPR for the

dierent possible cutout points for classiers possessing adjustable

internal thresholds. The AUC [

] summarizes this trade-o. Note

that an AUC of 0.5 is equivalent to random guessing.

In the following sections, we evaluate our prototype by resort-

ing to a set of microbenchmarks and by conducting a number of

experiments when deploying Protozoa in real-world scenarios.

6 EVALUATION USING MICROBENCHMARKS

In this section, we evaluate Protozoa using a series of microbench-

marks. We test our system on a baseline scenario and then study

the eects of varying the network and carrier conditions.

6.1 Baseline Deployment

Protozoa can be evaluated in multiple scenarios that depend on

many factors (e.g., carrier video, carrier WebRTC application, or

network conditions). Since validating all these dimensions is a

hard endeavor, we rst present an analysis of Protozoa based on

abaseline deployment scenario which gathers a set of conditions

expected to be found in a real-world deployment of Protozoa.

Our baseline deployment encompasses the following congu-

ration. First, we select Whereby, a popular WebRTC application,

as the carrier application for the Protozoa covert channel. Second,

we select the videos comprising the Chat dataset as carrier media.

Third, we assume that the round-trip-time (RTT) between Protozoa

endpoints (VM1 - VM3) is in the order of 50ms, a typical value for

connections established within the same continent [

]. Lastly,

Figure 8: Baseline trac analysis and performance results.

Duration (s) 10 20 30 40 50 60

AUC 0.56 0.60 0.59 0.58 0.58 0.61

Table 1: Classier’s AUC for varying trace durations.

we assume a 15ms RTT from the Protozoa proxy to an open Internet

service (VM3 - VM4). This value is reasonable even when accessing

foreign services due to the proliferation of CDN edge servers which

may be regionally co-located with a Protozoa proxy [58, 71].

6.2 Baseline Performance Results

We now evaluate Protozoa’s resistance against trac analysis and

assess the throughput and eciency of the covert channel in the

baseline deployment settings presented in the previous section.

Trac analysis resistance:

Figure 8a) depicts the ROC curve of

the classier when attempting to identify Protozoa connections re-

sorting to two sets of features: quantized packet size distributions,

and summary statistics. Firstly, we see that summary statistics

provide a better overall detection rate, enabling the classier to

obtain an AUC of 0.59 (for the remainder of our evaluation, we will

limit ourselves to present the results corresponding to the use of

summary statistics). Secondly, the ROC curve shows that a censor

would incur in a large FPR when blocking Protozoa ows resorting

to the state-of-the-art classier. Essentially, the FPR represents the

collateral damage that results from setting the TPR to a specic

cutovalue. As an example, if we assume that the censor would

like to block 80% of all Protozoa ows (TPR = 0.8), it would erro-

neously ag approximately 60% of all legitimate ows as covert

channels (FPR = 0.6). Although the cutoFPR value is determined

in a discretionary fashion by each censor (i.e., dierent censors can

possibly withstand dierent TPR/FPR tradeos), the gure shows

that distinguishing between Protozoa streams and legitimate media

streams is close to random guessing.

To assess the robustness of Protozoa for packet traces ofdierent

durations, we repeated the same set of experiments using trace

lengths up to 60 seconds as depicted in Table 1. These results suggest

that the size of the traces has no meaningful impact on the AUC,

given that the measured AUCs exhibit small uctuations between

0.56 and 0.61. Thus, in the interest of scaling up our experiments,

we conducted our remaining evaluation resorting to 30s traces.

Performance:

Figure 8b) depicts a boxplot showing the through-

put achieved by Protozoa’s covert channels. We can observe that,

under the baseline deployment conditions, Protozoa achieves an

average throughput of 1422 Kbps, while the 90th percentile sits at

1510 Kbps, and the 75th percentile at 1480Kbps. This amounts to a

throughput increase of 3

⇥

when compared to Facet, and a 3-fold

order of magnitude increase when compared to DeltaShaper.

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

Figure 9: Throughput of Protozoa’s covert channel when established over dierent network conditions.

Figure 10: ROC AUC obtained by the classier when detecting Protozoa ows under dierent network conditions.

Additionally, we analyzed the eciency of Protozoa’s covert

channel by measuring the ratio between the data embedded in each

outgoing frame and the size of the frame. When using iPerf to stress

the upstream covert channel link, we observed that Protozoa used

98.8% of the available frame space to transmit covert data. This

suggests that our packet encoding scheme can use the majority of

the encoded frame bitstream to transfer covert data.

Lastly, regarding resource consumption, the client and proxy

VMs peaked at a 21.6% usage of their total CPU and at 596MB

of memory usage. These numbers suggest that Protozoa can be

executed on various commodity hardware platforms.

In the next sections, we evaluate our system beyond our baseline

setup across multiple other network deployment scenarios.

6.3 Varying Network Conditions

Assessing the security of our prototype in face of dierent network

conditions is paramount i) to understand whether Protozoa can

remain undetectable in practical deployment scenarios, and ii) to

ascertain whether our system can withstand active network pertur-

bations introduced by a network adversary, aimed at disclosing the

operation of the system or at breaking the covert channel connec-

tion. To manipulate network conditions, we leveraged the trac

control facility Linux NetEm [

] and varied the network conditions

in the following dimensions: i) latency, ii) bandwidth, and iii) packet

loss. A recent study [

] reported that WebRTC connections can

withstand a limited range of network perturbations before being

torn down due to QoS constraints. We bound the network pertur-

bations to inject in the network according to the ranges suggested

by this study. Next, we detail the results of our experiments.

Latency variation of the covert channel:

We delay packets so

as to achieve a round-trip-time (RTT) of 15ms, 50ms, and 100ms

between Protozoa endpoints (VM1 - VM3). These values emulate re-

gional, intra-continental, and inter-continental RTTs [

], while

being kept within the bounds of 300ms, recommended for estab-

lishing real-time multimedia sessions with acceptable quality [

Our results are as follows. Figure 9 a) illustrates the breakdown of

throughput achieved by our prototype as the RTT between Protozoa

endpoints increases. It shows that the latency introduced between

endpoints does not impact the throughput obtained by Protozoa. In

particular, the throughput remains at an average of about 1420Kbps

in the three congurations tested. Figure 10 a) presents the ROC

curves obtained by the classier when attempting to detect Protozoa

in a network with dierent RTT congurations. We see that the

classier obtains a maximum AUC of 0.59. Thus, irrespective of

the latency introduced between endpoints, the adversary does not

obtain an advantage at distinguishing Protozoa ows.

Bandwidth variation of the covert channel:

We symmetrically

limit the bandwidth of the link to 1500Kbps, 750Kbps, and 250Kbps,

beyond the unrestricted bandwidth conditions assumed in our base-

line case. In these conditions, WebRTC streams use approximately

80% of the available bandwidth, agreeing with other studies [37].

Figure 9 b) shows that the achievable throughput tends to de-

crease as bandwidth is more scarce. For instance, while Proto-

zoa’s throughput averages 975Kbps when bandwidth is capped

at 1500Kbps, it drops to 460Kbps at 750Kbps, and attains an average

91Kbps when bandwidth is only 250Kbps. This eect is expected

since the constrained amount of bandwidth leads to the decrease of

frame rates and forces the downgrade of video resolution and en-

coded frame size, thus reducing the available space for embedding

covert data. For instance, a 250Kbps bandwidth cap only allows a

WebRTC stream to obtain

⇡

25 FPS at a low 480x270 resolution [

As for resistance to trac analysis, the AUC in Figure 10 b)

reveals that the bandwidth variation does not provide sucient

information for the classier to accurately distinguish between

legitimate and Protozoa connections, peaking at 0.65 AUC when

the bandwidth is limited to 1500Kbps.

Packet loss rate variation of the covert channel:

We assess

the properties of Protozoa when the media channel is subjected

to packet losses. Following the experiments of Jansen et al. [

we drop 2%, 5%, and 10% of the packets pertaining to WebRTC

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

Figure 11: Throughput and trac analysis resistance ob-

tained while varying the RTT between VM3 and VM4.

connections. Each of these loss rates causes WebRTC’s congestion

control to increase sending rate (2%), slowly increase sending rate

(5%), and converging data rate to values leading to the tear-down

of the video stream (10%). Typical recommendations for real-time

media trac sit at no more than 1% packet loss [67].

Figure 9 c) shows that while Protozoa’s throughput is negatively

aected by increasing packet loss rates, our prototype is still able

to sustain an average throughput of 1130Kbps for packet loss rates

of 2% and of 360Kbps for a loss rate of 5%. While a 10% packet loss

substantially decreases the throughput to 160Kbps, we note that

Protozoa’s covert channel connections remained active and did not

break for the duration of the experiment.

Lastly, the results in Figure 10 c) show that Protozoa preserves

high-levels of trac analysis resistance when the network link

between Protozoa endpoints is subject to variable packet loss rates.

Latency variation at the last mile:

We now focus on the impact

of the RTT between Protozoa’s proxy (VM3) and open Internet

services (VM4) to the network performance. Figure 11 b) shows

the breakdown of throughput achieved by Protozoa when the RTT

between VM1 and VM2 endpoints is set to 50ms and the last leg of

the connection to the Internet service ranges from 15ms to 100ms.

Similarly to our earlier experiments when varying the latency

between Protozoa endpoints, the throughput is not compromised

when latency increases between the Protozoa proxy and the Internet

service. The average throughput of our system is rather stable, at

around 1410Kbps, for the three tested congurations.

6.4 Varying Carrier Conditions

We also evaluate our system varying two carrier-specic conditions:

Varying video proles:

This experiment aims to test whether

dierent video proles used as cover media aect the throughput

of our system. Such a question arises since variable bitrate video

encoders, such as the ones used in WebRTC (e.g. VP8), adjust the

amount of output data according to the complexity of encoded video

segments. To answer this question, we evaluate the performance

of the covert channel when established through the Chat,Coding,

Gaming, and Sports video proles in our baseline deployment.

Performance-wise, Figure 12b) depicts the throughput achieved

by Protozoa when using dierent video proles as cover media.

We see that our system achieves a similar average throughput

of approximately 1400Kbps for Chat,Gaming, and Sports media

ows, while reaching an average throughput of 530Kbps when

transmitting Coding media. These results concur to the observation

that a large portion of video frames remain static in live coding

Figure 12: Throughput and trac analysis resistance ob-

tained while using dierent video proles.

Figure 13: Throughput and trac analysis resistance ob-

tained while using dierent WebRTC services.

videos. Additionally, these numbers suggest that the throughput

is consistent within each baseline, achieving a maximum standard

deviation of 157Kbps across the Chat,Gaming, and Sports baselines.

In turn, Figure 12a) shows the ROC curves for the classier when

attempting to distinguish Protozoa connections conducted over the

dierent video proles. The classier achieves a similar AUC for all

proles (

⇡

0.6 AUC), suggesting that the resistance against trac

analysis is preserved irrespective of the video prole used as cover.

Varying WebRTC services:

To assess whether the security and

performance properties of our system hold when media calls are es-

tablished over multiple WebRTC applications, we conducted further

experiments over two additional WebRTC services: a)

coderpad.io

– a live coding interview application – and b)

appr.tc

– Google’s

bare-bones demo application based on the simple WebRTC WebAPI.

Figure 13a) depicts the ROC curves for the classier when in-

specting Protozoa streams established through

coderpad.io

and

appr.tc

. The results show that the classier obtains an AUC of

0.58 for streams established over

coderpad.io

and an AUC of 0.60

for streams established over

appr.tc

. In both cases, we see that

Protozoa remains undetectable by a network eavesdropper.

As for the throughput when establishing a covert channel re-

sorting to the two alternative WebRTC applications, Figure 13b)

shows that Protozoa achieves an average throughput of 1420Kbps

for

appr.tc

and of 1388Kbps for

coderpad.io

, similar to what was

obtained with whereby.com, as presented previously in Section 6.2.

7 TESTING IN THE WILD

In this section, we test our system in multiple real-world settings.

First, we present the results of an experiment comprising the ex-

ecution of a set of typical workloads conducted by Internet users,

over Protozoa. Then, as proof of concept, we show that Protozoa is

able to evade the censorship apparatus of real-world adversaries

by using it to access censored content in China, Russia, and India.

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

Application Protocol Workload

A. Curl HTTP, FTP Page transfer (16 MB) in 89s

B. Transmission BitTorrent File transfer (2GB) in 3h5m

C. Mutt SMTP Send email (1KB) in 5.5ms

D. Irssi IRC Send text message (80B) in 0.44ms

E. VLC HTTP Video streaming at 20/14 fps in 240p/480p

F. Firefox HTTP Web-surng session

Table 2: Real application workloads over Protozoa.

7.1 Testing with Real Application Workloads

We tested Protozoa with multiple networked applications as de-

picted in Table 2. We used the baseline setup presented in Section 6.2.

To tunnel the trac of applications that do not natively support a

SOCKS proxy, such as

mutt

, we leverage

proxychains

[

], a SOCKS

proxy wrapper, to redirect such trac through Protozoa.

First, we used Curl (A) over the covert channel to download les

with sizes ranging from 1KB to 256MB using both the HTTP and

FTP protocols. We also veried that Protozoa is able to uniformly

distribute the bandwidth of the covert channel among simultaneous

Curl connections. In order to test Protozoa’s covert channel on

a dierent transport protocol, we congured the Transmission

BitTorrent client (B) to download a popular Linux distribution ISO.

We also found Protozoa to be successful when operating email

– Mutt (C) – and instant-messaging – Irssi IRC chat client (D) –

applications. Additionally, we tested the ability to stream video

content over VLC (E). Lastly, we ran Firefox (F) over Protozoa to

navigate dierent web pages and to stream videos from YouTube,

conrming that Protozoa enables interactive web-surng tasks.

Overall, the results of our experiments show that Protozoa is

able to accommodate a number of common Internet applications,

including web-browsing, video streaming, or bulk data transfer.

7.2 Evading State-Level Adversaries

To test Protozoa’s ability to circumvent real-world censors, we ran

Protozoa in three geographical locations known to be active targets

of Internet censorship – China [6], Russia [60], and India [82].

First, we identied sets of web pages that are blocked for each

country [

]. We selected web pages in several categories:

gambling, pornography, news/politics, drug sale, and circumven-

tion tools. For each set, we veried that the web pages could not

be directly accessed (i.e., without using Protozoa) using Firefox

running on a server physically deployed in the respective country.

Then, we repeated this access after setting up Protozoa covert ses-

sions. In each server, we congured a Protozoa client to establish

a covert channel towards a Protozoa proxy located in LA, USA,

and used this channel to access the blocked web pages. To run

our experiments in said countries, we resorted to virtual private

servers (VPSs) in Shanghai, Moscow, and Mumbai, respectively, and

deployed the Protozoa bundle amounting to a total of 150 MB.

Blocking policies:

We observed that browsing blocked websites

in Russia and India resulted in ISP blockpages, whereas in China

they would simply not load properly. A closer look at the trac

traces produced when trying to access blocked web pages revealed

that the GFW performs packet drops on connections aimed at black-

listed hosts. This observation is consistent with the behavior of the

GFW [

]. Browsing a blocked website from within Russia and India

showed that blocking policies implemented within datacenters are

WebRTC Application Reachability

China Russia India

appr.tc -33

aws.amazon.com/chime 333

codassium.com 333

coderpad.io 333

discordapp.com -33

gotomeeting.com 333

hangouts.google.com -33

messenger.com -33

slack.com 333

whereby.com 333

Table 3: Reachability tests on popular WebRTC services.

less restrictive from those applied on typical ISP connections, i.e.,

we could access websites which would trigger the return of ISP

blockpages when browsed over a VPN; therefore, given that our

VPSes are located inside datacenters, for ensuring a reliable Proto-

zoa testing, in Russia and India we route all VPS trac through a

VPN server hosted in the same country, where we obtain blockpages

when visiting forbidden websites. This dierentiation, however, did

not occur on the VPS within China, where the pages found to be

blocked when browsing over a VPN inside the country were also

blocked when accessing from our VPS in a datacenter.

Availability of WebRTC services:

Paramount to the functioning

of Protozoa is the ability to connect to a foreign WebRTC service.

Since Protozoa makes no assumption over the WebRTC application

used as a vehicle for the covert channel, it is only necessary to

nd one unblocked application within the censored region. Table 3

shows that multiple WebRTC applications are available in the coun-

tries focused in our evaluation. Importantly, the table shows that,

despite several WebRTC applications being blocked in China, a user

still has plenty of alternative WebRTC media applications that can

be used as a carrier for Protozoa covert channels.

Reaching censored content:

To reach our blocked page sets, we

leveraged

whereby.com

to establish Protozoa connections. We were

able to access all such blocked websites in China, Russia, and India.

7.3 Ethical Considerations

The experiments conducted in this section involve the access to

censored content from a number of vantage points within coun-

tries known to experience Internet censorship. These accesses raise

important ethical concerns since they risk triggering reprisals from

local authorities. We followed the best practices described in the

Menlo report [

] to guide three major decisions of our experimen-

tal design. First, we did not recruit volunteers for our experiments.

Instead, we rented VPSes from commercial VPS providers which

understand the legal implications of oering network and comput-

ing services in each country they operate. Second, albeit using the

signalling infrastructure of existing WebRTC applications, Protozoa

does not compromise in any way the integrity of such applications.

Covert trac is exclusively forwarded by replacing user-generated

video content. Lastly, we did not collect any sensitive user data.

8 SECURITY DISCUSSION

We now discuss some potential attacks to Protozoa and defenses:

Packet dropping:

An adversary may instrumentally drop a small

number of selected packets of WebRTC media streams in an attempt

to dramatically slow down the covert data transmission or disrupt

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

the functioning of Protozoa protocols causing, in either case, a

denial of service. In contrast to other systems [

], Protozoa

is robust against these attacks since it does not rely on specic

packets for managing covert channels. Moreover, Section 6.3 shows

that applications that use Protozoa’s covert channels are able to

tolerate a large percentage of dropped packets without terminating.

Active probing:

Active probing attacks aim at identifying Proto-

zoa proxies, e.g., by attempting to join some active chatroom and

identify the transmission of corrupted video streams which telltale

the presence of covert channels. By selecting WebRTC chatrooms

that implement member admission controls, e.g., using passwords

or contact list checks, Protozoa users can evade this attack.

Fingerprinting of cover videos:

If Protozoa is set up to stream

a pre-recorded cover video, an adversary may attempt to identify

a particular user by using that video for ngerprinting Protozoa

covert channels. This threat can be countered by: i) rotating the

pre-recorded video, ii) or feeding a live video from the local camera.

Long-term user proling:

An adversary may keep track of a

user’s interactions with WebRTC services so as to build a prole

of interactions with multimedia applications. An accurate prole

may enable an adversary to indirectly detect the usage of Protozoa

through connections with out-of-ordinary duration or by detecting

the placement of calls at unusual times of the day. Assessing the

feasibility of this threat is an interesting direction for future work.

9 RELATED WORK

We now describe past approaches aimed at evading Internet cen-

sorship and locate Protozoa in the spectrum of existing techniques.

9.1 Comparison with Similar Systems

Protozoa ts in the family of multimedia covert streaming systems.

It stands out by introducing a new technique – encoded media

tunneling. Next, we compare our system against two other branches

of this family (Figure 1 puts all these systems in perspective.)

Media protocol mimicking:

Previous systems have introduced

trac morphing [

] techniques for the transmission of covert

data by imitating multimedia protocols. For instance, by entirely

replacing the payload of media packets by encoded data, Skype-

Morph [

] and CensorSpoofer [

] deliver a reasonable throughput

of 344Kbps [

] and 64Kbps [

], respectively. However, due to the

diculty in mimicking the complete behavior of multimedia pro-

tocols, these systems are prone to be detected with 100% accuracy

through a combination of passive and active attacks [

]. In con-

trast, Protozoa provides not only strong resistance against trac

analysis, but also higher throughput (around 1.4Mbps).

Raw media tunneling:

Systems like FreeWave [

], Facet [

DeltaShaper [

], and CovertCast [

] modulate covert data in the au-

dio/video input of multimedia applications. Some of these systems

can sustain a reasonable throughput. For instance, Facet can reach

471Kbps [

] and CovertCast 168Kbps [

]. However, these sys-

tems are vulnerable to statistical trac analysis techniques [

FreeWave, Facet, CovertCast are detected with over 99% accuracy,

while DeltaShaper between 85%-95% [

]. Protozoa outperforms

these systems both performance and security wise.

9.2 Beyond Multimedia Covert Streaming

Protocol mimicking is a general technique for carrying covert data

by imitating the behavior of a carrier protocol. However, most

solutions [

] suer from the same limitations as their mul-

timedia protocol siblings and are prone to network attacks [

Protocol tunneling has been used in other contexts. SWEET [

CloudTransport [

], and Castle [

] tunnel covert data through

steganographically marked email, cloud storage services, and real-

time strategy games, respectively; meek [

] leverages domain

fronting to hide Tor trac inside HTTPS connections to allowed

hosts. However, unlike Protozoa, some of these systems have not

been evaluated against state-of-the-art trac analysis attacks, and

others have already been shown to be vulnerable to detection [

There are many other related techniques. Ephemeral proxies

like Snowake [

] (which uses WebRTC connections) redirect

trac through short-lived proxies provided by volunteers; however,

unlike Protozoa, the covert tracisngerprintable and the pres-

ence of secret messages can be detected through trac analysis.

Protocol randomization [

] transforms trac into random bytes

to evade protocol blacklists, but it fails in the presence of protocol

whitelisting and is vulnerable to entropy analysis [

]. Refraction

networking [

] incorporates special

trac redirection routers inside cooperative ISPs which need to

be carefully placed, otherwise a censor can avoid network paths

containing such routers [

]. In contrast, Protozoa relies on

individual trusted users located outside the censored region. Packet

manipulation strategies [

] aim at invalidating the state

of censors’ rewalls; Protozoa’s covert channels can breach through

such rewalls provided that WebRTC trac is not blocked.

Lastly, some systems provide access to censored content cached

in CDNs [

]. Protozoa provides access to any publicly avail-

able content accessible to the Protozoa proxies. MassBrowser [

]

leverages cache browsing [

] and volunteer proxies to reach

censored content. However, since the connections between clients

and proxies are protected with a variant of Obfsproxy [

], they

are also aected by the limitations of protocol randomization.

10 CONCLUSIONS

This paper introduced Protozoa, the rst multimedia-based censor-

ship circumvention tool which generates secure covert channels by

instrumenting the innards of the WebRTC multimedia framework.

Our evaluation shows that Protozoa trac cannot be distinguished

from typical WebRTC ows by state-of-the-art trac analysis tech-

niques. Further, the results of our evaluation show that Protozoa

enables an increase in throughput of up to three orders of magnitude

when compared against similar (and less secure) tunneling tools.

Currently, Protozoa requires active user support at the proxy’s end

and demands users to nd trusted proxies for exchanging covert

content. Devising a scalable solution for nding trusted proxies is

an interesting direction for future work.

Acknowledgments:

We thank our shepherd, Nick Feamster, and

the anonymous reviewers for their comments. This work was par-

tially supported by national funds through Fundação para a Ciência

e a Tecnologia (FCT) via the SFRH/BD/136967/2018 grant, and the

PTDC/EEI-COM/29271/2017 and UIDB/ 50021/ 2020 projects.

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

REFERENCES

[1]

A, S., A, H.,  H, J. A. Internet censorship in Iran : A rst

look. In Proceedings of the 3rd USENIX Workshop on Free and Open Communications

on the Internet (Washington, DC, USA, 2013).

[2]

B, D. Protozoa code repository. https://github.com/dmbb/Protozoa,

2020. Accessed: 2020-08-20.

[3]

B, D., S, N.,  R, L. Deltashaper: Enabling unob-

servable censorship-resistant tcp tunneling over videoconferencing streams. In

Proceedings on Privacy Enhancing Technologies (Minneapolis, MN, USA, 2017),

vol. 2017(4), pp. 5–22.

[4]

B, D., S, N.,  R, L. Eective detection of multimedia

protocol tunneling using machine learning. In Proceedings of the 27th USENIX

Security Symposium (Baltimore, MD, USA, 2018).

[5]

B, M., MG, D., N, M., C, E.,  N, K. The

secure real-time transport protocol (srtp). RFC 3711, March 2004.

[6]

B, K., H, G., Q, X.,  L, D. Geneva: Evolving censorship

evasion strategies. In Proceedings of the ACM SIGSAC Conference on Computer

and Communications Security (London, UK, 2019), pp. 2199–2214.

[7]

B, C.,  G, I. Slitheen: Perfectly imitated decoy routing

through trac replacement. In Proceedings of the 2016 ACM SIGSAC Conference

on Computer and Communications Security (Vienna, Austria, 2016), pp. 1702–1714.

[8]

B, C.,  G, I. Secure asymmetry and deployability for decoy

routing systems. In Proceedings on Privacy Enhancing Technologies (Barcelona,

Spain, 2018), vol. 2018 (3), pp. 43–62.

[9]

B, C., H, A.,  S,V. Cloudtransport: Using cloud

storage for censorship-resistant networking. In Privacy Enhancing Technologies,

vol. 8555 of Lecture Notes in Computer Science. Springer International Publishing,

2014, pp. 1–20.

[10]

C C  R. Report says China internet rms censored coronavirus

terms, criticism early in outbreak. https://www.reuters.com/article/us-health-

coronavirus-china- censorship/report-says- china-internet- rms-censored-

corona vir us-ter ms- c rit icism - ear ly- in - outbreak- i dUS KBN 20Q1V S, 2020.

Accessed: 2020-08-20.

[11]

C, A., C, T., C, M., DC, E., F, A., 

K, M. A. Censorship in the wild: Analyzing Internet ltering in Syria. In

Proceedings of the 2014 Conference on Internet Measurement Conference (Vancouver,

BC, Canada, 2014), pp. 285–298.

[12]

C, V., B, A.,  K, V. Anomaly detection: A survey. ACM

computing surveys (CSUR) 41, 3 (2009).

[13]

D, R. Obfsproxy: the next step in the censorship arms race. https:

//blog.torproject.org/blog/obfsproxy- next-step- censorship-arms- race, 2012.

Accessed: 2020-08-20.

[14]

D, D.,  K, E. The Menlo report: Ethical principles guiding

information and communication technology research. In U.S.Department of

Homeland Security, Tech. Rep. (2012).

[15]

D, K. P., C, S. E., R, T.,  S, T. Protocol misidenti-

cation made easy with format-transforming encryption. In Proceedings of the

2013 ACM SIGSAC Conference on Computer & Communications Security (Berlin,

Germany, 2013), pp. 61–72.

[16]

D, K. P., C, S. E.,  S, T. Marionette: A programmable

network-trac obfuscation system. In Proceedings of the 24th USENIX Conference

on Security Symposium (Washington, D.C., USA, 2015), pp. 367–382.

[17]

E, D., J, C., M, V., S, W. T., T, B., V W,

M.,  J, A. Rebound: Decoy routing on asymmetric routes via error

messages. In Proceedings of the 2015 IEEE 40th Conference on Local Computer

Networks (LCN) (Clearwater Beach, FL, USA, 2015), pp. 91–99.

[18]

E, R., F, D., W, P., F, N., W, N.,  P,

V. Examining how the great rewall discovers hidden circumvention servers.

In Proceedings of the 2015 ACM Conference on Internet Measurement Conference

(Tokyo, Japan, 2015), pp. 445–458.

[19]

F, T. Roc graphs: Notes and practical considerations for researchers.

Machine Learning 31 (01 2004), 1–38.

[20] FF. https://mpeg.org, 2000. Accessed: 2020-08-20.

[21]

F, D. Threat modeling and circumvention of Internet censorship. PhD thesis,

EECS Department, University of California, Berkeley, 2017.

[22]

F, D., H, N., E, J., S, E., B, D., D, R.,

 P, P. Evading censorship with browser-based proxies. In Proceedings of

the 12th International Conference on Privacy Enhancing Technologies (Vigo, Spain,

2012), pp. 239–258.

[23]

F, D., L, C., H, R., W, P.,  P, V. Blocking-resistant

communication through domain fronting. In Proceedings on Privacy Enhancing

Technologies 2015.2 (Philadelphia, PA, USA, 2015), pp. 46–64.

[24]

F, S., D, F., S, W., MD, A., VS, B., H,

R., K, A., K, M., R, D. G., S, S., B, N., H

, A.,  W, E. An ISP-Scale Deployment of TapDance . In

Proceedings of the 7th USENIX Workshop on Free and Open Communications on

the Internet (Vancouver, BC, 2017).

[25]

F, S., W, J., T, S. C., H, J. A., B, N.,  W

, E. Conjure: Summoning proxies from unused address space. In Proceedings

of the 2019 ACM SIGSAC Conference on Computer and Communications Security

(London, United Kingdom, 2019), p. 2215–2229.

[26]

G, G., A, A.,  K, T. Internet censorship in Thailand:

User practices and potential threats. In Proceedings of the 2nd IEEE European

Symposium on Security & Privacy (Paris, France, 2017).

[27]

G, J., S, M.,  H, N. Cover your acks: Pitfalls of covert

channel censorship circumvention. In Proceedings of the 2013 ACM SIGSAC

Conference on Computer and Communications Security (Berlin, Germany, 2013),

pp. 361–372.

[28]

G D  WRTC. Getting started with WebRTC. https://webrtc.o

rg/getting-started/overview, 2019. Accessed: 2020-08-20.

[29]

H, B., N, R., G, P.,  J, R. Games without frontiers:

Investigating video games as a covert channel. In 2016 IEEE European Symposium

on Security and Privacy (Saarbrucken, Germany, 2016), IEEE, pp. 63–77.

[30]

H, S. Network emulation with netem. 6th Linux and open source

conference for Australia and New Zealand - linux.conf.au (2005).

[31]

H, J. C. As China Cracks Down on Coronavirus Coverage, Journalists

Fight Back. https://www.nytimes.com/2020/03/14/business/media/coronavirus-

china-journalists.html, 2020. Accessed: 2020-08-20.

[32]

H, C., L, Z.,  G, E. Algorithmically bypassing

censorship on Sina Weibo with nondeterministic homophone substitutions. In

Proceedings of the 9th International Conference on Web and Social Media (Oxford,

UK, 2015), AAAI.

[33]

H, J.,  H, A. Cachebrowser: Bypassing chinese cen-

sorship without proxies using cached content. In Proceedings of the 22nd ACM

SIGSAC Conference on Computer and Communications Security (2015), pp. 70–83.

[34]

H, A., B, C.,  S, V. The parrot is dead: Ob-

serving unobservable network communications. In Proceedings of the 2013 IEEE

Symposium on Security and Privacy (San Francisco, CA, USA, 2013), pp. 65–79.

[35]

H, A., N, G. T., C, M.,  B, N. Cirripede:

Circumvention infrastructure using router redirection with plausible deniability.

In Proceedings of the 18th ACM Conference on Computer and Communications

Security (Chicago, IL, USA, 2011), pp. 187–200.

[36]

H, A., R, T. J., B, N.,  S, A. C. I want my voice to

be heard: IP over Voice-over-IP for unobservable censorship circumvention. In

Proceedings of the 20th Annual Network & Distributed System Security Symposium

(San Diego, CA, USA, 2013).

[37]

J, B., G, T., G, V., K, F.,  Z, G. Performance

evaluation of webrtc-based video conferencing. ACM SIGMETRICS Performance

Evaluation Review 45, 2 (2018), 56–68.

[38]

K, J., E, D., J, A., J, C., L, G., M, D., 

S, T. Decoy routing: Toward unblockable Internet communication. In

Proceedings of the USENIX Workshop on Free and Open Communications on the

Internet (San Francisco, CA, USA, 2011).

[39]

K, S., E, T., S, L., S, C. M., M, S. J.,  G

, I. Sok: Making sense of censorship resistance systems. In Proceedings on

Privacy Enhancing Technologies (Darmstadt, Germany, 2016), vol. 2016, pp. 37–61.

[40]

K, S., J, M., A, P. D.,  P, V. Towards illuminating a

censorship monitor’s model to facilitate evasion. In Proceedings of the 3rd USENIX

Workshop on Free and Open Communications on the Internet (Washington, D.C.,

USA, 2013).

[41]

K, G., P, J.,  R, M. E. Reverse-engineering censorship in china:

Randomized experimentation and participant observation. Science 345, 6199

(2014).

[42]

K, J., CN, M., N, J. Q., S, A.,  C, J. R.

Every rose has its thorn: Censorship and surveillance on social video platforms

in China. In Proceedings of the 5th USENIX Workshop on Free and Open Communi-

cations on the Internet (Washington, D.C., USA, 2015).

[43]

K, J., R, L.,  CN, M. An analysis of automatic image

ltering on wechat moments. In Proceedings of the 8th USENIX Workshop on Free

and Open Communications on the Internet (Baltimore, MD, USA, 2018).

[44]

K, K., H, T., K, D.,  P, C. SkypeLine: Robust hidden data

transmission for VoIP. In Proceedings of the 2016 ASIA Computer and Communi-

cations Security (Xi’an, China, 2016).

[45]

L, F., R, A., K, A. M., N, A. A., C, D., G, P., 

M, A. lib

•

erate,(n) a library for exposing (trac-classication) rules and

avoiding them eciently. In Proceedings of the Internet Measurement Conference

(London, UK, 2017), pp. 128–141.

[46]

L, S., S, M.,  H, N. Facet: Streaming over videoconferencing for

censorship circumvention. In Proceedings of the 13th Workshop on Privacy in the

Electronic Society (Scottsdale, AZ, USA, 2014), pp. 163–172.

[47]

L, S.,  R, S. P. Real-time communications in the web: Issues,

achievements, and ongoing standardization eorts. IEEE Internet Computing 16,

5 (2012), 68–73.

[48]

MG, D.,  R, E. Datagram transport layer security (dtls) extension

to establish keys for the secure real-time transport protocol (srtp). RFC 5764,

May 2010.

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA

[49]

MK, N., A, G.,  K, I. Sizing router buers (redux).

SIGCOMM Computer Communication Review 49, 5 (Nov. 2019), 69–74.

[50]

MP, R., H, A.,  S, V. CovertCast: Using live

streaming to evade internet censorship. In Proceedings on Privacy Enhancing

Technologies (Darmstadt, Germany, 2016), vol. 2016(3), pp. 212–225.

[51]

M, H., L, B., D, M.,  G, I. Skypemorph:

Protocol obfuscation for Tor bridges. In Proceedings of the 2012 ACM Conference

on Computer and Communications Security (Raleigh, NC, USA, 2012), pp. 97–108.

[52]

M, M. B., D, M., A, S. I.,  K, N. When the Internet goes

down in Bangladesh. In Proceedings of the 20th ACM Conference on Computer-

Supported Cooperative Work and Social Computing (Portland, Oregon, USA, 2017).

[53]

N, M.,  H, A. Game of decoys: Optimal decoy routing through

game theory. In Proceedings of the 23rd ACM SIGSAC Conference on Computer

and Communications Security (Vienna, Austria, 2016), pp. 1727–1738.

[54]

N, M., Z, H.,  H, A. The waterfall of liberty: Decoy

routing circumvention that resists routing attacks. In Proceedings of the 2017 ACM

SIGSAC Conference on Computer and Communications Security (2017), pp. 2037–

2052.

[55]

N, M., Z, H.,  H, A. MassBrowser: Unblocking the

censored web for the masses, by the masses. In Proceedings of the

27C⌘

Annual

Network and Distributed System Security Symposium (San Diego, CA, USA, 2020).

[56] N F. http://www.netfilter.org/, 1998. Accessed: 2020-08-20.

[57]

N, A. A., C, S., W, Z., H, N. P., R, A., C,

N.,  G, P. Iclab: A global, longitudinal internet censorship measurement

platform. In Proceedings of the 41st IEEE Symposium on Security and Privacy (San

Francisco, CA, USA, 2020).

[58]

N, E., S, R. K.,  S, J. The akamai network: a platform for

high-performance internet applications. ACM SIGOPS Operating Systems Review

44, 3 (2010), 2–19.

[59]

P L  B I. Here are all the major US tech companies

blocked behind China’s ’Great Firewall’. https://www.businessinsider.com/major-

us-tech- companies-blocked-from-operating-in- china-2019-5, 2019. Accessed:

2020-08-20.

[60]

R, R., R, R. S., B, M., O, V., E, L.,

E, A., S, S., I, M.,  E, R. Decentralized control:

A case study of russia. In Proceedings of the

27C⌘

Network and Distributed Systems

Security Symposium (San Diego, CA, USA, 2020).

[61]

RFC 1928 SOCKS P V 5. https://tools.ietf.org/html/rf c1928.

Last Accessed: 2020-08-20.

[62]

0GH. Proxychains-ng. https://github.com/rofl0r/proxychains-ng,

2011. Accessed: 2020-08-20.

[63]

R, R. R. Handbook of SDP for Multimedia Session Negotiations: SIP and WebRTC

IP Telephony. CRC Press, 2018.

[64]

R, L., K, J.,  CN, M. Censored Contagion: How

Information on the Coronavirus is Managed on Chinese Social Media. https:

//citizenlab.ca/2020/03/censored-contagion-how- information-on-the-

coronavirus-is- managed-on- chinese-social-media/, 2020. Accessed: 2020-08-20.

[65]

S, M., G, J., T, C.,  H, N. Routing around

decoys. In Proceedings of the ACM Conference on Computer and Communications

Security (Raleigh, North Carolina, USA, 2012), pp. 85–96.

[66]

S, S. R.,  A, F. Improving meek with adversarial techniques.

In Proceedings of the 9th USENIX Workshop on Free and Open Communications on

the Internet (Santa Clara, CA, USA, 2019).

[67]

S, T.,  H, C. End-to-End QoS Network Design: Quality of Service

in LANs, WANs, and VPNs. Cisco Press, 2004.

[68]

T K Y  GH. Analyzing-Web-Censorship-Mechanisms-in-

India. https://github.com/tarun14110/Analyzing-Web-Censorship- Mechanisms-

in-India/blob/master/possibly

blocked

websites.txt, 2018. Accessed: 2020-08-20.

[69]

T, M. C., A, S., A, P, V. Sok: Towards ground-

ing censorship circumvention in empiricism. In Proceedings of the IEEE Symposium

on Security and Privacy (2016), pp. 914–933.

[70]

42. https://github.com/umlaeute/v4l2loopback, 2005. Last Accessed:

2020-08-20.

[71]

V, A.,  P, G. Content delivery networks: status and trends. IEEE

Internet Computing 7, 6 (2003), 68–74.

[72]

V B. IP Latency Statistics. https://enterprise.verizon.com/terms/l

atency/, 2015. Accessed: 2020-08-20.

[73]

W, L., D, K. P., A, A., R, T.,  S, T. Seeing

through network-protocol obfuscation. In Proceedings of the 22nd ACM SIGSAC

Conference on Computer and Communications Security (Denver, CO, USA, 2015),

pp. 57–69.

[74]

W, Q., G, X., N, G. T., H, A.,  B, N. Censor-

spoofer: Asymmetric communication using IP spoong for censorship-resistant

web browsing. In Proceedings of the 2012 ACM Conference on Computer and

Communications Security (Raleigh, NC, USA, 2012), pp. 121–132.

[75] W, Z., C, Y., Q, Z., S, C.,  K, S. V. Your state is

not mine: a closer look at evading stateful internet censorship. In Proceedings of

the Internet Measurement Conference (London, UK, 2017), pp. 114–127.

[76]

W, Z., W, J., Y, V., B, L., C, S., W,

F.,  B, D. Stegotorus: A camouage proxy for the Tor anonymity system.

In Proceedings of the 2012 ACM Conference on Computer and Communications

Security (Raleigh, NC, USA, 2012), pp. 109–120.

[77]

W, C. V., C, S. E.,  M, F. Trac morphing: An ecient

defense against statistical trac analysis. In Proceedings of the 16th Network and

Distributed Security Symposium (San Diego, CA, USA, 2009), pp. 237–250.

[78]

W, E., S, C. M.,  H, J. A. Tapdance: End-to-middle

anticensorship without ow blocking. In Proceedings of the 23rd USENIX Security

Symposium (San Diego, CA, 2014), pp. 159–174.

[79]

W, E., W, S., G, I.,  H, J. A. Telex: An-

ticensorship in the network infrastructure. In Proceedings of the 20th USENIX

Security Symposium (San Francisco, CA, USA, 2011).

[80]

X, R.,  K, J. An ecient method to determine which combination

of keywords triggered automatic ltering of a message. In Proceedings of the 9th

USENIX Workshop on Free and Open Communications on the Internet (Santa Clara,

CA, USA, 2019).

[81]

X, X., M, Z. M.,  H, J. A. Internet censorship in china: Where

does the ltering occur? In Proceedings of the 12th International Conference on

Passive and Active Network Measurement (Vienna, Austria, 2011), pp. 133–142.

[82]

Y, T. K., S, A., G, D., S, P. K.,  C, S. Where

the light gets in: Analyzing web censorship mechanisms in India. In Proceedings

of the Internet Measurement Conference (Boston, MA, USA, 2018).

[83]

Y I  NTT C. A Study of WebRTC Security.

https://webrtc-security.github.io/, 2015. Accessed: 2020-08-20.

[84]

Z, S., A, G.,  B, P. A survey of covert channels and

countermeasures in computer network protocols. IEEE Communications Surveys

& Tutorials 9, 3 (2007), 44–57.

[85]

. Register of Internet Addresses ltered in Russian Federation.

https://github.com/zapret-info/z- i, 2020. Accessed: 2020-08-20.

[86]

Z, W., H, A., C, M.,  B, N. Sweet: Serving the

web by exploiting email tunnels. In Proceedings of the 6th Workshop on Hot Topics

in Privacy Enhancing Technologies (Bloomington, IN, USA, 2013).

[87]

Z, H.,  H, A. Practical censorship evasion leveraging

content delivery networks. In Proceedings of the ACM SIGSAC Conference on

Computer and Communications Security (Vienna, Austria, 2016), pp. 1715–1726.

Session 1A: Anonymous Routing and Censorship

CCS '20, November 9–13, 2020, Virtual Event, USA