[tor-project] Anti-censorship team meeting notes, 2023-03-09
meskio
meskio at torproject.org
Thu Mar 9 17:08:28 UTC 2023
Hey everyone!
Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-03-09-15.58.html
And our meeting pad:
Anti-censorship
--------------------------------
Next meeting: Thursday, March 16 16:00 UTC
Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC
(channel is logged while meetings are in progress)
== 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 sponsors, we are working on:
* All needs review tickets:
* https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&assignee_id=None
* Sponsor 28
* must-do tickets: https://gitlab.torproject.org/groups/tpo/-/milestones/10
* possible-do tickets: https://gitlab.torproject.org/groups/tpo/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name%5b%5d=Sponsor%2028&milestone_title=None
* Sponsor 96
* https://gitlab.torproject.org/groups/tpo/-/milestones/24
* Sponsor 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel working on it
* https://pad.riseup.net/p/sponsor139-meeting-pad
== Announcements ==
== Discussion ==
* No news yet about the inclusion of snowflake-02 in Orbot, after asking at S96 meeting.
* the are asking meskio by email privately, but he didn't answer being in vacation, will do today
* What is the procedure for creating a new repository under https://gitlab.torproject.org/tpo/anti-censorship ? Do I need to ask someone to create a repository or can I just do it?
* dcf wants to move other repositories there:
* https://gitlab.torproject.org/dcf/extor-static-cookie
* https://gitweb.torproject.org/pluggable-transports/goptlib.git
* It should be possible to just create new repos.
* dcf will try it, and report back if there's trouble.
* Resynchronization with Upsteamed Remove HelloVerify countermeasure (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40258#note_2883726)
* Syncing with upstream will require dropping one version of golang from CI, are we okay with that?
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/131#note_2869188 "The only problem I'm having with this is that it no longer builds with go1.15 due to the x/crypto dependency update. Is it possible to keep the old version or perhaps rebase these changes off of the versions of pion/dtls and pion/webrtc that we currently have pinned rather than the master branches?"
* go1.15 is the version in current Debian stable (bullseye), go1.19 is available in backports. go1.19 will be the version in the next stable (bookworm) coming in a few months.
== Actions ==
* move the ampcache snowflake fallback forward
== Interesting links ==
*
== Reading group ==
This paper is about detecting Tor-in-obfs4 when you only have a traffic sample; e.g., you only get to look at every 100th packet that passes through a router that handles both obfs4 and non-obfs4 flows. Traffic sampling means you cannot use features like "look at the first n packets of a flow" or "compare the timing of two consecutive packets". Instead, you can only look at aggregate statistical features and have to be memory-efficient.
The system collects 12 statistics (Table III in the appendix) and stores them in a data structure called a nest count Bloom filter (NCBF), which essentially is just a composition of 12 counting Bloom filters (https://en.wikipedia.org/wiki/Counting_Bloom_filter). The statistics are things like "number of non-empty upstream packets" (Cā) and "number of downstream packets with payload length between 62 and 465" (Cāā). From these 12 statistics, they derive 14 features (mostly ratios of statistics) and feed them to a random forest classifier.
For evaluation they use a 15-minute sample of backbone traffic provided by a third party, MAWI (https://mawi.wide.ad.jp/mawi/ditl/ditl2019-G/201904090000.html) and insert their own self-collected obfs4 traffic into it. They say the detection has few false negatives (finds almost all obfs4 bridges), but too many false positives to be usable directly for blocking decisions; they mention the need for "secondary testing" of suspected bridges.
* We will discuss "Detecting Tor Bridge from Sampled Traffic in Backbone Networks" on March 9
* https://www.ndss-symposium.org/wp-content/uploads/madweb2021_23011_paper.pdf
* https://www.youtube.com/watch?v=kL7YCRer3To&list=PLfUWWM-POgQvGOVAk1HjP3uFKoY93_-q9&index=5
* 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): last updated 2023-03-02
Last week:
- Lox tor browser integration work in progress
- https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/116
- Finished getting the wasm client integrated as a Tor Browser module
This week:
- continue Lox tor browser integration
- find a better way to generate and call wasm client in tor-browser-build
- make team repos for Lox pieces
- expand client-side support for more Lox features
- continue work on conjure client-side recovery
Needs help with:
dcf: 2023-03-09
Last week:
- drafted snowflake-01 bridge update for February 2023 https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations/updates/2023-february-update1
- attended 2023-03-04 relay operators meetup and answered questions about snowflake https://lists.torproject.org/pipermail/tor-relays/2023-March/021080.html
- documented further sporadic blocking of cdn.sstatic.net in some networks in Iran https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115#note_2883298
- made a graph of users in Russia since Tor Browser 12.0.3 and the Hello Verify mitigation; curiously it increased users in snowflake-02 but not snowflake-01 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/131#note_2883300
- noticed that conntrack changes did not persist after a reboot on the snowflake bridges, and started an experiment to measure the effect https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40259
Next week:
- migrate goptlib to gitlab https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/86#note_2823122 (for real)
Help with:
meskio: 2023-03-09
Last week:
- catch up (or fail to) after vacation
- deploy and break bridgedb (bridgedb#40064)
- test bridges without ORPort public (rdsys#154)
- review nil pointer fix in webtunnel (webtunnel!5)
- coordinate the update of pion libraries and snowflake in debian, including the HelloVerify patch
Next week:
- rdsys fixes to use onbasca (rdsys#153)
Shelikhoo: 2023-03-09
Last Week:
- [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64)
- [Research] HTTPT Planning https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/httpt/-/issues/1
- WebTunnel @ TorBrowser mobile(https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/663#note_2882700)
- Upstreaming Remove HelloVerify countermeasure (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249)
- Fix return nil error on unrecognized request http upgrade failure (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/merge_requests/5)
- Research on dynamic bridge DOL in china(https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector-admin/-/issues/7#note_2881520)
- meta: fill the "donate" link on addons.mozilla.org (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/79#note_2884226)
- consider propagating 2FA everywhere, maybe at the April Tor Meeting (https://gitlab.torproject.org/tpo/tpa/team/-/issues/41083#note_2884138)
- Review Proxy: add an option to bind to a specific address (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/136#note_2883837)
- Resynchronization with Upsteamed Remove HelloVerify countermeasure (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40258#note_2883726)
Next Week:
- [Research] WebTunnel planning (Continue)
- Try to find a place to host another vantage point
- Fix return nil error on unrecognized request http upgrade failure (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/merge_requests/5)
- Resynchronization with Upsteamed Remove HelloVerify countermeasure (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40258#note_2883726)
onyinyang: 2023-03-09
Last week:
- Working on distributor backend for Lox server (integration with rdsys)
- enabling Lox server to communicate with rdsys through rdsys-backend-api
This week:
- Continuing work on Lox server integration with rdsys
- Reconfigure Lox Bridgeline to fit with Tor's bridge info
- Figure out the proper multithreading in Rust to add bridges to Lox's bridgedb
- (later) Consider a reasonable approach for bridge groupings for Lox buckets
Itchy Onion: 2023-03-08
Last week:
- Finished most of issue #40252 (Standalone proxy outbound address) (!136)
- Worked on issue #40252 (NAT probetest for standalone proxy)
- Started looking at #40231 (Client sometimes send offer with no ICE candidates)
This week:
- Add warning message if the user provided IP address is not used by proxy to establish WebRTC connection (issue #40252 !136). In my testing, sometimes the IP obtained from Pion's selectedCandidatePair is not accurate. I chatted with Pion dev and think there might a bug in Pion. But from my testing it only happens on the first peerconnecion so not a huge problem for us.
- Closed issue #40252 (NAT probetest for standalone proxy)
- Working on #40231 (Client sometimes send offer with no ICE candidates). My current understanding is that this shouldn't happen. There was a similar issue but is fixed and merged: https://github.com/pion/webrtc/issues/1143. Doing more research on it.
hackerncoder: 2023-03-09
last week:
Next week:
- getting ooni-exporter to work with torsf (snowflake)
- ooni-exporter web_connectivity
- work on "bridgetester"?
- how does iran block bridges
cece: 2022-12-22
This week:
- working on creating a dummy WhatsApp bot
Next week:
- My bot is not yet working as expected s? still trying to figure that out
Help with:
- resources
--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20230309/cf3559b7/attachment.sig>
More information about the tor-project
mailing list