Here's Matt's email on how moat works.
----- Forwarded message from Matthew Finkel sysrqb@torproject.org -----
[...]
"meek-server" is (basically) the mirror-image of "meek", except it's on the server-side instead of the client-side - it decapsulates the request which was encapsulated by the meek client. Usually, this is the "pluggable transport bridge" running on some cloud VM (Google App Engine, MS Azure, AWS, etc.). It receives the normal incoming "transformed" traffic from the client, decodes it, and passes it onto the tor bridge. With moat, this configuration is tweaked a bit. Instead of running the meek-server and a tor bridge on a cloud vm, the meek server is running on the bridgedb server (and the incoming traffic is passed onto bridgedb rather than being passed onto the tor bridge). This means the cloud service is only being used for its CDN capability (and purely domain fronting), acting as a pass-through: from the client to the CDN to bridges.torproject.org, verses how meek is usually run where the tor bridge is running in the cloud, as well. With meek, there is an actual reflector VM where meek-server and the tor bridge usually run. With moat, the "reflector" is in name only, it simply associates the incoming connection with the CDN client configuration, so the CDN knows which client configuration it should look at for handling the traffic.
Diagram of standard meek setup (which you probably already saw): https://trac.torproject.org/projects/tor/wiki/doc/meek#Overview
The description of how this works is in this ticket: https://trac.torproject.org/projects/tor/ticket/16650
The general flow is: - Tor Browser's Tor Launcher creates HTTP request for https://bridges.torproject.org/moat - Tor Launcher starts a meek-client as a local proxy and pass in this request - The meek-client establishes a TLS connection with CDN (client -> https://ajax.aspnetcdn.com) - The meek-client then sends HTTP requests within this TLS tunnel where the host header is https://onion.azureedge.net and the body of the encapsulated request is the TCP stream for the HTTP request from Tor Launcher - This allows for creating the end-to-end TLS connection between Tor Launcher and BridgeDB - All traffic sent to the CDN is then proxied to https://bridges.torproject.org/meek (client -> CDN -> https://bridges.torproject.org/meek) - On the bridgedb server, there is an Apache webserver running that looks for incoming requests for /meek and redirects them to the meek-server running locally (client -> CDN -> https://bridges.torproject.org/meek -> meek-server) - The meek-server takes the incoming connections and decapsulates the enclosed request and passes it back to the Apache webserver (where the enclosed request is the TLS connection for https://bridges.torproject.org/moat) (client -> CDN -> https://bridges.torproject.org/meek -> meek-server (local) -> https://bridges.torproject.org/moat) - The Apache webserver then passes this request to BridgeDB for handling. Responses go in the reverse order. (client -> CDN -> https://bridges.torproject.org/meek -> meek-server (local) -> https://bridges.torproject.org/moat -> bridgedb)
The result of this is the client establishes the usual TLS connection with the CDN (therefore using it as the domain-front), then all traffic is passed from the CDN onto bridges.torproject.org. Within that pass-through connection, moat establishes another end-to-end TLS connection with bridges.torproject.org.
The ticket (29096) suggests changing how meek-server is currently run. Right now, it's simply a (hacky) shell script. My understanding of this is using ptadapter would simply be replacing the shell script with a maintained python program, but it'd provide essentially the same thing. https://gitweb.torproject.org/project/bridges/bridgedb-admin.git/tree/bin/ru...
The meek-server configuration is described here (if you're configuring it as a tor bridge). https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure
[...]
----- End forwarded message -----