On Sat, Mar 27, 2021 at 10:33:46AM -0400, Cecylia Bocovich wrote:
It looks like Azure is going to shutdown domain fronting: https://www.microsoft.com/security/blog/2021/03/26/securing-our-approach-to-...
There isn't a time frame listed in the article, and I haven't gotten any notifications through my Azure account yet.
One possible alternative is ESNI with Cloudflare, using the mainline meek code and its support for a headless (ESNI-supporting) Firefox. However, this will require a lot of Tor Browser work to swap meek implementations and re-wire the headless browser support files.
The meek source code (but not the obfs4proxy meek_lite now used in Tor Browser) supports using a headless Firefox for TLS camouflage. As a side benefit, if Firefox supports ESNI, then meek does as well. I used it successfully in 2018 with Cloudflare server ESNI and the changes are merged into the master branch, though I haven't looked at it much since then and it hasn't been tried in deployment. https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/meek/28...
It would be unfortunate, because the headless Firefox setup was hard to maintain, and for that reason the meek implementation was switched to obfs4proxy once obfs4proxy gained support for uTLS-based camouflage. Use uTLS for meek TLS camouflage in Tor Browser https://bugs.torproject.org/tpo/applications/tor-browser/29430 clean up the old meek http helper browser profiles https://bugs.torproject.org/tpo/applications/tor-launcher/31491 https://blog.torproject.org/new-release-tor-browser-90a6 https://blog.torproject.org/new-release-tor-browser-90 But restoring the browser-camouflage version of meek is something that could be done, in order to keep it working in the absence of Azure domain fronting support. Back then, I made a demonstration branch showing how to integrate the meek changes into Tor Browser: https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/meek/29... https://gitweb.torproject.org/user/dcf/tor-browser-build.git/log/?h=meek-web...
One problem with the headless Firefox model is that the TLS fingerprint of the ESR release used by Tor Browser would rapidly become uncommon (because most people don't run ESRs). See Section V of https://tlsfingerprint.io/static/frolov2019.pdf. But we currently have that problem anyway, as the version of uTLS we are using is two years old (Chrome 72, Firefox 65, and even the dev branch is 9 months old). https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/g... https://gitlab.com/yawning/utls/-/tree/v0.0.10-1
I've said "ESNI" and not "ECH" in this post because while Firefox 85 now has client support for ECH, there's no server support for it yet. And the ESR on which Tor Browser is based (currently Firefox 78) does not yet have ECH support. As far as I know, ESNI with Firefox ESR and Cloudflare works fine today. https://www.ghacks.net/2021/02/24/the-case-of-the-missing-esni-support-in-fi...