Blocking-resistant communication through domain fronting

Abstract: We describe “domain fronting,” a versatile
censorship circumvention technique that hides the remote
endpoint of a communication. Domain fronting
works at the application layer, using HTTPS, to communicate
with a forbidden host while appearing to communicate
with some other host, permitted by the censor.
The key idea is the use of different domain names at
different layers of communication. One domain appears
on the “outside” of an HTTPS request—in the DNS request
and TLS Server Name Indication—while another
domain appears on the “inside”—in the HTTP Host
header, invisible to the censor under HTTPS encryption.
A censor, unable to distinguish fronted and nonfronted
traffic to a domain, must choose between allowing
circumvention traffic and blocking the domain entirely,
which results in expensive collateral damage. Domain
fronting is easy to deploy and use and does not require
special cooperation by network intermediaries. We
identify a number of hard-to-block web services, such as
content delivery networks, that support domain-fronted
connections and are useful for censorship circumvention.
Domain fronting, in various forms, is now a circumvention
workhorse. We describe several months of deployment
experience in the Tor, Lantern, and Psiphon circumvention
systems, whose domain-fronting transports
now connect thousands of users daily and transfer many
terabytes per month.


Privacy-Preserving Network Flow Recording

Network flow recording is an important tool with applications that range from legal compliance and security auditing
to network forensics, troubleshooting, and marketing. Unfortunately, current network flow recording technologies
do not allow network operators to enforce a privacy policy on the data that is recorded, in particular how this
data is stored and used within the organization. Challenges to building such a technology include the public
key infrastructure, scalability, and gathering statistics about the data while still preserving privacy.

We present a network flow recording technology that addresses these challenges by using Identity Based Encryption in combination with privacy-preserving semantics for on-the-fly statistics. We argue that our implementation
supports a wide range of policies that cover many current applications of network flow recording. We also
characterize the performance and scalability of our implementation and find that the encryption and statistics scale
well and can easily keep up with the rate at which commodity systems can capture traffic, with a couple of interesting
caveats about the size of the subnet that data is being recorded for and how statistics generation is affected
by implementation details. We conclude that privacy preserving network flow recording is possible at 10 gigabit
rates for subnets as large as a /20 (4096 hosts).

Because network flow recording is one of the most serious threats to web privacy today, we believe that developing
technology to enforce a privacy policy on the recorded data is an important first step before policy makers
can make decisions about how network operators can and should store and use network flow data. Our goal in
this paper is to explore the tradeoffs of performance and scalability vs. privacy, and the usefulness of the recorded
data in forensics vs. privacy.


Differential Privacy for Collaborative Security

Fighting global security threats with only a local view is inherently difficult. Internet network operators need to fight global phenomena
such as botnets, but they are hampered by the fact that operators can observe only the traffic in their local domains. We propose a
collaborative approach to this problem, in which operators share aggregate information about the traffic in their respective domains
through an automated query mechanism. We argue that existing work on differential privacy and type systems can be leveraged to
build a programmable query mechanism that can express a wide range of queries while limiting what can be learned about individual
customers. We report on our progress towards building such a mechanism, and we discuss opportunities and challenges of the
collaborative security approach.