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:Development · Boards · Anti-censorship · GitLab
* The anti-censorship team's wiki page:
* Home · Wiki · The Tor Project / Anti-censorship / Team · GitLab
* Past meeting notes can be found at:
* The tor-project Archives
* Tickets that need reviews: from projects, we are working on:
* All needs review tickets:
* Merge requests · Anti-censorship · GitLab
* Project 158 <-- meskio working on it
* Issues · Anti-censorship · GitLab
== 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
* Draft: Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (!315) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
* 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: Investigate Distributed Snowflake Rollout Issue on proxy (#95) · Issues · The Tor Project / Anti-censorship / Team · GitLab
* 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
* CI: use Dependency Proxy when available (!522) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
* 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: Add covert-dtls to proxy and client (!448) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
* "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
- [BUG] 20% CPU overhead in kindness mode · Issue #1183 · guardianproject/orbot-android · GitHub
- maybe do some lox work
dcf: 2025-02-27
Last week:
- reviewed snowflake webextension snowflake-allow local storage patch Fix type in localStorage check (!90) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake WebExtension · GitLab
- commented on snowflake broker rate limiting and 504 Raise rate limit for client requests at broker (#40451) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- worked out payment for January 2025 Greenhost invoice Snowflake costs · Wiki · The Tor Project / Anti-censorship / Team · GitLab
- asked about snowflake broker rate limiting, source IP address and X-Forwarded-For What key does the broker rate-limit on? - anti-censorship-team - lists.torproject.org
wrote a summary of this week's reading group paper Identifying VPN Servers through Graph-Represented Behaviors (ACM WWW 2024) · Issue #455 · net4people/bbs · GitHub
Next week:
- open issue to have snowflake-client log whenever KCPInErrors is nonzero Deploy snowflake-server for QueuePacketConn buffer reuse fix (#40260) (#40262) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- parent: Improve bug discovery process (#40267) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- 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
- 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.)( Draft: Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (!315) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab ) improvements
- [Done] Add support for using a proxy to connect to the PTs(Add support for using a proxy to connect to the PTs (#40024) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / lyrebird · GitLab)
- [Done] Add Document for Bridge Line formats ( Add Document for Bridge Line formats (!28) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / WebTunnel · GitLab )
- Merge request reviews
Next Week/TODO:
- Merge request reviews
- [Refine] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( Draft: Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (!315) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab ) improvements
onyinyang: 2025-02-27
Last week(s):
- continued work on ampcache registration method for conjure
- WIP MR: [WIP] Adding AMP Cache registrar to conjure by onyiny-ang · Pull Request #1 · cohosh/conjure · GitHub
- Draft: Ampcache (!34) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / conjure · GitLab
- FOCI
- Finished work on implementing issuer efficiency for check-blockage and trust-promotion protocols
- Implement uCMZ for Lox credentials (!284) · Merge requests · The Tor Project / Anti-censorship / lox · GitLab
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:
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:
- 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: Add covert-dtls to proxy and client (!448) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
Next weeks:
- Write instructions on how to configure covert-dtls with snowflake client
- Fix merge conflicts in MR (Add covert-dtls to proxy and client (!448) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab).
- 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