Hey everyone!

Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-02-27-16.00.html

And our meeting pad:

Anti-censorship work meeting pad -------------------------------- Anti-censorship --------------------------------

Next meeting: Thursday,March  06 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: 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?sc...         * Project 158 <-- meskio working on it             * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_nam...

== Announcements ==

* rdsys 1.0 release         * https://blog.torproject.org/making-connections-from-bridgedb-to-rdsys/

== Discussion ==

for Feb 27:     * Next Step for Datagram mode transport mode for Snowflake         * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...         * The broker can now reject older proxies based on the version number         * The new server, broker, and proxy is designed to work with both new and old client         * We still need to add the support for new protocol to webextension version of the proxy         * Should we add both version of protocol to the client? or should we just merge the proxy, broker, and server code now, and wait long enough before merging the client?         * The plan is to merge and deploy support for the new protocol in proxies first, monitor the status of proxy upgrades, and then later release client support.         * Metrics to track proxy version updates: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/95         * The broker in the MR has the ability to reject all proxies that do not have updated protocol support, which is one way of ensuring compatibility between the protocol support of clients and proxies. (It avoids a situation where a client expects to be able to support the new datagram mode, and gets assigned a proxy that does not support that mode.)             * The broker could, notionally, be more sophisticated, and take protocol support into account when matching clients with proxies. That would also be a way of ensuring backward compatibility. The broker doing that kind of matching was deliberately left out of the early draft of the MR (which focused only on the mechanics of implementing the datagram mode), but could be considered now.         * Options before us:             * 1. Merge and deploy to production the already implemented standalone proxy, broker, and bridge changes. (And implement support in WebExtension proxies in the meanwhile.)             * 2. Deploy a testing broker, in order to test the new protocol without affecting the current proxy pool.                 * This could be with a testing proxy pool or without, or first one then the other.             * 3. Other plans, such as client and proxy version matching.         * shelikhoo will create a testing broker deployment with a small number of proxies for testing. The broker will work with both old and new clients, but the broker, bridge, and proxies must be updated.         * Prepare an MR with just the broker, bridge, and proxy changes. Regardless of how we handle backward compatibility, that will be the first step.     * Gitlab Dependency Proxy and our merge request pipeline         * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...         * The pipeline will stop working when we are developing from our "personal" fork of it         * meskio will check with TPA and see if there's a known solution that works for personal forks.

for March 6:     * Should we user test snowflake with covert-dtls? It is difficult to force Snowflake client to become the DTLS client: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...     * "After some debugging, reading the pion webrtc source code, and referencing RFC 5763 (DTLS-SRTP framework) I realized why hook was never triggered. The Snowflake client will almost always become the server in the DTLS handshake as sends the SDP Offer every time. According to the RFC, only the offer can decide who becomes the client or server."

== Actions ==

== Interesting links ==

* TURN/STUN server networks from https://www.petsymposium.org/foci/2025/foci-2025-0003.php "Using TURN Servers for Censorship Evasion"         * https://developers.cloudflare.com/calls/turn/         * https://www.metered.ca/tools/openrelay/         * https://www.expressturn.com/         * https://xirsys.com/     * https://arxiv.org/abs/2409.06247 "Differential Degradation Vulnerabilities in Censorship Circumvention Systems"         Several recently proposed censorship circumvention systems use encrypted network channels of popular applications to hide their communications. For example, a Tor pluggable transport called Snowflake uses the WebRTC data channel, while a system called Protozoa substitutes content in a WebRTC video-call application. By using the same channel as the cover application and (in the case of Protozoa) matching its observable traffic characteristics, these systems aim to resist powerful network-based censors capable of large-scale traffic analysis. Protozoa, in particular, achieves a strong indistinguishability property known as behavioral independence.         We demonstrate that this class of systems is generically vulnerable to a new type of active attacks we call "differential degradation." These attacks do not require multi-flow measurements or traffic classification and are thus available to all real-world censors. They exploit the discrepancies between the respective network requirements of the circumvention system and its cover application. We show how a censor can use the minimal application-level information exposed by WebRTC to create network conditions that cause the circumvention system to suffer a much bigger degradation in performance than the cover application. Even when the attack causes no observable differences in network traffic and behavioral independence still holds, the censor can block circumvention at a low cost, without resorting to traffic analysis, and with minimal collateral damage to non-circumvention users.     * Wallbleed: A Memory Disclosure Vulnerability in the Great Firewall of China         * https://gfw.report/publications/ndss25/en/

== Reading group ==

* We will discuss "Identifying VPN Servers through Graph-Represented Behaviors" on February 27         * https://dl.acm.org/doi/10.1145/3589334.3645552         * https://dl.acm.org/doi/pdf/10.1145/3589334.3645552         * https://github.com/chenxuStep/VPNChecker         * https://openreview.net/pdf?id=7024czziih public peer reviews         * https://github.com/net4people/bbs/issues/455 dcf's summary         * 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): 2025-02-27     Last week:         - found an issue with the broker's rate limiting (?) causing 504 errors (snowflake#40451)         - debugged and wrote a fix for SQS queue problems (snowflake#40363)         - wrote a fix for config options clobbering each other (snowflake#40483)         - fixed the SQS unit tests (snowflake#40453)         - supported conjure work         - reviewed snowflake!315     This week:         - support conjure work         - follow up on snowflake rendezvous failures         - take a look at potential snowflake orbot bug             - https://github.com/guardianproject/orbot-android/issues/1183         - maybe do some lox work

dcf: 2025-02-27     Last week:         - reviewed snowflake webextension snowflake-allow local storage patch https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...         - commented on snowflake broker rate limiting and 504 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...         - worked out payment for January 2025 Greenhost invoice https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-cos...         - asked about snowflake broker rate limiting, source IP address and X-Forwarded-For https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@l...         wrote a summary of this week's reading group paper https://github.com/net4people/bbs/issues/455     Next week:         - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...             - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...         - open issue to disable /debug endpoint on snowflake broker Help with:

meskio: 2024-02-27     Last week:         - basic rsdys containers (rdsys#219)         - snowflake CI using gitlab container proxy (snowflake!522)         - add settings distributor option to c-tor (tor!860)         - write a blogpost on the rdsys 1.0 release https://blog.torproject.org/making-connections-from-bridgedb-to-rdsys/             - put bridgedb-metrics on logrotate (rdsys-admin!38)             - keep old bridgedb-metrics logs (rdsys!489)     Next week:         - steps towards a rdsys in containers (rdsys#219)

Shelikhoo: 2024-02-27     Last Week:          - [Refine] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... ) improvements          - [Done] Add support for using a proxy to connect to the PTs(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyreb...)          - [Done] Add Document for Bridge Line formats ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtu... )         - Merge request reviews     Next Week/TODO:         - Merge request reviews         - [Refine] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... ) improvements

onyinyang: 2025-02-27     Last week(s):         - continued work on ampcache registration method for conjure             - WIP MR: https://github.com/cohosh/conjure/pull/1                 - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conju...             - FOCI         - Finished work on implementing issuer efficiency for check-blockage and trust-promotion protocols             - https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/284

Next week:         - finish up ampcache registration method (sqs on hold for now)         - Begin work on either obfs4 transport or decoy registration option         - add TTL cache to lox MR for duplicate responses: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/305         As time allows:         - Work on outstanding milestone issues:             - 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: 2025-02-26 (AFK 27 feb)         Last weeks:             - Implementing key_share extension support in covert-dtls             - Debugging Tor Build with covert-dtls: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...         Next weeks:             - Write instructions on how to configure covert-dtls with snowflake client             - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...).             - Condensing thesis into paper (on hold)         Help with:             - Test stability of covert-dtls in snowflake

Facilitator Queue:         meskio onyinyang 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