FTE Transport Evaluation
The Format Transforming Encryption transport was developed by Kevin P. Dyer et al and is currently in production use. It utilizes Format Transforming Encryption, a cryptographic primitive family that transforms plaintext into cyphertext that fits a predefined format, usually that of another protocol.
It is the only current "mimicry" based Pluggable Transport in production use, all other transports either transform the traffic to look like random noise (Eg: the obfs family), or include full implementations of other protocols (Eg: meek).
1. Review Coverage and Reviewability Evaluation
1.1 Is the software published, and is it entirely free / open source software?
The library that implements the FTE cryptographic primitive and the fteproxy pluggable transport which uses the library to obfuscate traffic are all publicly available under FOSS style licenses.
1.2 How well documented is the design?
The design is well documented, with the primary documentation in the form of a research paper. The code also features extensive literate programing documentation, with the output available on the website.
1.3 How much existing review has been done? Is the project active?
There has been moderate amount of review done, as the primary developer engaged with the Tor Project over the course of the transport's development. The project appears to be maintained but no substantial new features have been added recently.
1.4 What is the design's deployment history?
Experimental bundles containing the software were first made available in December 2013 in a post to the "tor-dev" mailing list. The full integration process till it was merged into the Tor Browser 3.6.x series is documented as a trac ticket (#10362 (moved)).
It is not currently deployed on mobile platforms. As the code includes substantial amounts of Python, packaging would be difficult, and it may be necessary to port the implementation to a more mobile friendly language if this is desired.
2 Design Evaluation
2.1 How difficult or expensive will it be to block the design?
The difficulty in blocking the design via DPI is primarily centered around the quality of the output formats (regexes) provided to the FTE primitive. If the transform leaves obvious distinguishers, the protocol will fall to "Dead Parrot" style attacks.
The current regexes have several identifing features that could be used by a DPI system to detect and censor FTE.
| Protocol | Distinguisher |
|---|---|
| HTTP | The FTE traffic's request claims to speak HTTP/1.1 but does not send a Host header. Such requests are required by the specification to trigger an immediate 400 Bad Request error response. |
| SSH | The FTE traffic only attempts to mimic the banner exchange. Subsequent traffic is not recognizably SSH. |
It is the reviewer's opinion that both listed distinguishers make the current shipping regex set trivially blockable assuming rudimentary DPI capabilities, though the author of the software disagrees and believes that using such distinguishers will cause too much collateral damage.
The protocol does not attempt to significantly alter traffic volume or timing related information, and thus should be vulnerable to statistical attacks targeting properties of the obfuscated protocol.
2.2 What impact on anonymity does the design have, if any?
As the FTE 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?
The implementation of the code as of the research paper's publication had competitive performance and goodput to a ssh tunnel. Since then more of the code has been pushed into Python, but the penalty incurred is not significant.
2.4 How resilient is the design to active probing?
As deployed FTE is vulnerable to active probing as a static key is used, so there is nothing preventing adversaries from attempting to connect, under the assumption that the destination is speaking FTE. The software includes provisions for specifying a key per bridge, however this configuration is not currently used in production.
A second active probing vector exists, which attempts to distinguish FTE from the mimicked protocol (Active "Dead Parrot"). For example, fteproxy will terminate the connection on receiving a well formed HTTP request, when a normal webs erver will return a response (#12677).
3 Implementation Evaluation
3.1 Does the design use the Tor Project's Pluggable Transport Application Programming Interface already?
Yes, fteproxy uses the PT API.
3.2 Is the implementation cross-platform? How about mobile support?
fteproxy is written in Python and is extremely portable assuming a Python interpreter and the required dependencies are available. It is not currently supported at all in mobile environments as a non-trivial amount of work is required to get a Python runtime.
The libfte dependency uses C++ for the critical path components (built as a python module), but the code is written in a portable manner.
3.3 What is the implementation's build process like, how easy is it to deploy, and what is deployment scaling like?
The implementation is capable of being built deterministically and is currently integrated into Tor Browser's build process. Packages are available for common operating systems for the purpose of Bridge deployment, and the deployment process is well documented.
3.4 How is the implementation's code from a security and maintainability perspective?
The implementation is written in a mixture of Python and C++. The Python components are memory safe, and tests exist for both the underlying library and the proxy program. Additionally, fteproxy leverages obfsproxy as a dependency, and benefits from code reuse. All code is well commented, and should be easy to maintain as needed.
3.5 How well-instrumented is the implementation in terms of collecting usage / performance / etc metrics?
fteproxy fully supports the Extended ORPort mechanism and thus provides metrics information.