|
|
|
[[TOC]]
|
|
|
|
|
|
|
|
= snowflake Transport Evaluation (Preliminary) =
|
|
|
|
|
|
|
|
The [https://gitweb.torproject.org/pluggable-transports/snowflake.git Snowflake] transport was developed by Serene H., intending to modernize the [https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/FlashproxyEvaluation flashproxy] concept with a more modern NAT traversal algorithm centered around [https://webrtc.org/ WebRTC].
|
|
|
|
|
|
|
|
Thus from a design standpoint, snowflake is extremely similar to flashproxy.
|
|
|
|
|
|
|
|
== 1. Review Coverage and Reviewability Evaluation ==
|
|
|
|
|
|
|
|
=== 1.1 Is the software published, and is it entirely free / open source software? ===
|
|
|
|
|
|
|
|
The snowflake implementation, website proxying CoffeeScript code, WebRTC pluggable transport, and the facilitator are all publicly available under FOSS style licenses.
|
|
|
|
|
|
|
|
=== 1.2 How well documented is the design? ===
|
|
|
|
|
|
|
|
As the transport is a work in progress, documentation is limited to a [https://trac.torproject.org/projects/tor/wiki/doc/Snowflake page on the Tor Project Trac wiki], and a handful of `README.md` files in the source repository, along with comments in the source code.
|
|
|
|
|
|
|
|
=== 1.3 How much existing review has been done? Is the project active? ===
|
|
|
|
|
|
|
|
An [https://lists.torproject.org/pipermail/tor-dev/2016-January/010310.html announcement e-mail] was sent to the tor-dev mailing list. There is no publicly documented extensive review of the major dependencies (the WebRTC implementation is that of Chromium).
|
|
|
|
|
|
|
|
The project is under active development.
|
|
|
|
|
|
|
|
=== 1.4 What is the design's deployment history? ===
|
|
|
|
|
|
|
|
As the transport is still experimental, there has been no large scale deployment at this point. David Fitfield has built [https://trac.torproject.org/projects/tor/ticket/19001 test bundles] of the Tor Browser with integrated snowflake support, but they have not been disseminated to a large user-base.
|
|
|
|
|
|
|
|
== 2 Design Evaluation ==
|
|
|
|
|
|
|
|
=== 2.1 How difficult or expensive will it be to block the design? ===
|
|
|
|
|
|
|
|
As designed, the transport theoretically is expensive to block, requiring a high collateral damage approach of disallowing WebRTC which is used for web browser based video and audio conferencing software.
|
|
|
|
|
|
|
|
As implemented, the transport is currently trivial to block, with the easiest method being "block Google" or "block clients that look like they originate from the Go runtime library's TLS implementation". A mixture of both should result in low collateral damage, and adversaries have been known to apply TLS implementation fingerprinting against other transports.
|
|
|
|
|
|
|
|
Alternative censorship approaches that are likely to be fruitful include packet size/timing based statistical attacks, and denying access to the pre-configured ICE (TURN/STUN) servers used in large scale deployments.
|
|
|
|
|
|
|
|
=== 2.2 What impact on anonymity does the design have, if any? ===
|
|
|
|
|
|
|
|
Similar to the original flashproxy, as the web browser instances used to relay user traffic are short lived and highly volatile, the client is exposing their use of the circumvention tool to a larger cross section of the internet than traditional single-hop proxy based transports.
|
|
|
|
|
|
|
|
A popular privacy measure advocated to certain classes of users (eg: those that use VPN systems) has been to disable WebRTC due to the potential privacy impact. While this is not a concern for Tor Browser users using
|
|
|
|
snowflake as a transport, there is a segment of people that view WebRTC as harmful to anonymity, and the volunteers that are contributing bandwidth are exposed to such risks.
|
|
|
|
|
|
|
|
=== 2.3 What is the design's overhead in terms of computational costs and bandwidth? ===
|
|
|
|
|
|
|
|
The snowflake protocol itself is low overhead, and WebRTC's DTLS/SCTP encrypted/reliable in-order delivery mode should have overheads comparable to TLS over TCP/IP.
|
|
|
|
|
|
|
|
=== 2.4 How resilient is the design to active probing? ===
|
|
|
|
|
|
|
|
The design should be free from the normal active probing hazards, as long as the rendezvous mechanism features some form of authentication. It is unknown as to if this is currently the case.
|
|
|
|
|
|
|
|
== 3 Implementation Evaluation ==
|
|
|
|
|
|
|
|
=== 3.1 Does the design use the Tor Project's Pluggable Transport Application Programming Interface already? ===
|
|
|
|
|
|
|
|
Yes, snowflake uses the PT API.
|
|
|
|
|
|
|
|
=== 3.2 Is the implementation cross-platform? How about mobile support? ===
|
|
|
|
The implementation is cross platform assuming it is supported by a modern version of Go and runs an operating system supported by Chromium's WebRTC implementation.
|
|
|
|
|
|
|
|
The main bottleneck to portability, including mobile support, is likely the actual WebRTC implementation's portability rather than the Go or intermediary proxy applications.
|
|
|
|
|
|
|
|
=== 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 [https://github.com/keroserene/go-webrtc/issues/29 not capable of being built deterministically], though the preliminary work has been done to integrate it into Tor Browser's build process.
|
|
|
|
|
|
|
|
Deployment scaling is primarily handled via having people include the proxy code on their websites (nb: The [https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/proxy/README.md instructions for embedding] currently 404). There has not been a drive to do so due to the early stage of development, and it is an open question to how many sites will volunteer, and how many site visitors allow and support WebRTC.
|
|
|
|
|
|
|
|
=== 3.4 How is the implementation's code from a security and maintainability perspective? ===
|
|
|
|
|
|
|
|
The implementation is mostly Go, except for the WebRTC implementation, written in C/C++, which is called from the Go application via the `cgo` FFI interface.
|
|
|
|
|
|
|
|
The largest attack surface is belived to be the non-Go components, that originate from Google's Chromium, which is conjectured to be well audited by Google's security team due to it's inclusion in Chrome. Validating and auditing the software independently is likely to be extremely difficult, and certain components such as DTLS implementations have historically been plagued with security vulnerabilities.
|
|
|
|
|
|
|
|
=== 3.5 How well-instrumented is the implementation in terms of collecting usage / performance / etc metrics? ===
|
|
|
|
|
|
|
|
snowflake does not currently use the Extended ORPort, and [https://trac.torproject.org/projects/tor/ticket/18628 requires code changes] if metrics information is desired. |
