|
|
|
[[TOC]]
|
|
|
|
|
|
|
|
= obfs4 Transport Evaluation =
|
|
|
|
The obfs4 protocol was developed and is in the process of being deployed by the Tor Project in response to the vulnerability of the obfs3 protocol to detection via active probing attacks. It is expected to supersede the obfs3 protocol as the front-line Pluggable Transport used by most Tor users.
|
|
|
|
|
|
|
|
From a design standpoint, the obfs4 protocol is significantly closer to the ScrambleSuit protocol by Philipp Winter, and can be described as a direct descendant with incremental cryptographic improvements. As the threat models are extremely similar, most of the comments regarding obfs4 will also apply to ScrambleSuit .
|
|
|
|
|
|
|
|
NB: The author of this evaluation is the primary designer, author, and maintainer of the obfs4 protocol and obfs4proxy software package.
|
|
|
|
|
|
|
|
== 1. Review Coverage and Reviewability Evaluation ==
|
|
|
|
=== 1.1 Is the software published, and is it entirely free / open source software? ===
|
|
|
|
The obfs4 protocol is implemented as part of the FOSS obfs4proxy suite in the Go language. There is a possibility that it will additionally be incorporated into the obfsclient C++ package for systems that are currently not targeted by the Go compiler, which will also be FOSS.
|
|
|
|
|
|
|
|
As the protocol is relatively simple, there are no special considerations regarding distribution.
|
|
|
|
|
|
|
|
=== 1.2 How well documented is the design? ===
|
|
|
|
The design is documented and includes a [https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/doc/obfs4-spec.txt comprehensive specification, along with a threat model].
|
|
|
|
|
|
|
|
=== 1.3 How much existing review has been done? Is the project active? ===
|
|
|
|
The project has had a moderate amount of third party review, and is under active development. As versioning obfuscated protocols is hard, it is unlikely that the obfs4 protocol itself will change significantly and further improvements will likely be made in the form of newer protocol designs.
|
|
|
|
|
|
|
|
=== 1.4 What is the design's deployment history? ===
|
|
|
|
The protocol was developed over the course of 2014, with a general call for bridge operators to run bridges sent to the "tor-relays" mailing list on September 26th, 2014. It has been incorporated into the Tor Browser 4.5 alpha series of releases since 4.5a1, released in November 2014.
|
|
|
|
|
|
|
|
Android availability in Orbot started as of Orbot v15 alpha 5.
|
|
|
|
|
|
|
|
The low user count can primarily be attributed to the fact that there have been no stable releases of Tor Browser or Orbot integrating obfs4 support as of this date.
|
|
|
|
|
|
|
|
https://metrics.torproject.org/userstats-bridge-transport.html?graph=userstats-bridge-transport&start=2014-09-01&end=2015-04-17&transport=obfs4
|
|
|
|
|
|
|
|
== 2 Design Evaluation ==
|
|
|
|
=== 2.1 How difficult or expensive will it be to block the design? ===
|
|
|
|
The design improves on the vulnerability to censorship based on active attackers identifying suspect flows and attempting to confirm which protocol is running via active attacks (See 2.4).
|
|
|
|
|
|
|
|
There are moderate attempts to obfuscate traffic volume, and the capability to obfuscate timing related information, however the latter is disabled in the default configuration as such attacks are believed to be expensive for the censor to mount, and the obfuscation adds a non-trivial amount of overhead.
|
|
|
|
|
|
|
|
Effective blocking strategies that are not the result of cryptographic breaks are currently believed to be primarily protocol whitelist and endpoint enumeration based, along with certain attacks that are the result of Tor's bridge and software design.
|
|
|
|
|
|
|
|
=== 2.2 What impact on anonymity does the design have, if any? ===
|
|
|
|
There is no negative anonymity impact with the obfs4 protocol, and it is possible that the traffic volume obfuscation (along with the timing obfuscation, if enabled) may add limited resistance to certain fingerprinting attacks on the user's anonymity.
|
|
|
|
|
|
|
|
However any such additional resistance is coincidental as such properties were not part of the primary design goals when the protocol was created.
|
|
|
|
|
|
|
|
=== 2.3 What is the design's overhead in terms of computational costs and bandwidth? ===
|
|
|
|
The obfs4 protocol has a variable amount of added overhead depending on the configuration. In particular the traffic length obfuscation attempts to mask data transmission sizes by modifying the burst length to fit a pseudorandom distribution. The default configuration limits the extra padding to under ~1500 bytes, however it is possible to adjust the configuration to pad each frame send on the network so they have a randomized packet size.
|
|
|
|
|
|
|
|
Each obfs4 handshake will additionally add a one time data transfer of up to 8192 bytes in both directions.
|
|
|
|
|
|
|
|
The cryptographic CPU overhead is minimal as unlike previous protocols the handshake uses high speed elliptic curve cryptography (Curve25519), and the link encryption primitives (Salsa20 and Poly1305) are easy to implement with high performance in software.
|
|
|
|
|
|
|
|
=== 2.4 How resilient is the design to active probing? ===
|
|
|
|
The obfs4 protocol requires that the client proves to the server that it knows a public key belonging to the server before the server will respond with any traffic, and thus is immune to active probing attacks.
|
|
|
|
|
|
|
|
== 3 Implementation Evaluation ==
|
|
|
|
=== 3.1 Does the design use the Tor Project's Pluggable Transport Application Programming Interface already? ===
|
|
|
|
Yes, the obfs4 implementation that is part of obfs4proxy uses the PT API.
|
|
|
|
|
|
|
|
=== 3.2 Is the implementation cross-platform? How about mobile support? ===
|
|
|
|
The Go implementation has been successfully deployed on Linux, Windows, Darwin and Android (ARM), and is believed to be portable to any platform that the Go compiler and runtime can target.
|
|
|
|
|
|
|
|
For certain rare low resource embedded systems it is tentatively planned that a C++ implementation be provided as part of the obfsclient package.
|
|
|
|
|
|
|
|
=== 3.3 What is the implementation's build process like, how easy is it to deploy, and what is deployment scaling like? ===
|
|
|
|
obfs4proxy is capable of being built deterministically and is integrated into the Tor Browser's build process. Pre-built binary packages are also available for several Linux distributions, and the deployment process is documented, though it could be publicized more.
|
|
|
|
|
|
|
|
=== 3.4 How is the implementation's code from a security and maintainability perspective? ===
|
|
|
|
The obfs4proxy package is written in Go which is a memory-safe language. Test coverage while, not complete encompasses most of the non-trivial components.
|
|
|
|
|
|
|
|
Third parties that have examined the code have said that it is possible to follow, and all non-trivial sections are commented.
|
|
|
|
|
|
|
|
=== 3.5 How well-instrumented is the implementation in terms of collecting usage / performance / etc metrics? ===
|
|
|
|
obfs4proxy fully supports the Extended ORPort mechanism and thus provides metrics information. |
|
|
|
\ No newline at end of file |
