Changes between Version 31 and Version 32 of doc/meek


Ignore:
Timestamp:
Mar 18, 2014, 10:40:47 PM (6 years ago)
Author:
dcf
Comment:

Add a higher-level description and a handcrafted artisanal diagram.

Legend:

Unmodified
Added
Removed
Modified
  • doc/meek

    v31 v32  
    99== Quick start ==
    1010
     11To get a prebuilt complete bundle:
     12 * https://people.torproject.org/~dcf/pt-bundle/3.5.2.1-meek-1/
     13
     14To build from source:
    1115{{{
    1216git clone https://git.torproject.org/pluggable-transports/meek.git
     
    2024== Overview ==
    2125
    22 When meek-client receives a SOCKS request from the Tor client, it generates a random session id string. `meek-client` makes an HTTP POST to !https://meek-reflect.appspot.com/, which is a special web app set up for this transport. The request looks something like this:
     26meek sends traffic through a custom web app on [https://developers.google.com/appengine/ Google App Engine]. meek works in places where Google search ('''www.google.com''') is unblocked, even though App Engine itself ('''appspot.com''') may be blocked. The meek-client program builds a special HTTPS request and sends it to the Google frontend server--the server that dispatches requests to different Google services, like search, Google Drive, and App Engine. What's special about the HTTPS request is that from the outside it appears to be destined for '''www.google.com''', so it is allowed by the censor. But under the encryption layer, the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23 Host header] is actually for '''meek-reflect.appspot.com''', so the frontend server knows to forward the request to App Engine and the web app that we run. The web app in turn forwards the traffic to a Tor bridge, where the meek-server program decodes it and feeds it to Tor.
     27
     28[[Image(meek-diagram.jpg)]]
     29
     30Here's what's happening at a byte level. When meek-client receives a SOCKS request from the Tor client, it generates a random session id string. meek-client makes an HTTP POST to !https://meek-reflect.appspot.com/, which is a special web app set up for this transport. The request looks something like this:
    2331{{{
    2432GET / HTTP/1.1
     
    3038<data payload follows>
    3139}}}
    32 Normally a censor would be able to search for the string `meek-reflect.appspot.com` and block the connection. But the HTTP request is inside HTTPS, and the IP address and [https://en.wikipedia.org/wiki/Server_Name_Indication SNI] of the HTTPS connection are those of www.google.com.
     40Normally a censor would be able to search for the string `meek-reflect.appspot.com` and block the connection. But the HTTP request is encrypted inside HTTPS, and the IP address and [https://en.wikipedia.org/wiki/Server_Name_Indication SNI] of the HTTPS connection are those of www.google.com. The censor sees a DNS request, but it is for www.google.com, not appspot.com.
    3341
    3442The web app running at meek-reflect.appspot.com is very simple: it just copies the POST request it receives, and makes an identical request to a meek-server running on a Tor relay. There is a meek-server instance running at !http://meek.bamsoftware.com:7002/. The request from App Engine to meek-server looks like: