- anti-censorship-team - lists.torproject.org

Deprecation of Azure CDN from Edgio (azureedge.net), replaced by Azure Front Door (azurefd.net), affects snowflake-broker.azureedge.net
by David Fifield 22 Apr '25

22 Apr '25

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_re…. 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-co… 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(a)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

8 22

set yourself a new password for prometheus / grafana
by Gabriel Filion 17 Apr '25

17 Apr '25

Hello! I'm writing to inform you that TPA's been moving on something that should make it possible to eventually merge both of the prometheus / grafana servers: we're moving towards per-user passwords that need to be set through LDAP and deprecating the shared passwords. I would invite everyone who needs to continue accessing prometheus and grafana (either on prometheus1.tpo or prometheus2.tpo) to head over to https://db.torproject.org/ , login and set yourself a password in the "Web password" field. That field was previously hidden but it was recently added to the form. The password will take some time to get synchronized to the servers, so allow some 1 to 2 hours before you test out your new credentials. When ready, head over to https://grafana2.torproject.org/ and use your ldap username with your new web password to confirm that you're able to login there. The shared passwords that are currently in use are bound to be removed on April 17th. If you're having issues with setting up and/or using your own credentials to access prometheus and grafana, please contact TPA and we'll take a look with you into what's happening. Cheers! additional note for TPA members: we now have a fallback password that's present in our password manager. it should let us access the monitoring sites even if ldap has a disruption. you can try that one as well.

3 6

Fwd: [Docker] Confirmation - Subscription Canceled
by meskio 15 Apr '25

15 Apr '25

I got this email out of the blue. It looks like docker has canceled our sponsored open source subscription without any warning. It looks like all our images are still there, I'm trying to contact them to see what is happening. Forwarded message from Docker (2025-04-15 02:04:16): > [1][IMG] > Hello thetorproject! > We're sad to see you go. This email confirms that your Docker-Sponsored > Open Source subscription for your account has been canceled. > [2]View past invoices > Please keep this email for your records. If you have any questions, reach > out to our [3]support team. > If you would like to regain access, you can [4]manage your subscription. > Thank you, > The Docker Team > > This email was sent to meskio(a)sindominio.net to notify you of an update > that was made to your Docker Account. > [5]© 2025 Docker Inc. > 3790 El Camino Real #1052, Palo Alto, CA 94306 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 1

Snowflake bridges using SQS
by Michael Rogers 26 Mar '25

26 Mar '25

Hi all, After updating Briar's bridge config to use the current settings from Moat, we're seeing two Snowflake bridges consistently failing in our CI tests. They're the two bridges that use SQS. Here's a snippet from the log: ``` INFO: NOTICE Managed proxy "/builds/briar/onionwrapper/onionwrapper-java/test.tmp/35/lyrebird": offer created Feb 04, 2025 1:12:34 PM org.briarproject.onionwrapper.AbstractTorWrapper message INFO: NOTICE Managed proxy "/builds/briar/onionwrapper/onionwrapper-java/test.tmp/35/lyrebird": broker failure operation error SQS: GetQueueUrl, https response error StatusCode: 400, RequestID: 60e91cfa-a2a0-55db-beb0-7ce6b621d324, AWS.SimpleQueueService.NonExistentQueue: The specified queue does not exist. ``` Does the queue really not exist, or does this point to some other issue, like the bridges being geoIP restricted or the app needing to pass some extra information to the transport? Thanks, Michael

2 6

What key does the broker rate-limit on?
by David Fifield 28 Feb '25

28 Feb '25

The Snowflake broker's request rate limiting, what does it key on? The source IP address, X-Forwarded-For, or something else? This is where the rate limiting was introduced: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… location ~ ((proxy)|(client)|(answer)|(metrics)|(prometheus)|(amp/client/.*)|(robots.txt)) { limit_req zone=snowflake burst=3; proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; } limit_req_zone $binary_remote_addr zone=snowflake:10m rate=1r/s; Here's another, more recent snapshot of the configuration: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… location ~ ((proxy)|(client)|(answer)|(metrics)|(prometheus)|(amp/client/.*)|(robots.txt)) { limit_req zone=snowflake burst=3; proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_read_timeout 300; proxy_connect_timeout 300; proxy_send_timeout 300; proxy_set_header X-Forwarded-For $proxy_protocol_addr; } limit_req_zone $proxy_protocol_addr zone=snowflake:10m rate=1r/s; If the limited is using the source IP address, then different clients could be causing each other to be rate-limited, because many requests come from the same CDN IP address (or whatever). If the limiter is using X-Forwarded-For or similar, then it's possible to evade the limiter by putting random or incrementing IP addresses in the header.

2 2

OpenReview of "Identifying VPN Servers through Graph-Represented Behaviors"
by David Fifield 26 Feb '25

26 Feb '25

The peer reviews of this week's reading group paper are public: https://openreview.net/forum?id=7024czziih I hadn't known it before, but peer reviews are public for all ACM WWW accepted papers: https://www2024.thewebconf.org/calls/research-tracks/ "By submitting paper(s) to The Web Conference 2024, the authors agree that the reviews, meta-reviews, and discussions will be made public in OpenReview for all accepted papers." You can see the reviewers' brief written summaries, and reviewer adPJ raising the possibility that VPN detection could "amplify censorship attempts which are rampant on the web today especially by authoritarian governments". While it was still a submission, the system was apparently called "VPNSniffer" rather than "VPNChecker".

2 2

(FWD) Online FOCI workshop 2025-02-20
by Roger Dingledine 12 Feb '25

12 Feb '25

----- Forwarded message from Jeffrey Knockel <jeff(a)citizenlab.ca> ----- Date: Wed, 12 Feb 2025 09:20:44 -0500 From: Jeffrey Knockel <jeff(a)citizenlab.ca> To: undisclosed-recipients: ; Subject: Online FOCI workshop 2025-02-20 Dear FOCI community, The first of two Free and Open Communications on the Internet (FOCI) workshops in 2025 will happen on February 20th 17:00 - 21:30 UTC <https://www.timeanddate.com/worldclock/fixedtime.html?msg=Virtual+FOCI+2025…>. This event is fully online and free. The event will take place on gather.town <https://app.gather.town>, and registration is required to receive a link for attending the event. Event web site: https://foci.community/ Registration: https://foci.community/register The program includes a keynote and 5 research presentations. The full schedule is available on the event website: * *Keynote: When the World Pushes Back: Enumerating Risks of Digital Accountability Research* Ronald Deibert * *Extended Abstract: Using TURN Servers for Censorship Evasion* Afonso Vilalonga, Kevin Gallagher, João Resende, Osman Yagan, and Henrique Domingos * *Is Custom Congestion Control a Bad Idea for Circumvention Tools?* Wayne Wang, Diwen Xue, Piyush Kumar, Ayush Mishra, Anonymous, and Roya Ensafi * *I(ra)nconsistencies: Novel Insights into Iran's Censorship* Felix Lange, Niklas Niere, Jonathan von Niessen, Dennis Suermann, Nico Heitmann, and Juraj Somorovsky * *The Mechanics of Surveillance in Leading Pakistani Mobile Apps* Sana Habib, Mohammad Taha Khan, and Jedidiah R. Crandall * *Revisiting BAT Browsers: Protecting At-Risk Populations from Surveillance, Censorship, and Targeted Attacks* Esther Rodriguez, Lobsang Gyatso, Tenzin Thayai, and Jedidiah R. Crandall -- Jeff & Tariq ----- End forwarded message -----

1 0

moderation in the list
by meskio 11 Feb '25

11 Feb '25

Looks like AI spam is becoming more common, see the last thread "Inquiry Regarding the Deprecation of Azure CDN (azureedge.net)"[0]. To stop it I have enabled the moderation of new messages to the list as a temporary solution. Any subscriber that was already a member of the list before the migration to mailman3[1] is not moderated and can write directly to the list. But any new subscriber will be moderated. I would propose that we unmoderate manually after the first email if is not spam. But let's discuss it next thursday. [0] https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… [1] https://lists.torproject.org/mailman3/hyperkitty/list/tor-project@lists.tor… -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

Inquiry Regarding the Deprecation of Azure CDN (azureedge.net)
by tmsimregph＠gmail.com 11 Feb '25

11 Feb '25

Subject: Inquiry Regarding the Deprecation of Azure CDN (azureedge.net) Dear [Recipient's Name or Anti-Censorship Team], I hope this email finds you well. I came across the discussion regarding the early deprecation of Azure CDN services (azureedge.net) by Edgio/Verizon and its replacement with Azure Front Door (azurefd.net) I understand that this unexpected change poses significant challenges for users and services relying on domain fronting for critical operations. The shutdown highlights the need for reliable alternatives during such transitions. Could you provide further insights or recommendations for mitigating service disruptions, especially for those still using snowflake-broker.azureedge.net or similar configurations? Additionally, any updates regarding the migration process to Azure Front Door would be greatly appreciated. In the meantime, I also recommend visiting my website, https://tmsimreg.ph/, for helpful resources and discussions related to similar transitions. Thank you for your time and efforts in addressing these challenges. I look forward to your guidance. Best regards, Leandro tmsimregph(a)gmail.com

2 1

[eclips.is] The future of eclips.is
by David Fifield 06 Feb '25

06 Feb '25

The Snowflake broker is currently hosted on Greenhost's subsidized eclips.is platform. Their funding has ended, and they are moving to a partial user-pays model. For the next year Greenhost will self-fund up to 50 EUR per month per user. I am not sure whether we fit under that threshold. ----- Forwarded message from Greenhost <support(a)greenhost.nl> ----- Date: Thu, 31 Oct 2024 14:43:05 +0000 From: Greenhost <support(a)greenhost.nl> To: david(a)bamsoftware.com Subject: [eclips.is] The future of eclips.is Hello david(a)bamsoftware.com, Hope you’re doing well! We’re happy to inform you that all VPSs have been successfully migrated from our Miami data center to Amsterdam. Please take a moment to check that your VPS is functioning as expected, and let us know if you encounter any issues. As mentioned earlier this year, funding support from the Open Technology Fund (OTF) will conclude on October 31st, 2024 (today). However, Greenhost is committed to ensuring continued service and will fully support eclips.is through December 31st, 2024. Starting January 1st, 2025, Greenhost will migrate eclips.is to a hybrid model. We will provide every account with a free tier of up to EUR 50 per month. Based on usage data, this will cover about 90% of current accounts. As a result, for the majority of accounts/users, nothing will change. For accounts using more resources, the portion above EUR 50 per month will be charged, with a discount of 25% applied. This model will be in place until at least October 31st, 2025. During the year, we will assess this model and determine if it is sustainable long-term. With this approach, Greenhost has found a good balance between continuing to fully support grassroots and small organizations, and providing heavy users with an affordable service. This sponsorship represents approximately €120,000 per year, and Greenhost is proud to be able to provide this service to the community without funding. However, we are dedicated to exploring extra funding options to further support the community and broaden our user base. For users who can fully cover their service costs, we encourage you to purchase directly through the Greenhost website. Direct purchases strengthen our ability to support the community in the long term. Thank you for being part of this journey! The Greenhost Team -- Voor vragen of opmerkingen kunt u contact opnemen via info(a)greenhost.nl Volg ons / Follow us: Website: https://greenhost.net/blog Twitter: https://twitter.com/greenhost ----- End forwarded message -----

2 6