Threat model for the obfs2 obfuscation protocol

                              George Kadianakis
                               Nick Mathewson

0. Abstract

   We discuss the intended threat model for the 'obfs2' protocol
   obfuscator, its limitations, and its implications for the protocol
   design.

   The 'obfs2' protocol is based on Bruce Leidl's obfuscated SSH layer,
   and is documented in the 'doc/protocol-spec.txt' file in the obfsproxy
   distribution.

1. Adversary capabilities and non-capabilities

   We assume a censor with limited per-connection resources.

   The adversary controls the infrastructure of the network within and
   at the edges of her jurisdiction, and she can potentially monitor,
   block, alter, and inject traffic anywhere within this region.

   However, the adversary's computational resources are limited.
   Specifically, the adversary does not have the resources in her
   censorship infrastructure to store very much long-term information
   about any given IP or connection.

   The adversary also holds a blacklist of network protocols, which she
   is interested in blocking. We assume that the adversary does not have
   a complete list of specific IPs running that protocol, though
   preventing this is out-of-scope.

2. The adversary's goals

   The censor wants to ban particular encrypted protocols or
   applications, and is willing to tolerate some collateral damage, but
   is not willing to ban all encrypted traffic entirely.

3. Goals of obfs2

   Currently, most attackers in the category described above implement
   their censorship by one or more firewalls that looking for protocol
   signatures and block protocols matching those signatures. These
   signatures are typically in the form of static strings to be matched
   or regular expressions to be evaluated, over a packet or TCP flow.

   obfs2 attempts to counter the above attack by removing content
   signatures from network traffic. obfs2 encrypts the traffic stream
   with a stream cipher, which results in the traffic looking uniformly
   random.

4. Non-goals of obfs2

   obfs2 was designed as a proof-of-concept for Tor's pluggable
   transport system: it is simple, useable and easily implementable. It
   does _not_ try to protect against more sophisticated adversaries.

   obfs2 does not try to protect against non-content protocol
   fingerprints, like the packet size or timing.

   obfs2 does not try to protect against attackers capable of measuring
   traffic entropy.

   obfs2 (in its default configuration) does not try to protect against
   Deep Packet Inspection machines that expect the obfs2 protocol and
   have the resources to run it. Such machines can trivially retrieve
   the decryption key off the traffic stream and use it to decrypt obfs2
   and detect the Tor protocol.

   obfs2 assumes that the underlying protocol provides (or does not
   need!) integrity, confidentiality, and authentication; it provides
   none of those on its own.

   In other words, obfs2 does not try to protect against anything other
   than fingerprintable TLS content patterns.

   That said, obfs2 is not useless. It protects against many real-life
   Tor traffic detection methods currentl deployed, since most of them
   currently use static SSL handshake strings as signatures.