meek Transport Evaluation
The meek protocol was developed by David Fitfield and is currently in production use. It is one of the better options for users in certain environments and the technology has been adapted by other systems including Psiphon.
NB: The economic cost side is mostly out of scope of this evaluation.
1. Review Coverage and Reviewability Evaluation
1.1 Is the software published, and is it entirely free / open source software?
The meek protocol is implemented in a FOSS package in the Go language. Additionally there are supplemental FOSS reflector (backend) packages in a variety of different languages.
1.2 How well documented is the design?
The design has extensive documentation on the Tor Project's wiki, including an overview on how it works and how to configure meek server instances on the various cloud computing and CDN providers.
A detailed wire protocol specification appears to be missing, however the protocol is simple enough that it is immediately apparent from the source code.
1.3 How much existing review has been done? Is the project active?
As a project that has garnered considerable external interest it has had significant amounts of external review and is under continual active development by the original author.
1.4 What is the design's deployment history?
The protocol and software was announced in January 2014. There were no public calls for bridge operators as the deployment model is different in that it uses centralized backends hosted on third party commercial infrastructure. It has been incorporated into the Tor Browser as of 4.0a1, released in August 2014.
Android availablity in Orbot started as of Orbot v15 alpha 3.
2 Design Evaluation
2.1 How difficult or expensive will it be to block the design?
The meek protocol is unique in that, from a technical standpoint, blocking meek is trivial as the entry points that the user connects to are public and known to the adversaries. Instead of keeping the entry points secret, meek relies on having collateral damage that is considered "unacceptable" to most censors as each entry point aims to be one site among many, and most adversaries are unlikely to be willing to block thousands of sites as collateral damage.
Despite this, there are several attacks that a resourceful adversary can mount to attempt to block meek with minimal collateral damage. If meek is run without a browser based helper to normalize the TLS signature, meek requests will stand out from legitimate requests, and would be candidates for selective DPI based blocking.
The meek protocol is also likely vulnerable to statistical attacks based on request/response timing and traffic volume as no attempts are made to mask traffic volume, and the client driven poll timing is rather distinctive.
The meek protocol is also uniquely vulnerable in that political and economic pressure can be applied to the centralized third parties that host the meek reflector instances by sufficiently large adversaries.
2.2 What impact on anonymity does the design have, if any?
The meek protocol presents a unique anonymity hazard in that it is possible for the cloud computing or CDN provider to deanonymize users visiting sites hosted on their infrastructure, despite the users traffic passing through the Tor network.
This is because under those conditions, the third party gets to observe the user's traffic to the Bridge and the application traffic to and from the exit, allowing them to mount end-to-end correlation attacks.
2.3 What is the design's overhead in terms of computational costs and bandwidth?
As the meek protocol is a lightweight wrapper around HTTPS requests, it has considerable bandwidth overhead as each time data needs to be transferred, a new HTTP request must be made and encapsulated in TLS records. Additionally, the client must poll the server for return traffic, resulting in extra network overhead.
In certain deployment conditions, the TCP/IP and TLS connections will get terminated by the third party intermediary hosting the reflector resulting in extra CPU and network overhead to re-establish a communication channel.
2.4 How resilient is the design to active probing?
The location of the meek server entry points that the users connect to are not secret, instead relying on the collateral damage associated with censoring the entry points. Thus while active probing to see if the entry point is still running is extremely trivial, it does not gain adversaries anything.
3 Implementation Evaluation
3.1 Does the design use the Tor Project's Pluggable Transport Application Programming Interface already?
Yes, meek-client and meek-server uses the PT API.
3.2 Is the implementation cross-platform? How about mobile support?
The core meek-client code is cross-platform and has been successfully deployed on Linux, Windows, Darwin and Android, and is believed to be portable to any platform that the Go compiler and runtime can target.
However for maximum effectiveness, meek-client should use a platform specific helper to normalize it's TLS handshake signature to that of a common browser. Currently only Firefox and Chrome are capable of being used as the helper, and further development effort is needed in this area particularly on the mobile platforms.
3.3 What is the implementation's build process like, how easy is it to deploy, and what is deployment scaling like?
meek is capable of being build deterministically and is integrated into the Tor Browser's build process. The server deployment model is different and while extremely well documented is not something that needs lots of volunteers unlike the continual need for Bridges for the other PT protocols.
3.4 How is the implementation's code from a security and maintainability perspective?
The core meek client and server software is written in Go which is a memory-safe language. Partial test coverage exists, and the code is well written and commented.
3.5 How well-instrumented is the implementation in terms of collecting usage / performance / etc metrics?
The meek-server software supports the Extended ORPort mechanism and thus provides metrics information. However as the users do not connect directly to the host running meek-server and instead travel through an intermediary, certain information such as the client location is currently unavailable.