Roger asked me what it would take to run a meek bridge on an existing hard-to-block HTTPS web site that wants to help, Wikipedia for example. The difference with our existing deployments on CDNs is that we don't expect any special cooperation by the CDN, whereas an interested site could make minor changes to make running a bridge easier.

It's actually not hard to do. For example, this is the meek-server port on the Tor bridge behind meek-azure: https://meek.bamsoftware.com/ That URL is actually totally usable directly in a bridge line: Bridge meek 0.0.2.0:3 url=https://meek.bamsoftware.com/ The reason we don't just distribute the above bridge line, (and why we involve a CDN at all), is because meek.bamsoftware.com is trivial to block by domain or IP--it is used for nothing but circumvention, so the collateral damage of blocking it is zero. That's why we have to do domain fronting and put a domain with some unblockability in front of it.

With an important web site, the unblockability comes for free, so you don't need domain fronting. Wikipedia could set up their own Tor bridge running meek-server, then set up a special URL path to reverse-proxy to the bridge. A bridge line might look like this: Bridge meek 0.0.2.0:4 url=https://en.wikipedia.org/magic-meek-path/ They would configure their web server to forward every request for the path /magic-meek-path to their Tor bridge running meek-server, and that's it.

You could do the same thing with a vhost rather than special path. The domain name doesn't even have to exist--its only purpose is to tag the requests that should get forwarded to meek-server. The bridge line would be like this: Bridge meek 0.0.2.0:4 url=https://magic.meek.bogus/ front=en.wikipedia.org They would set up the vhost magic.meek.bogus to forward to a meek-server as before. Here we are technically using domain fronting, but not to gain unblockability, merely to tag meek requests. (The requests arrive at the server for en.wikipedia.org, but they have a Host header of magic.meek.bogus.)

This is how to run meek-server: https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtorunameek-serverb... And this is an example of doing vhost forwarding on Nginx: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/nginx/READM... https://gitweb.torproject.org/pluggable-transports/meek.git/tree/nginx/nginx...

An even lighter-weight alternative that doesn't require running meek-server is to host one of the "reflector" apps. For example, they can host this file: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/php/index.p... at a path like /meek/index.php. Then the bridge line will be Bridge meek 0.0.2.0:4 url=https://en.wikipedia.org/meek/index.php All the PHP file does is forward to a meek-server running elsewhere. This way is less efficient than running your own meek-server, but it's the first thing I would try for testing. We have reflector apps for PHP and Python WSGI: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/php https://gitweb.torproject.org/pluggable-transports/meek.git/tree/wsgi

In summary, it's not hard to do. A quick test with index.php is less than a day of work. Setting up meek-server on your own bridge is more involved, but not more than other pluggable transports.

David Fifield