- tor-project - lists.torproject.org

Rhatto's Monthly Status Report, September 2024
by rhatto 02 Oct '24

02 Oct '24

Hi all :) This is my monthly status report for September 2024 with the main relevant activities I have done, was involved or are related to my work during the period. For other Onion Services news, check this post: https://forum.torproject.org/t/some-news-from-the-onionspace-2024-09/14963 # Planning Helped with the overall planning for the upcoming Onion Service tooling development. It allowed me to figure out priorities, and finally clean my backlog. This also resulted in creating an Onion Services feature matrix comparing Arti and C Tor: https://onionservices.torproject.org/dev/implementations/ The current plan is summarized below. ## Oniongroove - next generation onionsite manager Project page: https://onionservices.torproject.org/apps/web/oniongroove/ Plan: have Oniongroove acting as a middleware, abstracting specifics from the underlying Tor (and perhaps the HTTPS rewriting proxy) implementation. Advantages: it might be easier for Onion Service Operators to adopt a tool supporting both backends. They can start using the C Tor backend and later on switch for Arti, eg. once the needed feature set becomes supported. Current goals: * Goal 1: support both C Tor and Arti as backends (prototype). * Goal 2: feature-parity with Onionspray, for the C Tor backend (taking some onionsites we manage as a reference for the requirements); migration procedure from Onionspray (production-ready). ## Onionspray - current onionsite manager Project page: https://onionservices.torproject.org/apps/web/onionspray/ Current focus: * Keep supporting Onionspray until there's feature parity with Oniongroove, plus a migration procedure. * Merge requests are welcome :) ## Onionbalance - load balancer for Onion Services Project page: https://onionservices.torproject.org/apps/base/onionbalance/ The road mapping discussion for Onionbalance is still ongoing. Meanwhile, my focus would be to keep the software working, and going through issues and MRs when doable. It's still uncertain how load balancing with Onion Services should be done in the long term, since: * Proof of Work (PoW) Support in Onionbalance is still in the discussion phase: https://gitlab.torproject.org/tpo/onion-services/onionbalance/-/issues/13 * A replacement built-in directly on Arti still needs design; it will possibly be based on changes in the descriptor; a publisher node would be way simpler than the current functionality. There's still no timeline for that. On the other hand, Onionbalance is basically a descriptor publisher. So, roughly speaking, migrating away from Onionbalance to an Arti-equivalent implementation won't require Operators to migrate all their C Tor setup to Arti: they could just replace their Onionbalance instance with something else and keep all their backend onionsites with C Tor for a while. That said, depending on the design changes to implement PoW, it would still be needed to backport this feature to the C Tor backends and clients, which may not be a lot of stuff (possibly just descriptor changes). In summary, one way to move forward could be (but these are still only speculations): 1. Creating a spec for PoW with descriptor-based load balancing: this seems to be mostly about (new) descriptor field(s). 2. Evaluate/scope what would be needed to: * Implement this both for Onionbalance. Maybe it's just a few changes... * Implement this on Arti. That involves implementing the whole load balancing feature. * Backport the changes needed on C Tor both for backends and clients. 3. Then we could decide whether to do it for Onionbalance to win time, or just skip it in favor of a migration. ## Onionprobe - monitoring tool for onionsites Project page: https://onionservices.torproject.org/apps/web/onionprobe/ Current focus: properly set the Grafana dashboard within Tor Project: https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/93 Support for the Arti backend was postponed to future (2026+), after Arti's RPC is stabilized. This is being tracked at https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/86 There are lots of ideas for improvements, that may be implemented opportunistically. # Documentation Did some documentation updates, including: * The Certificate Proposals page: https://onionservices.torproject.org/research/proposals/usability/certifica… * Some roadmap scenarios (but these still need more work): https://onionservices.torproject.org/research/scenarios/ux/ https://onionservices.torproject.org/research/scenarios/network/ -- Silvio Rhatto pronouns he/him

1 0

Nina’s Monthly Status Report, September, 2024
by Nina 02 Oct '24

02 Oct '24

Hi! Below is my September’24 report! In September, I resolved 994 (↑16) tickets: * On Telegram (@TorProjectSupportBot) - 728 (↑41); * On RT (frontdesk@tpo) - 189 (↓44); * On WhatsApp (+447421000612) - 27 (↑19); * and on Signal (+17787431312) - 0 (0). I also took part in forum moderation [1], worked with storereviews, and joinedthe Tor relay operators meetup. The focus of my work is to help Russian-speaking users: - to bypass censorship and to connect to Tor; - to troubleshoot any problems with Tor Browser; - to collect users' feedback and then use it to provide working bridges. We still got many tickets from Russia due to internet censorship getting stronger; our users reported that many Tor bridges didn't work for them.Also, we got multiple requests from Russian-speakingTails users. In September, I also checked and edited several user support templatesused in our support tools. *Google Play Reviews for Tor Browser**(TBA)**and Tor Browser Alpha**for Android* Tor Browser App had a Google Play rating of 4.388-4.390 stars in September 2024. Tor Browser App got 668 reviews out of 57976 for the lifetime. Most often topics of the reviews: - Samsung users point out the error "Proxy server refused connection" on their devices; [2] - Some (mostly Google Pixel) users complain about Tor Browser draining battery of their devices; [3] - Tor Browser doesn't work - mostly from users from Russia, who are struggling to find the working bridge; - Kind words from Portuguese-speaking users from Brazil who started using Tor Browser due to an internet censorship case in the country - the X platform (former Twitter) was blocked [4]. Tor Browser Alpha App had a rating of 4.265, lower than Tor Browser Stable. In September, Tor Browser Alpha got 35 reviews out of 8337 for the lifetime. [1] https://forum.torproject.org [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42714 [3] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43137 [4] https://en.wikipedia.org/wiki/Blocking_of_Twitter_in_Brazil

1 0

Felicia's Montly Status Report, September 2024
by Priscila 01 Oct '24

01 Oct '24

Hi everyone, Here is my status report for September 2024: ### Tor Browser - Designed the implementation of the “New circuit for this site” feature on Android using Acorn’s updated design tokens https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42655 - Adjusted light and dark colors of the onion pattern in about:torconnect https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43087 ### Design System The tasks listed below refer to Figma libraries only: - Joined donuts in a meeting with Mozilla UX team - Unified Mozilla Firefox and Tor’s desktop styles libraries, adding Tor’s specific purple shades for light and dark modes and correcting elements that were out of date https://gitlab.torproject.org/tpo/ux/design/-/work_items/108 - Unified Mozilla Firefox and Tor’s mobile styles libraries, keeping visual elements for Private mode on Android only since it’s the one used in Tor Browser for Android https://gitlab.torproject.org/tpo/ux/design/-/work_items/113 - Unified Mozilla Firefox and Tor Browser’s assets libraries: https://gitlab.torproject.org/tpo/ux/design/-/work_items/109 - Unified Mozilla Firefox and Tor Browser’s components libraries, updating its colors to variables so we can quickly switch between Light and Dark modes while improving consistency (this task was actually finished on October 1, but I’m listing in September as it was almost entirely done then) https://gitlab.torproject.org/tpo/ux/design/-/work_items/110 ### Tor VPN - Joined a brainstorming session for Tor VPN ran by sajolida https://www.figma.com/board/5dWNYdBBEPVJN1kSsZEmrd/VPN-brainstorming?node-i… Cheers, - Felicia / UX Team

1 0

PieroV's Monthly Status Report, September 2024
by Pier Angelo Vendrame 01 Oct '24

01 Oct '24

Hi everyone! Here is my status report for September 2024. I dedicated a consistent part of this month to various tasks to fix regressions we got after migrating to Firefox 128 or for refinements. I started by re-implementing our search engine customization. Upstream themselves reworked their configuration, so I ended up reverting our previous patch and implementing a new one [0]. While at it, I removed some search engines we used to bundle by default, such as Yahoo and Twitter. I also re-implemented the functionality to send DuckDuckGo searches through its HTML-only version when running at the safest security level [1]. After doing this for Tor Browser, I wrote similar patches for Mullvad Browser [2]. After that, I worked on the Android part of our build system. I removed the Lox WASM blob [3], which isn't currently used on Android. This allowed us to ship x86 APKs on the Play Store again. Then, I simulated a release build to check they don't fail when we're close to the release period. However, they didn't work, and I had to fix our dependency list [4]. Also, I fixed single-arch Android test builds [5]. Then, I focused on a disk leak problem. Firefox downloads and opens some formats in the browser without asking for confirmation by default when the server sends them as attachments. There's a preference for force-inlining PDFs (browser.download.open_pdf_attachments_inline), but it doesn't work on other formats. Therefore, I extended that functionality, but I'm not completely satisfied. In our issue [6], I documented all the various problems we still have. However, I will need more time and some help from upstream to provide a better fix. I also went back to one of my passions: fonts. I investigated the differences between having and not having our custom font configuration on Linux [7], and I thought of some strategies for 14.5, as we are too late for 14.0. For now, I created some font aliases to improve compatibility and updated our bundled fonts. In addition to that, I helped with releasing. I rebased our browsers onto Firefox 115.16.0esr and 128.3.0esr. Also, I prepared 13.5.3 and 13.5a10. The latter was an unplanned alpha release from a legacy branch to test the watershed update procedure, which we need to provide alternative updates for legacy platforms (Windows 7/8 and macOS up to 10.14). Finally, I attended the Reproducible Build Summit in Hamburg [8]. I joined the group that focused on writing documentation for repro build beginners. Best, Pier [0] https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42617 [2] https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/328 [3] https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… [4] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4… [5] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4… [6] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42220 [7] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41799 [8] https://reproducible-builds.org/events/hamburg2024/

1 0

TPA-RFC-72: donate site maintenance on Wednesday 2024-10-02
by Antoine Beaupré 26 Sep '24

26 Sep '24

Summary: donation site will be down for maintenance on Wednesday around 14:00 UTC, equivalent to 07:00 US/Pacific, 11:00 America/Sao_Paulo, 10:00 US/Eastern, 16:00 Europe/Amsterdam. # Background We're having [latency issues][] with the main donate site. We hope that migrating it from our data center in Germany to the one in Dallas will help fix those issues as it will be physically closer to the rest of the cluster. [latency issues]: https://gitlab.torproject.org/tpo/web/donate-neo/-/issues/134 # Proposal Move the `donate-01.torproject.org` virtual machine, responsible for the production <https://donate.torproject.org/> site, between the two main Ganeti clusters, following the procedure detailed in [#41775][]. [#41775]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41775 Outage is expected to take no more than two hours, but no less than 15 minutes. # References See the discussion issue for more information and feedback: <https://gitlab.torproject.org/tpo/tpa/team/-/issues/41775> -- Antoine Beaupré torproject.org system administration

1 0

Anti-censorship team meeting notes, 2024-09-26
by Shelikhoo 26 Sep '24

26 Sep '24

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-09-26-16.00.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, Octember 03 16:00 UTC Facilitator: shelikhoo ^^^(See Facilitator Queue at tail) Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: shelikhoo == Goal of this meeting == Weekly check-in about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at the Tor Project and Tor community. == Links to Useful documents == * Our anti-censorship roadmap: * Roadmap:https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards * The anti-censorship team's wiki page: * https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home * Past meeting notes can be found at: * https://lists.torproject.org/pipermail/tor-project/ * Tickets that need reviews: from projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * bridges(a)torproject.org is now served by rdsys, bridgedb is down now == Discussion == * drop in unrestricted proxies * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * not urgent, but something to invetigate early next week * since last week's (2024-09-12) meeting: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * "The count is down to 2090. Whoever has historical Prometheus data, could you please check the drop in unrestricted NAT type per proxy type? See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…. I wonder if only iPtProxy is affected." * Currently there are virtually no unrestricted iptproxy proxies, but maybe there were more in the past (before 2024-09-13)? * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * cohosh will provide WofWca with prometheus data starting from a few days before the drop (Sep 26 New:) * probetest delay-before-disconnect to reduce incorrect "restricted" measurements * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * shelikhoo will deploy next week, maybe Monday 2024-09-30 == Actions == == Interesting links == == Reading group == * We will discuss "" on * * Questions to ask and goals to have: * What aspects of the paper are questionable? * Are there immediate actions we can take based on this work? * Are there long-term actions we can take based on this work? * Is there future work that we want to call out in hopes that others will pick it up? == Updates == Name: This week: - What you worked on this week. Next week: - What you are planning to work on next week. Help with: - Something you need help with. cecylia (cohosh): 2024-09-26 Last week: - worked with meek bridge operator to update domain names - dove into family support for bridges (tor#40935) - TROVE-2024-012 - merged and then unmerged kcp library update This week: - take a look at WofWca's big changes to snowflake - finish snowflake dependency upgrades that were causing problems - take a look at snowflake web and webext translations and best practices - make changes to Lox encrypted bridge table - https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/147 dcf: 2024-09-26 Last week: - archived snowflake-webextension-0.9.0 https://archive.org/details/snowflake-webextension-0.9.0 https://lists.torproject.org/pipermail/anti-censorship-team/2024-September/… - archived snowflake-webextension-0.9.1 https://archive.org/details/snowflake-webextension-0.9.1 - commented on offline stun:stun.bluesip.net:3478 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://lists.mayfirst.org/pipermail/guardian-dev/2024-September/005718.html - helped with replacement snowflake broker setup and commented on new configuration https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - reviewed comment about packet size https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - closed an obsolete issue, broker "status code 400" https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - closed MR that proposed to rename RelayURL to DefaultRelayURL https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented on proposed preflight HEAD request for snowflake bridge authentication https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - reviewed broker bridge list not being set https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - reviewed snowflake webextension manifest v3 running in background https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - made a merge request for code quality in the snowflake webextension https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - reviewed an error handling change for invalid relayURL in proxy https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented on probetest delay-before-disconnect https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented on kcp-go v5.6.10 upgrade causing new failing tests https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented on adding port number to snowflake proxy allowlist https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented on proposal to allow snowflake clients to freely choose their bridge https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - replied to forwarded upstream communication with guardian-dev about inaccurate NAT self-tests by iPtProxy snowflake proxies https://lists.mayfirst.org/pipermail/guardian-dev/2024-September/005719.html - Next week: - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Help with: - tell me when to restart the brokers for https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… meskio: 2023-09-19 Last week: - fail to recover github gettor (rdsys#189) - switch email from BridgeDB to rdsys (rdsys#218) - deploy bridgedb metrics producer (rdsys#218) - review and fix X-Forwarded-From header handling in https and moat (rdsys!390 rdsys!388) - start a conversation with TPA on contanerizing rdsys (tpa/team#41769) Next week: - investigate if bridges are still jumping distributors (rdsys#232) Shelikhoo: 2024-09-26 Last Week: - snowflake broker update/reinstall(cont.): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Merge request review: docs: improve proxy CLI param descriptions (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Merge request reviews Next Week/TODO: - Merge request reviews - snowflake broker update/reinstall(cont.): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.) ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements onyinyang: 2023-09-19 Last week(s): - started looking into troll-patrol integration for Lox bridge blockage detection Next week: - Global Gathering - continue troll-patrol integration for Lox bridge blockage detection - update lox protocols to return duplicate responses for an already seen request - Work on outstanding milestone issues: in particular: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/69 - key rotation automation Later: pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096) - add pref to handle timing for pubkey checks in Tor browser - add trusted invitation logic to tor browser integration: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - improve metrics collection/think about how to show Lox is working/valuable - sketch out Lox blog post/usage notes for forum (long term things were discussed at the meeting!): https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice Question: What makes a bridge usable for a given user, and how can we encode that to best ensure we're getting the most appropriate resources to people? 1. Are there some obvious grouping strategies that we can already consider? e.g., by PT, by bandwidth (lower bandwidth bridges sacrificed to open-invitation buckets?), by locale (to be matched with a requesting user's geoip or something?) 2. Does it make sense to group 3 bridges/bucket, so trusted users have access to 3 bridges (and untrusted users have access to 1)? More? Less? theodorsm: 2024-09-12 Last weeks: - Next weeks: - Update Snowflake to use latest pion upstream releases, waiting for WebRTC v4 beta. - Test Snowflake fork with covert-dtls - Condensing thesis into paper Help with: - Feedback on thesis Facilitator Queue: onyinyang meskio shelikhoo 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 2. After facilitating the meeting, the facilitator will be moved to the tail of the queue

1 0

PSA: GitLab tokens expiring
by Antoine Beaupré 19 Sep '24

19 Sep '24

Hi, GitLab recently introduced a maximum lifetime for *all* access tokens. The change is discussed in a [blog post][1] from last October. Most importantly: > As of the 16.0 milestone (May 2023), we applied an expiration date of > May 14, 2024, to any personal, group, or project access token that > previously didn't have one. We first noticed this issue in [January][2] and have looked at mitigations, but ultimately, there's no good workaround short of "service accounts" which is some Open Core thing they are pushing onto us. There's some work upstream to make it easier to rotate tokens (which make the entire security measure moot in the first place, fun). So anyways. Your things might break now. And when you recreate the tokens, they will still have an upper time limit (one year, IIRC), so you will need to fix this again and again. I'm sorry. Further discussion in [2]. For now our approach is wait and see what gitlab.com is going to do, because this is breaking a *lot* of things in a lot of places, and I can't imagine they will just let the thing burn for that long. The actual recommended workaround from upstream now is to have a *pair* of tokens that renew each other but we have found that to be really impractical. So for now, we're just trying to document the tokens we have and how to refresh them, as an immediate mitigation. I encourage you to pay attention to the "your token has expired" notification as well. Good luck! [1]: https://about.gitlab.com/blog/2023/10/25/access-token-lifetime-limits/ [2]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41510 -- Antoine Beaupré torproject.org system administration

1 2

Anti-censorship team meeting notes, 2024-09-12
by onyinyang 12 Sep '24

12 Sep '24

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-09-12-16.03.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, September 19 16:00 UTC Facilitator: meskio ^^^(See Facilitator Queue at tail) Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: onyinyang == Goal of this meeting == Weekly check-in about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at the Tor Project and Tor community. == Links to Useful documents == * Our anti-censorship roadmap: * Roadmap:https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards * The anti-censorship team's wiki page: * https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home * Past meeting notes can be found at: * https://lists.torproject.org/pipermail/tor-project/ * Tickets that need reviews: from projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * https://bridges.torproject.org and moat are now served by rdsys == Discussion == * shadow integration for snowflake catching some good stuff * backwards compatibility break in snowflake!381 * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * problem with pion/webrtc or pion/transport dependency upgrade in snowflake!357 * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * do we want to create integration tests for other projects? * yes!!! * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * A regression is required for snowflake with this UDP-like transport mode merge request * longer-term goal is to retain backward compatibility, this MR is just meant to isolate the changes required to switch completely to the UDP-like transport, without backward compatibility negotiation * drop in unrestricted proxies * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * not urgent, but something to invetigate early next week == Actions == == Interesting links == * https://opencollective.com/censorship-circumvention/projects/snowflake-dail… * "??" country snowflake users? https://lists.torproject.org/pipermail/anti-censorship-team/2024-September/… * https://mastodon.social/@tdp_org/113108525970163764 * "We monitor traffic to www.bbc.co.uk & www.bbc.com per country & got alerts that daily requests from Angola have dropped off loads recently. ... Digging in to the logs, looks like they removed their Fortigates on 6th Sept. which'd been sending 343k req/day for www.bbc.co.uk/, every single day!" * "I [Neil Craig at BBC] spoke to Fortinet about it once (and asked them to change how the poller works - it was originally doing plaintext http GET requests so I asked them to at least do HTTPS HEADs) - to their credit they made a real effort to help...anyway, I forget how often they poll but IIRC it's something like every 5 or 10s so it doesn't actually take all that many firewalls to get to 343K." * https://github.com/c-skills/passport * "Forwarding TCP ports through Passkey (https://fidoalliance.org/passkeys/) servers to bypass censorship." * "A quite new chapter about Hybrid Transports allows to use QR codes with the authenticator (in this case most likely your smart phone) to authenticate against a service in that authenticator and client platform (in this case most likely your browser) open a tunnel to send PDUs back and forth in a similar way that they would travel via USB or NFC." * https://dpidetector.org/en/ * VPN protocols availability monitoring in Russia == Reading group == * We will discuss "SpotProxy: Rediscovering the Cloud for Censorship Circumvention " on September 12 * https://www.cs-pk.com/sec24-spotproxy-final.pdf * https://censorbib.nymity.ch/#Kon2024b * Questions to ask and goals to have: * What aspects of the paper are questionable? * Are there immediate actions we can take based on this work? * Are there long-term actions we can take based on this work? * Is there future work that we want to call out in hopes that others will pick it up? == Updates == Name: This week: - What you worked on this week. Next week: - What you are planning to work on next week. Help with: - Something you need help with. cecylia (cohosh): 2024-09-12 Last week: - rebased wasm-bindgen fork onto v0.2.93 - followed up on some meek bridge handover tasks - lots of reviews and gitlab todos This week: - take a look at WofWca's big changes to snowflake - grant writing (for conjure) - finish snowflake dependency upgrades that were causing problems - take a look at snowflake web and webext translations and best practices - make changes to Lox encrypted bridge table - https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/147 dcf: 2024-09-12 Last week: - read about pion SetInterfaceFilter https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented on STUN servers not supporting RFC 5780 NAT behavior testing https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented on snowflake proxy NAT type metrics https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - closed issue of stuck snowflake probetest https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented on storage.sync for snowflake WebExtension proxy consent https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - archive snowflake webextension v0.9.0 (manifest V3) - comment as requested on kcp v5.6.17 upgrade https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker - move snowflake-02 to new VM Help with: - tell me when to restart the brokers for https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… meskio: 2023-09-12 Last week: - switch moat and https from BridgeDB to rdsys (rdsys#218) - add ipversion subscription to rdsys (rdsys#221) - recover gitlab gettor account (rdsys#189) - improvements on error logs of the email distributor (rdsys!384) - sanitize prometheus metrics (rdsys#227) Next week: - recover github gettor (rdsys#189) - deploy bridgedb metrics producer (rdsys#218) Shelikhoo: 2024-09-12 Last Week: - snowflake broker update/reinstall: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Unreliable+unordered WebRTC data channel transport for Snowflake rev2( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Probetest Deployment 24-09-10 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Merge request reviews Next Week/TODO: - Merge request reviews - snowflake broker update/reinstall: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Unreliable+unordered WebRTC data channel transport for Snowflake rev2( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements onyinyang: 2023-09-12 Last week(s): - finished up key rotation integration work - started looking into troll-patrol integration for Lox bridge blockage detection Next week: - continue troll-patrol integration for Lox bridge blockage detection - update lox protocols to return duplicate responses for an already seen request - Work on outstanding milestone issues: in particular: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/69 - key rotation automation Later: pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096) - add pref to handle timing for pubkey checks in Tor browser - add trusted invitation logic to tor browser integration: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - improve metrics collection/think about how to show Lox is working/valuable - sketch out Lox blog post/usage notes for forum (long term things were discussed at the meeting!): https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice Question: What makes a bridge usable for a given user, and how can we encode that to best ensure we're getting the most appropriate resources to people? 1. Are there some obvious grouping strategies that we can already consider? e.g., by PT, by bandwidth (lower bandwidth bridges sacrificed to open-invitation buckets?), by locale (to be matched with a requesting user's geoip or something?) 2. Does it make sense to group 3 bridges/bucket, so trusted users have access to 3 bridges (and untrusted users have access to 1)? More? Less? theodorsm: 2024-09-12 Last weeks: - Next weeks: - Update Snowflake to use latest pion upstream releases, waiting for WebRTC v4 beta. - Test Snowflake fork with covert-dtls - Condensing thesis into paper Help with: - Feedback on thesis Facilitator Queue: onyinyang meskio shelikhoo 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 2. After facilitating the meeting, the facilitator will be moved to the tail of the queue -- --- onyinyang GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036

1 0

sysadmin meeting minutes
by Antoine Beaupré 10 Sep '24

10 Sep '24

Hi everyone, it's been a while! # Roll call: who's there and emergencies No fires. anarcat, gaba, lavamind, and two guests. # Dashboard review Normal per-user check-in: * https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&… * https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&… * https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&… General dashboards: * https://gitlab.torproject.org/tpo/tpa/team/-/boards/117 * https://gitlab.torproject.org/groups/tpo/web/-/boards * https://gitlab.torproject.org/groups/tpo/tpa/-/boards # Security policy We had a discussion about the new security policy, details in confidential issue tpo/tpa/team#41727. # Roadmap review We reviewed priorities for September. We decided prioritize the web fixes lavamind was assigned over the Puppet server upgrades as it should be quick and people have been waiting for this. Those upgrades have been rescheduled to October. We will also prioritize the donate-neo launch (happening this week), retiring Nagios, and upgrading mail servers. For the latter, we wish to expedite the work and focus on upgrading over TPA-RFC-45, AKA "fix all of email", which is too complex of a project to block the critical upgrade path for now. # Other discussions Some conversations happened in private about other priorities, documented in confidential issue tpo/tpa/team#41721. # Next meeting Currently scheduled for October 7th 2024 at 15:00UTC. # Metrics of the month * hosts in Puppet: 90, LDAP: 90, Prometheus exporters: 323 * number of Apache servers monitored: 35, hits per second: 581 * number of self-hosted name servers: 6, mail servers: 10 * pending upgrades: 0, reboots: 0 * average load: 1.00, memory available: 3.43 TiB/4.96 TiB, running processes: 299 * disk free/total: 63.64 TiB/135.88 TiB * bytes sent: 423.94 MB/s, received: 274.55 MB/s * planned bookworm upgrades completion date: 2024-08-14 (yes, in the past) * [GitLab tickets][]: 244 tickets including... * open: 0 * icebox: 159 * future: 28 * needs information: 3 * backlog: 30 * next: 11 * doing: 6 * needs review: 9 * (closed: 3660) [Gitlab tickets]: https://gitlab.torproject.org/tpo/tpa/team/-/boards Upgrade prediction graph lives at https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/bookworm/ Now also available as the main Grafana dashboard. Head to <https://grafana.torproject.org/>, change the time period to 30 days, and wait a while for results to render. -- Antoine Beaupré torproject.org system administration

1 0

Rhatto's Monthly Status Report, August 2024
by rhatto 10 Sep '24

10 Sep '24

Hi all :) This is my monthly status report for August 2024 with the main relevant activities I have done, was involved or are related to my work during the period. # Things I've done ## Notes from the Lisbon meeting Finally sorted and edited notes from the Lisbon Meeting! I would like to thank Rasmus Dahlberg for his impressive note taking skills! Public notes are available here: * Onion Plan: https://gitlab.torproject.org/tpo/team/-/wikis/Meetings/2024/Lisbon/onion-p… * ACME for Onions: https://gitlab.torproject.org/tpo/team/-/wikis/Meetings/2024/Lisbon/update-… * Self-authenticated certificates for Onion Services: https://gitlab.torproject.org/tpo/team/-/wikis/Meetings/2024/Lisbon/self-au… ## Onion Services and Mixed content handling Did some security evaluation for Tor Browser about upcoming changes on mixed content handling on upstream Firefox: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43013 ## Onion Discovery Updated some documents related to Onion Discovery: * Onion Association page: https://onionservices.torproject.org/research/proposals/usability/discovery… * Specs for DNS-based .onion records: https://onionservices.torproject.org/research/appendixes/dns/ ## Onionbalance Onionbalance documentation was migrated to Onion MkDocs and included in the Ecosystem: * New URL: https://onionservices.torproject.org/apps/base/onionbalance/ * Related issues: * https://gitlab.torproject.org/tpo/onion-services/onionbalance/-/issues/28 * https://gitlab.torproject.org/tpo/onion-services/ecosystem/-/issues/2 ## House keeping * Created monthly scheduled builds for all major projects at https://gitlab.torproject.org/tpo/onion-services * Created monthly scheduled builds for documentation generators such as Onion MkDocs, Onion TeX Slim and Onion Reveal: * https://gitlab.torproject.org/tpo/web/onion-mkdocs/ * https://gitlab.torproject.org/tpo/web/onion-reveal/ * https://gitlab.torproject.org/tpo/community/onion-tex-slim * Invited the Renovate Bot (https://gitlab.torproject.org/tpo/tpa/renovate-cron) to help keeping some more projects. ## Support * Ongoing sponsored work with deployment, maintenance and monitoring of Onion Services. # Other news from the Onionspace * The ACME for Onions (https://acmeforonions.org/) Internet Draft is going through the Last Call on the IETF working group! Current status available at https://datatracker.ietf.org/doc/draft-ietf-acme-onion/history/ -- Silvio Rhatto pronouns he/him

4 5