|
|
[[TOC]]
|
|
|
|
|
|
= obfs3 Transport Evaluation =
|
|
|
|
|
|
# obfs3 Transport Evaluation
|
|
|
The obfs3 protocol was developed and deployed by the Tor Project in response to the vulnerability of the obfs2 protocol to detection via DPI mechanisms and the subsequent censoring of the protocol. It is currently the front-line Pluggable Transport used by the most Tor users, although it is expected that obfs4 will eventually replace obfs3.
|
|
|
|
|
|
Multiple implementations of the protocol exist, however this evaluation will primarily cover the Python implementation that is part of the obfsproxy suite, with references to the other implementations as needed.
|
|
|
|
|
|
== 1. Review Coverage and Reviewability Evaluation ==
|
|
|
=== 1.1 Is the software published, and is it entirely free / open source software? ===
|
|
|
## 1. Review Coverage and Reviewability Evaluation
|
|
|
### 1.1 Is the software published, and is it entirely free / open source software?
|
|
|
The obfs3 protocol is implemented in multiple software packages, all under FOSS style licenses. The original implementation is the Python implementation in the obfsproxy suite, with a C++11 client only implementation in obfsclient, a the Go implementation in the obfs4proxy suite.
|
|
|
|
|
|
As it is a relatively simple protocol, there are no special considerations regarding distribution.
|
|
|
|
|
|
=== 1.2 How well documented is the design? ===
|
|
|
The design is well documented and includes a [https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/doc/obfs3/obfs3-protocol-spec.txt comprehensive specification] and [https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/doc/obfs3/obfs3-threat-model.txt threat model]. The documentation has been used by developers to write interoperable implementations.
|
|
|
### 1.2 How well documented is the design?
|
|
|
The design is well documented and includes a [comprehensive specification](https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/doc/obfs3/obfs3-protocol-spec.txt) and [threat model](https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/doc/obfs3/obfs3-threat-model.txt). The documentation has been used by developers to write interoperable implementations.
|
|
|
|
|
|
=== 1.3 How much existing review has been done? Is the project active? ===
|
|
|
### 1.3 How much existing review has been done? Is the project active?
|
|
|
As the current front-line Pluggable Transport, it has received a fair amount of attention and review, and has been used as the basis for the development of subsequent Pluggable Transports. While the software packages that provide obfs3 functionality are actively maintained and developed, the obfs3 protocol itself is unexpected to change and is inactive. Further improvements will be made in the form of newer protocol designs.
|
|
|
|
|
|
=== 1.4 What is the design's deployment history? ===
|
|
|
### 1.4 What is the design's deployment history?
|
|
|
The protocol was developed in early 2013, with a general call for bridge operators to run bridges sent to the "tor-relays" mailing list on April 16th, 2013. It has since then become the main frontline Pluggable Transport used and supported by the Tor Project, and is currently still in wide use today.
|
|
|
|
|
|
Android availability in Orbot started in May 2014 as of Orbot v14 alpha via the obfsclient C++ implementation of the protocol.
|
|
|
|
|
|
https://metrics.torproject.org/userstats-bridge-transport.html?graph=userstats-bridge-transport&start=2013-01-01&end=2015-04-17&transport=obfs3
|
|
|
|
|
|
== 2 Design Evaluation ==
|
|
|
=== 2.1 How difficult or expensive will it be to block the design? ===
|
|
|
## 2 Design Evaluation
|
|
|
### 2.1 How difficult or expensive will it be to block the design?
|
|
|
The design improves on the vulnerability to DPI based censorship present in the obfs2 protocol by using a proper cryptographic handshake. Due to this improvement, it is believed to be immune to trivial DPI techniques, though it would be vulnerable to censors that specifically look for high-entropy traffic, or those that are willing to use a protocol whitelist.
|
|
|
|
|
|
There is no attempt to obfuscate traffic volume or timing related information and it is believed that such statistical attacks will be able to identify protocols obfuscated within obfs3 flows with high accuracy.
|
|
|
|
|
|
Certain large adversaries are currently successfully censoring obfs3 flows via active probing attacks (See 2.4), however it is worth noting that mounting such attacks on a large scale is relatively resource intensive.
|
|
|
|
|
|
=== 2.2 What impact on anonymity does the design have, if any? ===
|
|
|
### 2.2 What impact on anonymity does the design have, if any?
|
|
|
As the obfs3 protocol focuses solely on circumvention, there is no anonymity impact, positive nor negative.
|
|
|
|
|
|
=== 2.3 What is the design's overhead in terms of computational costs and bandwidth? ===
|
|
|
### 2.3 What is the design's overhead in terms of computational costs and bandwidth?
|
|
|
The obfs3 protocol has a relatively low overhead, with the only added bandwidth costs being that of the handshake (a maximum of 8418 bytes). The CPU overhead is slightly more complicated as a relatively expensive cryptographic key exchange algorithm is used, involving 1536 bit modular exponentiation, however as each connection is expected to be relatively long-lived, the CPU overhead will be dominated by CTR-AES128 encryption/decryption on outgoing/incoming traffic which should be affordable by all clients and all but the most under-powered Bridges.
|
|
|
|
|
|
=== 2.4 How resilient is the design to active probing? ===
|
|
|
### 2.4 How resilient is the design to active probing?
|
|
|
The basic obfs3 protocol is completely vulnerable to active probing, as the client has zero requirements to prove that it knows that the server accepts obfs3 connections. This approach is currently used by the Chinese state firewall to censor obfs3 Bridges, and anecdotal evidence suggests that the delayed probing results in connections to previously unknown obfs3 bridges being terminated after approximately 10 minutes.
|
|
|
|
|
|
== 3 Implementation Evaluation ==
|
|
|
=== 3.1 Does the design use the Tor Project's Pluggable Transport Application Programming Interface (API) already? ===
|
|
|
## 3 Implementation Evaluation
|
|
|
### 3.1 Does the design use the Tor Project's Pluggable Transport Application Programming Interface (API) already?
|
|
|
Yes, all of the currently actively supported obfs3 implementations use the PT API.
|
|
|
|
|
|
=== 3.2 Is the implementation cross-platform? How about mobile support? ===
|
|
|
### 3.2 Is the implementation cross-platform? How about mobile support?
|
|
|
The Python obfsproxy implementation is extremely portable, assuming a Python interpreter and the required dependencies are available. For mobile environments, Python has proved to be difficult, and thus obfs3 support is provided via obfsclient (C++11) and obfs4proxy (Go). Between the three codebases, obfs3 runs on a large assortment of hardware and operating systems.
|
|
|
|
|
|
=== 3.3 What is the implementation's build process like, how easy is it to deploy, and what is deployment scaling like? ===
|
|
|
### 3.3 What is the implementation's build process like, how easy is it to deploy, and what is deployment scaling like?
|
|
|
Both obfsproxy and obfs4proxy are capable of being built deterministically and are currently integrated into the Tor Browser's build process. As both of those suites are part of the standard array of software recommended to administrators for running Bridges, pre-built binary packages are widely available and the deployment process is well documented.
|
|
|
|
|
|
=== 3.4 How is the implementation's code from a security and maintainability perspective? ===
|
|
|
### 3.4 How is the implementation's code from a security and maintainability perspective?
|
|
|
This varies by implementation. The Python and Go versions have the benefit of being written in memory-safe languages, while the C++11 version does not. All three implementations have test coverage for the surrounding components, however only the Python obfsproxy code ha integration tests. The code implementing the non-trivial components of the protocol (specifically the UniformDH key exchange) tends to have additional test coverage as Known Answer Tests are available.
|
|
|
|
|
|
=== 3.5 How well-instrumented is the implementation in terms of collecting usage / performance / etc metrics? ===
|
|
|
### 3.5 How well-instrumented is the implementation in terms of collecting usage / performance / etc metrics?
|
|
|
Both the python obfsproxy and Go obfs4proxy server implementations of obfs3 fully support the Extended ORPort mechanism and thus provide metrics information. |
|
|
\ No newline at end of file |