tor-project November 2024

tor-project@lists.torproject.org

17 participants
24 discussions

getting ready for TPA holidays
by Antoine Beaupré 20 Dec '24

20 Dec '24

Hi, So it's the most wonderful time of the year and everything... This means that we're actually coming pretty close to the holidays! TL;DR: everything will be fine, but if you need something from us before the holidays, ask now! TPA is, as usual, going to ensure some minimal rotation during the TPI holidays (December 21st to January 5th, inclusively), so we should be able to deal with emergencies. We'll have someone checking alerts and mail on a daily basis, basically. "How to report issues" doesn't change, see: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/support If you're curious, you can see who's on rotation in the "TPA rotations" calendar I have just shared with TPI (an oversight). That said. If you think you might need something urgently before the holidays, it's getting *really* late to tell us now, as we're pretty much trying to wrap up everything to quiet down our infra before the holidays. So if you need anything from TPA, the time to ask for this is pretty much right now, we'll be glad to consider your request! And as the ~3 weeks pass before the holidays, we'll be less and less happy to deal with urgent "oh I just need this blog post" or "can I get a little VM cluster setup now?" right before the holidays. :) (If you need a coordinated release right before the holidays, that's fine too, but let's plan it no!) Thank you for your attention, and happy holidays! a. -- Antoine Beaupré torproject.org system administration

1 1

sajolida's report, September 2024
by sajolida 20 Dec '24

20 Dec '24

Hi, September was again more busy than average to respect the timeline of Project 101 (Tor VPN) and Tails releases. Tor VPN ======= - I analyzed the usability test of Tor VPN 0.6.2 that I did in August. https://gitlab.torproject.org/tpo/ux/research/-/issues/69 In short, the usability of Tor VPN 0.6.2 is decent when people don't need to use a bridge, but very bad when Tor is blocked. None of the participant managed to use a bridge on their own. The main issues are unclear system status and confusing network model. Quotes: “Tor is like a bridge.“ — P5 “I'm looking for bridges that make it like if I were in Switzerland.“ — P4 “It should say: You are being blocked! With Tor you can bypass this censorship using a bridge.“ — P6 Summary of findings: https://gitlab.torproject.org/-/project/92/uploads/1fba8220a110622d852bf448… List of all issues: https://nc.torproject.net/s/fXbRYw76pTXJZym Video clips: https://nc.torproject.net/f/645757 - I created GitLab issues to document the most severe issues: Improve feedback while "Connecting" https://gitlab.torproject.org/tpo/applications/vpn/-/issues/181 Clarify connection status on all screens https://gitlab.torproject.org/tpo/applications/vpn/-/issues/182 Allow changing exit location from Configure menu https://gitlab.torproject.org/tpo/applications/vpn/-/issues/185 Improve discoverability of the list of countries https://gitlab.torproject.org/tpo/applications/vpn/-/issues/186 Clarify what can be tapped in the Bridges screen https://gitlab.torproject.org/tpo/applications/vpn/-/issues/187 Remove the need to press Enter when entering a bridge line https://gitlab.torproject.org/tpo/applications/vpn/-/issues/188 Clarify which bridge is being used (eg. after Bridge Bot) https://gitlab.torproject.org/tpo/applications/vpn/-/issues/189 Improve discoverability of the circuit view https://gitlab.torproject.org/tpo/applications/vpn/-/issues/190 Allow configuring only a single bridge https://gitlab.torproject.org/tpo/applications/vpn/-/issues/193 Rethink how the different relays are named https://gitlab.torproject.org/tpo/applications/vpn/-/issues/194 Clarify just enough about the network model https://gitlab.torproject.org/tpo/applications/vpn/-/issues/195 Don't allow changing exit location unless already connected https://gitlab.torproject.org/tpo/applications/vpn/-/issues/196 Report loss of connectivity to the Tor network https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/110 - I started brainstorming solutions to all of these issues with Duncan and the rest of the UX team. Tails ===== I wrote some documentation to help users with recent issues: - Shim SBAT verification error (#20471) https://tails.net/news/version_6.7/#sbat - Provide fsck from Welcome Screen when the file system of the Persistent Storage is corrupted (#15451) https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1586 This one was a LOT of work to figure out which data forensics path we should recommend to users and document the main ones step-by-step. -- sajolida

1 3

TPA-RFC-74: GitLab CI retention policy
by Jérôme Charaoui 16 Dec '24

16 Dec '24

Summary: a proposal to limit the retention of GitLab CI data to 1 year # Background As more and more Tor projects moved to GitLab and embraced its continuous integration features, managing the ensuing storage requirements has been a challenge. We regularly deal with near filesystem saturation incidents on the GitLab server, especially involving CI artifact storage, such as tpo/tpa/team#41402 and recently, tpo/tpa/team#41861 Previously, [TPA-RFC-14][] was implemented to reduce the default artifact retention period from 30 to 14 days. This, and CI optimization of individual projects has provided relief, but the long-term issue has not been definitively addressed since the retention period doesn't apply to some artifacts such as job logs, which are kept indefinitely by default. [TPA-RFC-14]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/tpa-rfc-14-gitlab-artifa… # Proposal Implement a daily GitLab maintenance task to delete CI pipelines older than 1 year in *all* projects hosted on our instance. This will: * Purge old CI pipeline and job records for the GitLab database * Delete associated CI job artifacts, even those "kept" either: * When [manually prevented from expiring][] ("Keep" button on CI job pages) * When they're the [latest successful pipeline artifact][] * Delete old CI job log artifacts [manually prevented from expiring]: https://gitlab.torproject.org/help/ci/jobs/job_artifacts#with-an-expiry [latest successful pipeline artifact]: https://gitlab.torproject.org/help/ci/jobs/job_artifacts.md#keep-artifacts-… ## Goals This is expected to significantly reduce the growth rate of CI-related storage usage, and of the GitLab service in general. ## Affected users All users of GitLab CI will be impacted by this change. But more specifically, some projects have "kept" artifacts, which were manually set not to expire. We'll ensure the concerned users and projects will be notified of this proposal. GitLab's documentation has the [instructions to extract this list of non-expiring artifacts](https://docs.gitlab.com/ee/administration/cicd/job_artifacts_tro…. ## Timeline Barring the need to further discussion, this will be implemented on Monday, December 9th. ## Costs estimates ### Hardware This is expected to reduce future requirements in terms of storage hardware. ### Staff This will reduce the amount of TPA labor needed to deal with filesystem saturation incidents. # Alternatives considered A "CI housekeeping" script is already in place, which scrubs job logs daily in a hard-coded list of key projects such as c-tor packaging, which runs an elaborate CI pipeline on a daily basis, and triage-bot, which runs it CI pipeline on a schedule, every 15 minutes. Although it has helped up until now, this approach is not able to deal with the increasing use of personal fork projects which are used for development. It's possible to define a different retention policy based on a project's namespace. For example, projects under the `tpo` namespace could have a longer retention period, while others (personal projects) could have a shorter one. This isn't part of the proposal currently as it could violate the principle of least surprise. # References * Discussion ticket: tpo/tpa/team#41874 * [Make It Ephemeral: Software Should Decay and Lose Data](https://lucumr.pocoo.org/2024/10/30/make-it-ephemeral/)

1 1

Tor Project + SEEKCommons Fellowship Opportunity Now Available for 2025!
by gus 10 Dec '24

10 Dec '24

Hello, I'm writing to let you know that applications are now open for the second SEEKCommons Fellowship[1] cohort. The SEEKCommons Fellowship program is funded by NSF and run by partners at University of Notre Dame, University of California Davis, University of Michigan, University of Virginia, and The HDF Group. The goal of the fellowship is to bring graduate students, post-doctoral researchers, and professionals from community-based organizations with new perspectives to socio-environmental research with open technologies. Application deadline is Dec. 15, 2024. The fellowship is designed to: - Encourage new translational and integrative work involving socio-environmental action research with Open Science practices; - Provide a space for Fellows and Network members to collaborate on common research issues, challenges, and solutions. Fellows may be: - Graduate students working with open technologies on socio-environmental issues; - Post-docs with existing community projects in Science and Technology Studies, Open Science, and/or Socio-environmental research; and/or - Community practitioners who are interested in integrating common technologies into their environmental justice work. The SEEKCommons website contains all the necessary fellowship information, including the application link. https://seekcommons.org/fellowship-application.html Partnership SEEKCommons + Tor Project ===================================== This year SEEKCommons is reserving one fellowship to sustainability studies of community networks in partnership with the Tor Project! We welcome Fellowship applications on the sustainability of the Tor network with a focus on energy consumption and relay metadata (such as ASN, uptime, and platform). The goal of the partnership between SEEKCommons and Tor is to study the environmental impact of community networks and promote the use of renewable energy in decentralized infrastructures. We would like to support applications that address one (or more) of these questions: - What Free and Open Source technologies can be used to promote a more sustainable and distributed Tor infrastructure? - How can the energy consumption of the Tor network be measured and optimized to reduce its environmental impact? - How can the "Tor Snowflake" decentralized proxy model be used to improve the sustainability of the network? - How can we use metadata from relays (e.g., ASN / uptime / platform) to assess the environmental impact of the network? - What open hardware and renewable energy sources could be used/reused in the Tor network? More information: https://seekcommons.org/partnership-tor.html If you have any questions, please don't hesitate to reach out. Thank you so much! Warmly, Gus [1] https://seekcommons.org/about.html -- The Tor Project Community Team Lead

1 1

cve's monthly status report
by Clara Engler 04 Dec '24

04 Dec '24

Hello, the following contains my status report for November '24: * Wrote a tiny tool to block Tor with simple firewall rules to simulate a loss of connectivity.[^1] * Discovered a bug in arti while doing this.[^2] * Improved the recognition of being bootstrapped.[^3] * Researched upon loss of connectivity.[^4] * Upgraded various outdated crates in onionmasq by merging overdue MR's from Renovate-Bot * Upgraded `thiserror` to version 2 in arti and onionmasq, fixing a breaking change.[^5] * Allowing packets to be received when the source address is the loopback one.[^6] * This was a particularly difficult issue to tackle that is crucial for testing. * Fixed a general lack of IPv6 connectivity in onionmasq.[^7] * Implemented an HTTP integration test.[^8] * Fixed `wait_for_bootstrap` issue in chutney.[^9] * Fixed a bug in onionmasq for routing UDP datagrams to a loopback address.[^10] * Made the integration test suite ready for UDP.[^11] * Implemented a UDP integration test, thereby greatly bumping the overall coverage.[^11] * Improved documentation of the integration test suite.[^11] * Various reviews of merge requests in arti and onionmasq. * Various feature suggestions in onionmasq through the use of issues. * Legal and bureaucratic matters. [^1]: https://gitlab.torproject.org/cve/torblock [^2]: https://gitlab.torproject.org/tpo/core/arti/-/issues/1731 [^3]: https://gitlab.torproject.org/tpo/core/onionmasq/-/merge_requests/312 [^4]: https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/110 [^5]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2626 [^6]: https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/120 [^7]: https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/122 [^8]: https://gitlab.torproject.org/tpo/core/onionmasq/-/merge_requests/322 [^9]: https://gitlab.torproject.org/tpo/core/chutney/-/merge_requests/39 [^10]: https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/128 [^11]: https://gitlab.torproject.org/tpo/core/onionmasq/-/merge_requests/332

2 1

Moving gitlab to our Dallas cluster on Thursday 2024-11-28
by Gabriel Filion 29 Nov '24

29 Nov '24

Hello, Additionally to the mail server switch on Monday, we're planning to move/migrate the gitlab server from our Falkenstein-based cluster to the one in Dallas. This move will be happening on Thursday november 28th starting at 18:00 UTC. The disks for the gitlab server are fairly sizeable so the transfer could be taking a long time. Our current estimates are that it could take about 18 hours to transfer. We will try launching an operation to zero out empty parts of the disk volumes before starting the transfer in the hopes that it could give the transfer a boost. So the transfer will most likely take gitlab offline until the next day, friday 29th, at which time we'll make sure that the service is coming back online properly. If there's any issue during the outage, please reach out to us via IRC or email, but not through gitlab issues since this last one will obviously be offline at that time. For status updates, see: https://status.torproject.org/issues/2024-11-28-gitlab-migration/ Cheers!

1 1

Anti-censorship team meeting notes, 2024-11-28
by Shelikhoo 28 Nov '24

28 Nov '24

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-11-28-16.00.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, December 05 16:00 UTC Facilitator: onyinyang ^^^(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 == == Discussion == (old) * Snowflake blocking in Russia November 2024 * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * No apparent difference in DTLS handshakes between proxies that continue working and proxies that stop working. * Reports say that some proxies stop working, but only after transferring some traffic. * Hard to test because we can't easily control the proxy. It would be a good idea to set up a small test deployment to afford us more experimental control. * cohosh will work on that. * Traffic analysis fingerprinting? An old padding patch: https://github.com/net4people/bbs/issues/255#issuecomment-1566227484\ (New Nov 21) * Snowflake blocking in Russia November 2024 * Restored copy-paste signaling (manual without broker) to be able to control the proxy connection. * https://gitlab.torproject.org/cohosh/snowflake/-/commit/a4a574a4584332fc282… * Still blocked with a new proxy: therefore likely some kind of protocol fingerprinting, not proxy enumeration. * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * Still blocked with client-side padding patch as well. * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * theodorsm's covertDTLS fork https://gitlab.torproject.org/theodorsm/snowflake/-/tree/covert-dtls-test * Snowflake broker transition * Next monday 2024-11-25 there will be a DNS switch from the current broker to the new broker primary. * https://gitlab.torproject.org/tpo/tpa/team/-/issues/41878 (new Nov 28) * Broker Transition Anomaly * (added by non-Tor member WofWca): Evaluate [the plan for "Multi-Pool Matching Support"](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40156#note_3132445)? * Snowflake blocking in Russia seems to have stopped == 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-11-28 Last week: - followed up on the snowflake blocking in Russia - helped debug and recover from the snowflake broker upgrade - caught up a bit on reviews - fixed the logging of the new proxy event (snowflake#40413) - started looking at alerts for censorship events (snowflake#40416) This week: - alerts for censorship events (snowflake#40416) - keep looking at snowflake blocking in Russia - take care of review backlog - 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 Needs help with: - what was that censorship events mailing list? dcf: 2024-11-21 Last week: - released goptlib v1.6.0 https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… Next week: - comment on updates to unreliable snowflake transport 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 Help with: meskio: 2024-11-28 Last week: - investigate why the metrics of the new broker were not arriving to prometheus (tpa/team#41902) - try to upgrade snowflake gitlab CI to debian stable and fail (for now) - multiple grant writting work (logic model, reviews, ...) - reports for grants fun - WIP: update snowflake proxy debian package (snowflake#40414) Next week: - update snowflake proxy debian package (snowflake#40414) Shelikhoo: 2024-11-28 Last Week: - [Pending] snowflake broker update/reinstall(cont.): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - [Awaiting Review] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Vantage point deployment in Iran - Snowflake new broker deployment - Merge request reviews Next Week/TODO: - Merge request reviews - Work on finishing snowflake container release(and fix the comments) - Incorrectly flattened container image with "pull" command https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… onyinyang: 2024-11-21 Last week(s): - working on refactor of Lox (library) protocols to improve issuing efficiency as described in: https://eprint.iacr.org/2024/1552.pdf - WIP MR: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/284 - Adjusted dependencies to line up with non-wasm browser integration for: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096): - https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/283 - Updating renovate bot to ignore these dependencies (and maybe others) - Fixed up wasm changes in https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/271 Next week: - Fix up Troll-patrol MR - Deploy test distributor - Continue work on improving issuer efficiency in Lox protocols - 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!): - 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-10-24 Last weeks: - Adjusting to post-student life - Testing out beta releases of pion dtls and webrtc Next weeks: - Update Snowflake to use latest pion upstream releases - 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

Reminder: planned maintenance on Hetzner network december 3rd 3:30 UTC
by Gabriel Filion 26 Nov '24

26 Nov '24

Hello all, I'm sending a reminder about this since the last communication about it was more than a month ago. Hetzner is planning to perform maintenance on their networking equipment next week, on December 3rd between 3:30 and 5:30 UTC. This is something that the TPA team does not have control over. We can expect some network outage for all hosts at Hetzner during that time (which is just a handful of our servers). None of our hosts will reboot during that time, they will just momentarily lose network connectivity. More details can be seen on status.torproject.org and the maintenance announcement was already planned as soon as we got the notice from Hetzner. The announcement lists the services which can be expected to have an outage: https://status.torproject.org/issues/2024-12-03-hetzner-router-maintenance/ Thanks all for your understanding, LeLutin for TPA

1 0

Anti-censorship team meeting notes, 2024-11-21
by Shelikhoo 21 Nov '24

21 Nov '24

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-11-21-16.00.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, November 28 16:00 UTC Facilitator: onyinyang ^^^(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 == == Discussion == (old) * Snowflake blocking in Russia November 2024 * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * No apparent difference in DTLS handshakes between proxies that continue working and proxies that stop working. * Reports say that some proxies stop working, but only after transferring some traffic. * Hard to test because we can't easily control the proxy. It would be a good idea to set up a small test deployment to afford us more experimental control. * cohosh will work on that. * Traffic analysis fingerprinting? An old padding patch: https://github.com/net4people/bbs/issues/255#issuecomment-1566227484 * on monday shelikhoo will start the move to the new broker * WebTunnel Server utility command interface * for certificate pinning we need to generate a hash of the certificate chain * there is no standard tooling for that, we need to extend webtunnel to do that * lets add a -gen-cert-fp flag (New Nov 21) * Snowflake blocking in Russia November 2024 * Restored copy-paste signaling (manual without broker) to be able to control the proxy connection. * https://gitlab.torproject.org/cohosh/snowflake/-/commit/a4a574a4584332fc282… * Still blocked with a new proxy: therefore likely some kind of protocol fingerprinting, not proxy enumeration. * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * Still blocked with client-side padding patch as well. * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * theodorsm's covertDTLS fork https://gitlab.torproject.org/theodorsm/snowflake/-/tree/covert-dtls-test * Snowflake broker transition * Next monday 2024-11-25 there will be a DNS switch from the current broker to the new broker primary. * https://gitlab.torproject.org/tpo/tpa/team/-/issues/41878 * expired cdn77 alerts * https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-alert… == Actions == == Interesting links == * https://github.com/doxx/darkflare * TCP over CDN. using cloudflare to tunnel traffic, the client does HTTP requests. * https://www.youtube.com/watch?v=rZYfrj2iqYE&list=PLbRoZ5Rrl5ldQ2K_dpmPKHEyR… * Snowflake conference presentation from Usenix Security 2024 == 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-11-21 Last week: - simplified the bridge_blocked function in lox (lox!277) - improved clean up function and tests (lox!281) - grant stuff - iptproxy rewrite now released - fixup for snowflake transport in lyrebird - lox reviews - tried some Snowflake experiments from the vantage point in Russia (snowflake#40407) This week: - keep looking at snowflake blocking in Russia - take care of review backlog - 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 Needs help with: dcf: 2024-11-21 Last week: - released goptlib v1.6.0 https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… Next week: - comment on updates to unreliable snowflake transport 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 Help with: meskio: 2024-11-21 Last week: - investigate OnionSproutsBot freeze (onionsproutsbot#68) - distribute windows7 TorBrowser installers in OnionSproutsBot (onionsproutsbot#64) - fix OnionSproutsBot locale deployment so all locales appear (onionsproutsbot#60) - multiple grant writting work (reviews, risks assesments, ...) - WIP on snowflake proxy package for debian (snowflake#40414) Next week: - update snowflake proxy debian package (snowflake#40414) Shelikhoo: 2024-11-21 Last Week: - [Pending] snowflake broker update/reinstall(cont.): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - [Awaiting Review] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - [Awaiting Input] Review CI: fix `latest` container image tag. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Request to update domain snowflake-broker.torproject.net with correct CAA record (https://gitlab.torproject.org/tpo/tpa/team/-/issues/41878) - Rapid response fund for webtunnel dynamic bridges ( https://gitlab.torproject.org/tpo/operations/proposals/-/issues/88 ) - Choosing next provider target(s) for Rapid Response Funded Dynamic Bridges ( https://gitlab.torproject.org/tpo/community/relays/-/issues/106 ) - Merge request reviews Next Week/TODO: - Merge request reviews - Work on finishing snowflake container release(and fix the comments) - Vantage point deployment in Iran - Snowflake broker deployment onyinyang: 2024-11-21 Last week(s): - working on refactor of Lox (library) protocols to improve issuing efficiency as described in: https://eprint.iacr.org/2024/1552.pdf - WIP MR: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/284 - Adjusted dependencies to line up with non-wasm browser integration for: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096): - https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/283 - Updating renovate bot to ignore these dependencies (and maybe others) - Fixed up wasm changes in https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/271 Next week: - Fix up Troll-patrol MR - Deploy test distributor - Continue work on improving issuer efficiency in Lox protocols - 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!): - 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-10-24 Last weeks: - Adjusting to post-student life - Testing out beta releases of pion dtls and webrtc Next weeks: - Update Snowflake to use latest pion upstream releases - 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

Switching mail servers on Monday 2024-11-25
by groente 21 Nov '24

21 Nov '24

Hey everyone, On November 25st 2024, starting at 11:00 UTC, we will be switching to new mail servers for receiving and forwarding mail sent to torproject.org. If all goes well, there will be no downtime and deliverability to external providers like gmail will improve. If all does not go well, please reach out on IRC or file an issue on Gitlab, do not mail TPA since e-mail may obviously not be reliable. For more details on how to get in touch and how to report e-mail problems, see: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/support For status updates, see: https://status.torproject.org/issues/2024-11-25-switching-mail-servers/ Fingers crossed :) x, groente

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

tor-project November 2024