Flashproxy Transport Evaluation

The Flashproxy transport was developed by David Fitfield et al and is currently in production use. It utilizes Internet user's web browsers as short lived proxies, under the assumption that having lots of short lived entry points to the Tor network will be difficult to censor.

While the design is deployed in theory, in practice, the requirement that clients must be able to accept incoming connections appears to be a significant barrier to actual use (< 10 daily users). There were plans of utilizing uPnP/NAT-PMP to automate NAT traversal, however concerns about code quality in libraries the original implementation used and the prevalence of pathologically broken router implementations of the traversal protocol have effectively halted efforts in this area.

This evaluation will cover the currently deployed WebSocket based implementation. Future incarnations of the transport based around WebRTC will be discussed separately, should they appear.

1. Review Coverage and Reviewability Evaluation

1.1 Is the software published, and is it entirely free / open source software?

The flashproxy implementation, website proxying JavaScript code, WebSocket pluggable transport, and the facilitator are all publicly available under FOSS style licenses.

1.2 How well documented is the design?

The design is well documented and includes a specification, and the website has additional resources for understanding the design.

1.3 How much existing review has been done? Is the project active?

There has been considerable review done, as multiple developers have touched on the code over it's lifespan. While the software packages associated with flashproxy are being maintained, it is unlikely that the current WebSocket implementation will be augmented. Further improvements are likely to to be made in the form of a newer WebRTC based implementation.

1.4 What is the design's deployment history?

Experimental bundles containing the software were first made available in January 2013 in a post to the "tor-dev" mailing list and have been part of the various pluggable transport aware Tor Browser bundles ever since.

It is not currently deployed on mobile, and the proliferation of carrier grade NAT devices in Telco networks makes it unlikely to be effective, even if deployed.

2 Design Evaluation

2.1 How difficult or expensive will it be to block the design?

As the WebSocket connections are plaintext and non-encrypted, it is trivial to block via DPI if it was actively searched for (There is a form of obfuscation applied to one direction as part of the WebSocket protocol ("masking"), however it is trivial to undo), by looking for WebSocket connections carrying the Tor protocol as the payload.

It is possible for the censor to block access to the facilitators that handle informing the browser-based intermediaries about new clients. The current flashproxy facilitators are hosted on Google's infrastructure, and use SMTP+STARTTLS and/or domain fronted HTTPS as the registration protocols. Either "blocking Google" or DPI against the TLS signature would block Tor Browser's flashproxy instance.

A third method to block flashproxy would be to disallow incoming connections to clients in a censored network. Due to design limitations imposed by being browser based and using WebSocket, the browser that is handling relaying data for the client opens the TCP connection. While this may seem like unacceptably high collateral damage, it is worth noting that such environments are already rather common, especially due to the proliferation of carrier-grade NAT devices in the mobile space.

2.2 What impact on anonymity does the design have, if any?

There are two negative impacts on anonymity due to the protocol's design.

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.

The client are also exposed to active adversaries probing for use of this transport, by virtue of listening for incoming connections on a TCP port.

2.3 What is the design's overhead in terms of computational costs and bandwidth?

The flashproxy protocol has minimal overhead, as the WebSocket protocol is neither complex nor encrypted. One direction of the flow has "masking" applied, which entails a single xor pass over the payload, however the computational overhead is negligible.

2.4 How resilient is the design to active probing?

The design by nature is immune to server side active probing attacks as the intermediary running in the various web browser instances are the ones that open the connection (the browser running the flashproxy applet connects to the client).

Clients are exposed to active probing attacks, as they have a publicly reachable port waiting for incoming WebSocket connections.

3 Implementation Evaluation

3.1 Does the design use the Tor Project's Pluggable Transport Application Programming Interface already?

Yes, the flashproxy client, and websocket-server both use the PT API.

3.2 Is the implementation cross-platform? How about mobile support?

The client implementation 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.

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.

Deployment scaling is primarily handled via having people include the JavaScript code on their websites. There has not been a major drive to do so in quite a while, primarily attributable to the NAT traversal requirements and the transport's low use.

3.4 How is the implementation's code from a security and maintainability perspective?

The client code written in Python, and the bridge side websocket-server backend written in Go are in memory-safe languages. The flashproxy client has limited test coverage, while the websocket-server code appears to have none. 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?

The websocket-server software supports the Extended ORPort mechanism and thus provides metrics information. However as the users do not connect directly to the host running websocket-server and instead travel through an intermediary, certain information such as the client location is currently unavailable.

Last modified 2 years ago Last modified on Oct 26, 2015, 6:55:46 PM