ScrambleSuit Transport Evaluation
The ScrambleSuit protocol was developed by Philipp Winter, Tobias Pulls, and Jergen Fuss as a response to DPI based censorship with the aim to counter increasingly sophisticated attacks against Tor and the obfs3 protocol. While unbroken, most if not all of the functionality is also present in the obfs4 protocol, and thus is considered deprecated and has been evaluated as a historical reference only.
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?
The ScrambleSuit protocol is implemented in multiple software packages, all under FOSS style licenses. The original implementation is the Python implementation in the obfsproxy suite, with additional client-only implementations in C++11 (obfsclient) and Go (obfs4proxy).
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 comprehensive specification. The documentation has been used by developers to write interoperable implementations.
1.3 How much existing review has been done? Is the project active?
As part of the deployment process, extensive review of the Python implementation was done. While the software packages that provide ScrambleSuit functionality are actively maintained and developed, the ScrambleSuit protocol is almost entirely superceded by the obfs4 protocol. Further improvents will be made in the form of newer protocol designs.
1.4 What is the design's deployment history?
ScrambleSuit was integrated into obfsproxy and a general call for bridge operators to upgrade sent to the "tor-relays" list on Febuary 10, 2014. It has been incorporated into the Tor Browser 4.0 series of releases since 4.0, released in October 2014.
Android availability started in Orbot in May 2014 as of Orbot v14 alpha via the obfsclient C++ implemention of the protocol.
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 ScrambleSuit 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 ScrambleSuit 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 amount of padding added per burst will always be limited to less than 1500 bytes as only burst lenght is considered when padding is added.
Each ScrambleSuit handshake will additionally add a one time data transfer of up to 1532 bytes in both directions.
The cryptographic CPU overhead varies depending on which handshake primitive is used. The first connection will require a relatively expensive 1536 bit DH key exchange, however subsequent connections can use a "ticket" saved clientside. Once a link is established, data is encrypted via CTR-AES-128, and MACed with HMAC-SHA256-128 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?
The ScrambleSuit 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 (API) already?
Yes, all of the currently actively supported ScrambleSuit implementations use the PT API.
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 ScrambleSuit client support is provided via obfsclient (C++11) and obfs4proxy (Go). Between the three codebases, ScrambleSuit 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?
Both obfsproxy and obfs4proxy are capable of being built deterministically and are currently integrated into the Tor Browser's build process. As obfsproxy is the legacy software package recommended to administrators for running Bridges, pre-built packages are widely available and the deployment process is well documented.
As the protocol is considered superceded by obfs4, few if any additional deployments are expected, rendering this moot.
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?
The Python implementation that is part of the obfsproxy suite is the only server implementation, and it fully supports the Extended ORPort mechanism and thus provides metrics information.