Deprecation of Azure CDN from Edgio (azureedge.net), replaced by Azure Front Door (azurefd.net), affects snowflake-broker.azureedge.net
I got an email on 2024-12-05 saying that that Azure CDN from Edgio/Verizon is going to shut down sooner than expected. The shutdown date was supposed to be 2025-11-04, now it is 2024-01-15 (about one month from now).
This affects (at least) snowflake-broker.azureedge.net, which was first set up and is still on Azure CDN with Edgio. I think that snowflake-broker.azureedge.net has not been used by this team since 2021 and https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_req.... But it is still getting some use from somewhere, as evidenced by the nonzero monthly bills: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-cos... Whatever is out there that is still using snowflake-broker.azureedge.net will likely stop working after 2025-01-15.
Date: 5 Dec 2024 17:03:50 +0000 From: Microsoft Azure azure-noreply@microsoft.com Subject: Urgent action required: Migrate workloads on Azure CDN from Edgio (formerly Verizon) before 15 January 2025
Migrate to Azure Front Door or other CDN services as soon as possible to avoid service disruptions.
Migrate workloads on Azure CDN from Edgio (formerly Verizon) before 15 January 2025.
You're receiving this notice because you're currently using Azure CDN Standard/Premium from Edgio.
All Azure CDN from Edgio customers must migrate their workloads to Azure Front Door or other CDN services before 15 January 2025 as Edgio has advised their platform is currently scheduled to be shut down by that date. Migrate as soon as possible to avoid an imminent service shut-down.
On 31 October 2024, we sent you a notice advising that Azure CDN Standard/Premium from Edgio (formerly Verizon) will be retired on 4 November 2025, and that customers of this service must migrate their workload(s) to a comparable service before this date to avoid service interruptions. In that email we also advised given that Edgio filed for Chapter 11 Bankruptcy on 9 September 2024, Microsoft cannot guarantee that Edgio will continue to support this service through 4 November 2025 as previously stated.
Online references about Azure CDN with Edgio retirement: https://learn.microsoft.com/en-us/azure/cdn/edgio-retirement-faq https://azure.microsoft.com/updates?id=467688
I did try setting up a Front Door CDN profile (which is the recommended replacement for Edgio), following the migration instructions: https://learn.microsoft.com/en-us/azure/frontdoor/migrate-cdn-to-front-door I got the hostname: snowflake-broker-hadmaqbnc4dmcffs.z03.azurefd.net It works as an alias for the broker: curl -i https://snowflake-broker-hadmaqbnc4dmcffs.z03.azurefd.net/debug However, it apparently does not work with domain fronting, so is likely not actually useful. Front Door not working with domain fronting is consistent with prior announcements by Azure: https://github.com/net4people/bbs/issues/67
meek.azureedge.net is also still advertised:
``` % curl https://bridges.torproject.org/moat/circumvention/builtin {"meek-azure":["meek_lite 192.0.2.18:80 BE776A53492E1E044A26F17306E1BC46A55A1625 url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com"],"obfs4":[...],"snowflake":[...]} ```
My iOS apps still use this, since it never went away and people wanted it.
I guess, that is affected, too?
~tla
Am 11.12.24 um 07:09 schrieb David Fifield via anti-censorship-team:
I got an email on 2024-12-05 saying that that Azure CDN from Edgio/Verizon is going to shut down sooner than expected. The shutdown date was supposed to be 2025-11-04, now it is 2024-01-15 (about one month from now).
This affects (at least) snowflake-broker.azureedge.net, which was first set up and is still on Azure CDN with Edgio. I think that snowflake-broker.azureedge.net has not been used by this team since 2021 and https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_req.... But it is still getting some use from somewhere, as evidenced by the nonzero monthly bills: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-cos... Whatever is out there that is still using snowflake-broker.azureedge.net will likely stop working after 2025-01-15.
That seems likely, yes, unless I am misinterpreting the announcement from Azure. I get the impression that the exact date is uncertain, as it has to do with the bankruptcy of Edgio.
On Wed, Dec 11, 2024 at 11:13:42AM +0100, Benjamin Erhart via anti-censorship-team wrote:
meek.azureedge.net is also still advertised:
% curl https://bridges.torproject.org/moat/circumvention/builtin {"meek-azure":["meek_lite 192.0.2.18:80 BE776A53492E1E044A26F17306E1BC46A55A1625 url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com"],"obfs4":[...],"snowflake":[...]}My iOS apps still use this, since it never went away and people wanted it.
I guess, that is affected, too?
~tla
Am 11.12.24 um 07:09 schrieb David Fifield via anti-censorship-team:
I got an email on 2024-12-05 saying that that Azure CDN from Edgio/Verizon is going to shut down sooner than expected. The shutdown date was supposed to be 2025-11-04, now it is 2024-01-15 (about one month from now).
This affects (at least) snowflake-broker.azureedge.net, which was first set up and is still on Azure CDN with Edgio. I think that snowflake-broker.azureedge.net has not been used by this team since 2021 and https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_req.... But it is still getting some use from somewhere, as evidenced by the nonzero monthly bills: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-cos... Whatever is out there that is still using snowflake-broker.azureedge.net will likely stop working after 2025-01-15.
Who is responsible for https://bridges.torproject.org/moat/circumvention/ ?
Is there already a planned change to the `builtin` endpoint?
I guess I'll just leave it in Onion Browser, Orbot Apple and OnionShare for now, as long as there is no Meek alternative planned.
~tla
Am 11.12.24 um 16:50 schrieb David Fifield via anti-censorship-team:
That seems likely, yes, unless I am misinterpreting the announcement from Azure. I get the impression that the exact date is uncertain, as it has to do with the bankruptcy of Edgio.
On Wed, Dec 11, 2024 at 11:13:42AM +0100, Benjamin Erhart via anti-censorship-team wrote:
meek.azureedge.net is also still advertised:
% curl https://bridges.torproject.org/moat/circumvention/builtin {"meek-azure":["meek_lite 192.0.2.18:80 BE776A53492E1E044A26F17306E1BC46A55A1625 url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com"],"obfs4":[...],"snowflake":[...]}My iOS apps still use this, since it never went away and people wanted it.
I guess, that is affected, too?
~tla
Am 11.12.24 um 07:09 schrieb David Fifield via anti-censorship-team:
I got an email on 2024-12-05 saying that that Azure CDN from Edgio/Verizon is going to shut down sooner than expected. The shutdown date was supposed to be 2025-11-04, now it is 2024-01-15 (about one month from now).
This affects (at least) snowflake-broker.azureedge.net, which was first set up and is still on Azure CDN with Edgio. I think that snowflake-broker.azureedge.net has not been used by this team since 2021 and https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_req.... But it is still getting some use from somewhere, as evidenced by the nonzero monthly bills: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-cos... Whatever is out there that is still using snowflake-broker.azureedge.net will likely stop working after 2025-01-15.
anti-censorship-team mailing list -- anti-censorship-team@lists.torproject.org To unsubscribe send an email to anti-censorship-team-leave@lists.torproject.org
Who is responsible for https://bridges.torproject.org/moat/circumvention/ ?
Is there already a planned change to the `builtin` endpoint?
I guess I'll just leave it in Onion Browser, Orbot Apple and OnionShare for now, as long as there is no Meek alternative planned.
~tla
Am 11.12.24 um 16:50 schrieb David Fifield via anti-censorship-team:
That seems likely, yes, unless I am misinterpreting the announcement from Azure. I get the impression that the exact date is uncertain, as it has to do with the bankruptcy of Edgio.
On Wed, Dec 11, 2024 at 11:13:42AM +0100, Benjamin Erhart via anti-censorship-team wrote:
meek.azureedge.net is also still advertised:
% curl https://bridges.torproject.org/moat/circumvention/builtin {"meek-azure":["meek_lite 192.0.2.18:80 BE776A53492E1E044A26F17306E1BC46A55A1625 url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com"],"obfs4":[...],"snowflake":[...]}My iOS apps still use this, since it never went away and people wanted it.
I guess, that is affected, too?
~tla
I don't know the answers to those questions but someone else may.
On Fri, Dec 13, 2024 at 10:50:29AM +0100, Benjamin Erhart via anti-censorship-team wrote:
Who is responsible for https://bridges.torproject.org/moat/circumvention/ ?
Is there already a planned change to the `builtin` endpoint?
I guess I'll just leave it in Onion Browser, Orbot Apple and OnionShare for now, as long as there is no Meek alternative planned.
~tla
Am 11.12.24 um 16:50 schrieb David Fifield via anti-censorship-team:
That seems likely, yes, unless I am misinterpreting the announcement from Azure. I get the impression that the exact date is uncertain, as it has to do with the bankruptcy of Edgio.
On Wed, Dec 11, 2024 at 11:13:42AM +0100, Benjamin Erhart via anti-censorship-team wrote:
meek.azureedge.net is also still advertised:
% curl https://bridges.torproject.org/moat/circumvention/builtin {"meek-azure":["meek_lite 192.0.2.18:80 BE776A53492E1E044A26F17306E1BC46A55A1625 url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com"],"obfs4":[...],"snowflake":[...]}My iOS apps still use this, since it never went away and people wanted it.
I guess, that is affected, too?
~tla
Quoting David Fifield via anti-censorship-team (2024-12-13 18:35:05)
On Fri, Dec 13, 2024 at 10:50:29AM +0100, Benjamin Erhart via anti-censorship-team wrote:
Who is responsible for https://bridges.torproject.org/moat/circumvention/ ?
Anybody in the Team, but if you look for a concrete person I guess you can point to me.
Is there already a planned change to the `builtin` endpoint?
There is no plan already done. We've being planning to fase out meek for years[0] but kept it around as it was the last resort in some cases.
We could set up a meek bridge in another provider, but there are less and less providers that allow domain fronting and places that currently relay on meek like turkmenistan have other providers blocked. We might want to keep the existing meek-azure up and running until the last day for those cases.
There is an issue created to work on this: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/155
[0] https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/33
I guess I'll just leave it in Onion Browser, Orbot Apple and OnionShare for now, as long as there is no Meek alternative planned.
Yes, that makes sense.
The onionwrapper library (which is used by Briar and OnionShare Android) uses snowflake-broker.azureedge.net and meektm.azureedge.net for certain configurations (depending on the country and Android version, as some older Android devices can't verify Let's Encrypt certificates).
If we want to follow the upstream PT configuration, what's the best way to do that? The config files seem to move around various Tor repositories and at the moment I think we're basing our config on the expert bundle - but does that reflect what actually works/is used by Tor Browser?
Cheers, Michael
On 11/12/2024 06:09, David Fifield via anti-censorship-team wrote:
I got an email on 2024-12-05 saying that that Azure CDN from Edgio/Verizon is going to shut down sooner than expected. The shutdown date was supposed to be 2025-11-04, now it is 2024-01-15 (about one month from now).
This affects (at least) snowflake-broker.azureedge.net, which was first set up and is still on Azure CDN with Edgio. I think that snowflake-broker.azureedge.net has not been used by this team since 2021 and https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_req.... But it is still getting some use from somewhere, as evidenced by the nonzero monthly bills: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-cos... Whatever is out there that is still using snowflake-broker.azureedge.net will likely stop working after 2025-01-15.
Date: 5 Dec 2024 17:03:50 +0000 From: Microsoft Azure azure-noreply@microsoft.com Subject: Urgent action required: Migrate workloads on Azure CDN from Edgio (formerly Verizon) before 15 January 2025
Migrate to Azure Front Door or other CDN services as soon as possible to avoid service disruptions.
Migrate workloads on Azure CDN from Edgio (formerly Verizon) before 15 January 2025.
You're receiving this notice because you're currently using Azure CDN Standard/Premium from Edgio.
All Azure CDN from Edgio customers must migrate their workloads to Azure Front Door or other CDN services before 15 January 2025 as Edgio has advised their platform is currently scheduled to be shut down by that date. Migrate as soon as possible to avoid an imminent service shut-down.
On 31 October 2024, we sent you a notice advising that Azure CDN Standard/Premium from Edgio (formerly Verizon) will be retired on 4 November 2025, and that customers of this service must migrate their workload(s) to a comparable service before this date to avoid service interruptions. In that email we also advised given that Edgio filed for Chapter 11 Bankruptcy on 9 September 2024, Microsoft cannot guarantee that Edgio will continue to support this service through 4 November 2025 as previously stated.
Online references about Azure CDN with Edgio retirement: https://learn.microsoft.com/en-us/azure/cdn/edgio-retirement-faq https://azure.microsoft.com/updates?id=467688
I did try setting up a Front Door CDN profile (which is the recommended replacement for Edgio), following the migration instructions: https://learn.microsoft.com/en-us/azure/frontdoor/migrate-cdn-to-front-door I got the hostname: snowflake-broker-hadmaqbnc4dmcffs.z03.azurefd.net It works as an alias for the broker: curl -i https://snowflake-broker-hadmaqbnc4dmcffs.z03.azurefd.net/debug However, it apparently does not work with domain fronting, so is likely not actually useful. Front Door not working with domain fronting is consistent with prior announcements by Azure: https://github.com/net4people/bbs/issues/67 _______________________________________________ anti-censorship-team mailing list -- anti-censorship-team@lists.torproject.org To unsubscribe send an email to anti-censorship-team-leave@lists.torproject.org
On Wed, 11 Dec 2024, Michael Rogers via anti-censorship-team wrote:
If we want to follow the upstream PT configuration, what's the best way to do that? The config files seem to move around various Tor repositories and at the moment I think we're basing our config on the expert bundle - but does that reflect what actually works/is used by Tor Browser?
Yes, the `tor/pluggable_transports/pt_config.json` in tor-expert-bundle should reflect what is being used in Tor Browser. You can also find it in git (in the `main` branch for alpha releases and the `maint-14.0` branch for the 14.0.* releases): * https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/main/... * https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/maint...
Nicolas
On 11/12/2024 10:51, Nicolas Vigier via anti-censorship-team wrote:
On Wed, 11 Dec 2024, Michael Rogers via anti-censorship-team wrote:
If we want to follow the upstream PT configuration, what's the best way to do that? The config files seem to move around various Tor repositories and at the moment I think we're basing our config on the expert bundle - but does that reflect what actually works/is used by Tor Browser?
Yes, the `tor/pluggable_transports/pt_config.json` in tor-expert-bundle should reflect what is being used in Tor Browser. You can also find it in git (in the `main` branch for alpha releases and the `maint-14.0` branch for the 14.0.* releases):
Fantastic, thank you!
Nicolas
anti-censorship-team mailing list -- anti-censorship-team@lists.torproject.org To unsubscribe send an email to anti-censorship-team-leave@lists.torproject.org
Quoting Michael Rogers via anti-censorship-team (2024-12-11 13:51:37)
On 11/12/2024 10:51, Nicolas Vigier via anti-censorship-team wrote:
On Wed, 11 Dec 2024, Michael Rogers via anti-censorship-team wrote:
If we want to follow the upstream PT configuration, what's the best way to do that? The config files seem to move around various Tor repositories and at the moment I think we're basing our config on the expert bundle - but does that reflect what actually works/is used by Tor Browser?
Yes, the `tor/pluggable_transports/pt_config.json` in tor-expert-bundle should reflect what is being used in Tor Browser. You can also find it in git (in the `main` branch for alpha releases and the `maint-14.0` branch for the 14.0.* releases):
Fantastic, thank you!
Better than pooling from the tor-browser-build repo you can get the same information from the circumvention settings API: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat...
$ curl https://bridges.torproject.org/moat/circumvention/builtin
On 16/12/2024 18:32, meskio wrote:
Quoting Michael Rogers via anti-censorship-team (2024-12-11 13:51:37)
On 11/12/2024 10:51, Nicolas Vigier via anti-censorship-team wrote:
On Wed, 11 Dec 2024, Michael Rogers via anti-censorship-team wrote:
If we want to follow the upstream PT configuration, what's the best way to do that? The config files seem to move around various Tor repositories and at the moment I think we're basing our config on the expert bundle - but does that reflect what actually works/is used by Tor Browser?
Yes, the `tor/pluggable_transports/pt_config.json` in tor-expert-bundle should reflect what is being used in Tor Browser. You can also find it in git (in the `main` branch for alpha releases and the `maint-14.0` branch for the 14.0.* releases):
Fantastic, thank you!
Better than pooling from the tor-browser-build repo you can get the same information from the circumvention settings API: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat...
$ curl https://bridges.torproject.org/moat/circumvention/builtin
Thanks! I was reluctant to use this before because I wasn't sure whether the results would be affected by my client IP address. Does the builtin endpoint return the same results for all clients?
Cheers, Michael
Quoting Michael Rogers (2024-12-17 12:39:28)
On 16/12/2024 18:32, meskio wrote:
Quoting Michael Rogers via anti-censorship-team (2024-12-11 13:51:37)
On 11/12/2024 10:51, Nicolas Vigier via anti-censorship-team wrote:
On Wed, 11 Dec 2024, Michael Rogers via anti-censorship-team wrote:
If we want to follow the upstream PT configuration, what's the best way to do that? The config files seem to move around various Tor repositories and at the moment I think we're basing our config on the expert bundle - but does that reflect what actually works/is used by Tor Browser?
Yes, the `tor/pluggable_transports/pt_config.json` in tor-expert-bundle should reflect what is being used in Tor Browser. You can also find it in git (in the `main` branch for alpha releases and the `maint-14.0` branch for the 14.0.* releases):
Fantastic, thank you!
Better than pooling from the tor-browser-build repo you can get the same information from the circumvention settings API: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat...
$ curl https://bridges.torproject.org/moat/circumvention/builtin
Thanks! I was reluctant to use this before because I wasn't sure whether the results would be affected by my client IP address. Does the builtin endpoint return the same results for all clients?
Yes it does. The only thing that changes is that it will randomly sort the bridges so if clients always use the first few not all clients will use the same.
Incidentally, the team discovered a configuration error today. The Snowflake broker was recently upgraded and reinstalled on a new host (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...) but the snowflake-broker.azureedge.net CDN configuration was still pointing to the *old* broker (which for the time being is still running in parallel.
I'm about to adjust the CDN configuration to point to the new broker: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...
It's like that this will require no action on your part, but if something stops working, it may be the reason why.
On Wed, Dec 11, 2024 at 10:16:32AM +0000, Michael Rogers via anti-censorship-team wrote:
The onionwrapper library (which is used by Briar and OnionShare Android) uses snowflake-broker.azureedge.net and meektm.azureedge.net for certain configurations (depending on the country and Android version, as some older Android devices can't verify Let's Encrypt certificates).
If we want to follow the upstream PT configuration, what's the best way to do that? The config files seem to move around various Tor repositories and at the moment I think we're basing our config on the expert bundle - but does that reflect what actually works/is used by Tor Browser?
Cheers, Michael
On 11/12/2024 06:09, David Fifield via anti-censorship-team wrote:
I got an email on 2024-12-05 saying that that Azure CDN from Edgio/Verizon is going to shut down sooner than expected. The shutdown date was supposed to be 2025-11-04, now it is 2024-01-15 (about one month from now).
This affects (at least) snowflake-broker.azureedge.net, which was first set up and is still on Azure CDN with Edgio. I think that snowflake-broker.azureedge.net has not been used by this team since 2021 and https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_req.... But it is still getting some use from somewhere, as evidenced by the nonzero monthly bills: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-cos... Whatever is out there that is still using snowflake-broker.azureedge.net will likely stop working after 2025-01-15.
Date: 5 Dec 2024 17:03:50 +0000 From: Microsoft Azure azure-noreply@microsoft.com Subject: Urgent action required: Migrate workloads on Azure CDN from Edgio (formerly Verizon) before 15 January 2025
Migrate to Azure Front Door or other CDN services as soon as possible to avoid service disruptions.
Migrate workloads on Azure CDN from Edgio (formerly Verizon) before 15 January 2025.
You're receiving this notice because you're currently using Azure CDN Standard/Premium from Edgio.
All Azure CDN from Edgio customers must migrate their workloads to Azure Front Door or other CDN services before 15 January 2025 as Edgio has advised their platform is currently scheduled to be shut down by that date. Migrate as soon as possible to avoid an imminent service shut-down.
On 31 October 2024, we sent you a notice advising that Azure CDN Standard/Premium from Edgio (formerly Verizon) will be retired on 4 November 2025, and that customers of this service must migrate their workload(s) to a comparable service before this date to avoid service interruptions. In that email we also advised given that Edgio filed for Chapter 11 Bankruptcy on 9 September 2024, Microsoft cannot guarantee that Edgio will continue to support this service through 4 November 2025 as previously stated.
Online references about Azure CDN with Edgio retirement: https://learn.microsoft.com/en-us/azure/cdn/edgio-retirement-faq https://azure.microsoft.com/updates?id=467688
I did try setting up a Front Door CDN profile (which is the recommended replacement for Edgio), following the migration instructions: https://learn.microsoft.com/en-us/azure/frontdoor/migrate-cdn-to-front-door I got the hostname: snowflake-broker-hadmaqbnc4dmcffs.z03.azurefd.net It works as an alias for the broker: curl -i https://snowflake-broker-hadmaqbnc4dmcffs.z03.azurefd.net/debug However, it apparently does not work with domain fronting, so is likely not actually useful. Front Door not working with domain fronting is consistent with prior announcements by Azure: https://github.com/net4people/bbs/issues/67
The unexpected early shutdown of Azure CDN from Edgio/Verizon highlights the challenges of maintaining consistent services amidst infrastructure changes. For those affected, transitioning to alternatives like Azure Front Door, despite its limitations with domain fronting, seems necessary but imperfect. During such transitions, reliable platforms for other critical tasks can help bridge the gap. For instance, users facing downtime or service issues can still rely on resources like https://tmsimregister.ph/tm-sim-no-signal/ or similar tools to stay informed and manage their needs
anti-censorship-team@lists.torproject.org
-
Benjamin Erhart -
Benjamin Erhart -
David Fifield -
meskio -
Michael Rogers -
Nicolas Vigier -
rutificador7＠gmail.com