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.
Cecylia
=(
Was that the last major provider that supported it?
On Sat, Mar 27, 2021, 10:33 AM Cecylia Bocovich cohosh@torproject.org 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.
Cecylia _______________________________________________ anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
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...
On Mon, Mar 29, 2021 at 01:19:33PM -0600, David Fifield wrote:
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.
One huge advantage of routing via Cloudflare is that it's free (gratis), right? That is, we could move the (currently hugely rate limited and thus very slow) meek-azure traffic over to this future meek-cloudflare service, and open up the rate limits a lot more?
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).
How far is the current utls from being able to do ESNI? That approach might be more work in the short term, but provide the "easier to maintain" feature in the long term?
I hear ESNI won't work so well in China, but there are plenty of other censored situations where it would be really useful to offer users a higher-bandwidth domain-fronted option.
--Roger
On Thu, Apr 01, 2021 at 11:15:47PM -0400, Roger Dingledine wrote:
On Mon, Mar 29, 2021 at 01:19:33PM -0600, David Fifield wrote:
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.
One huge advantage of routing via Cloudflare is that it's free (gratis), right? That is, we could move the (currently hugely rate limited and thus very slow) meek-azure traffic over to this future meek-cloudflare service, and open up the rate limits a lot more?
I think that's right. I don't know how the paid features break down, but you can use the CDN free of charge.
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).
How far is the current utls from being able to do ESNI? That approach might be more work in the short term, but provide the "easier to maintain" feature in the long term?
I don't think it's close. uTLS is patches on top of the Go standard library tls/crypto, and the Go maintainers don't have plans to support it until after browsers do. https://github.com/golang/go/issues/9671#issuecomment-439561672 ESNI itself is a dead end now; any development work now would go toward ECH instead.
I hear ESNI won't work so well in China, but there are plenty of other censored situations where it would be really useful to offer users a higher-bandwidth domain-fronted option.
There's a secondary risk, though. ESNI/ECH are not deployed by default in any clients. If we're the only ones using it, then far from being covert, ESNI/ECH becomes a signal for traffic censors want to block. Worst case, if we act incautiously, is that we get a protocol blocked before it catches on and undo a lot of hard work. With ESNI it's maybe not so bad (compared to ECH), as it's on the way out anyway.
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.
Another option is to implement this existing idea for rendezvous using DNS (DNS over HTTPS or DNS over TLS). https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfla...
It's not reflected in the ticket, but since then there is https://www.bamsoftware.com/software/dnstt/ which implements an encrypted, reliable channel over DNS queries and responses. Unfortunately some sort of reliability channel is necessary, as Snowflake client messages are longer than the ~100 bytes you can fit into a single DNS query. But it's not really any different than the Turbo Tunnel / KCP / smux that Snowflake is already using.
A downside is that encrypted DNS servers do not have as much blocking resistance as we had with domain fronting.
On 2021-03-27 10:33 a.m., 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.
Just a brief update on our side:
We've set up domain fronting with Fastly for Snowflake and Moat (using an existing account and credits we have for Tor Browser updates). We still have no plans to move meek over to another provider. Right now we're only planning to use this provider for exchanging bridge and proxy information (by allowing connections to the Snowflake broker and BridgeDB), and not for actual user traffic.
These changes will be merged into the next Tor Browser alpha soon, and we're discussing when to do a stable release. You can find the various associated tickets here:
- https://gitlab.torproject.org/tpo/applications/tor-launcher/-/issues/40007 - https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40... - https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40...
On Mon, Apr 05, 2021 at 03:40:59PM -0400, Cecylia wrote:
On 2021-03-27 10:33 a.m., 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.
Just a brief update on our side:
We've set up domain fronting with Fastly for Snowflake and Moat (using an existing account and credits we have for Tor Browser updates). We still have no plans to move meek over to another provider.
Thanks for being on top of this.
It would be good to forewarn users about the removal of meek. Is the comms team planning some kind of announcement?
On 4/5/21 9:39 PM, David Fifield wrote:
On Mon, Apr 05, 2021 at 03:40:59PM -0400, Cecylia wrote:
On 2021-03-27 10:33 a.m., 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.
Just a brief update on our side:
We've set up domain fronting with Fastly for Snowflake and Moat (using an existing account and credits we have for Tor Browser updates). We still have no plans to move meek over to another provider.
Thanks for being on top of this.
It would be good to forewarn users about the removal of meek. Is the comms team planning some kind of announcement?
Not sure but sending this thread to comms@ for them to have an eye on this.
anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
Thank you for sharing this. While the blog mentions Microsoft’s stance against domain fronting, it doesn't specify a timeline for the shutdown. It's worth monitoring your Azure notifications and announcements closely for updates. In the meantime, planning alternative solutions is advisable. https://therutificador.cl/rut-por-nombre/
anti-censorship-team@lists.torproject.org
-
Cecylia -
Cecylia Bocovich -
David Fifield -
Gaba -
Roger Dingledine -
therutificadorchile＠gmail.com -
Tom Ritter