[tor-project] Anti-censorship team meeting notes, 2023-03-09

meskio · March 9, 2023, 5:08pm

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: 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 sponsors, we are working on:
    * All needs review tickets:
      * Merge requests · Anti-censorship · GitLab
    * Sponsor 28
      * must-do tickets: Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR) · The Tor Project · GitLab
      * possible-do tickets: Issues · The Tor Project · GitLab
    * Sponsor 96
      * Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet · The Tor Project · GitLab
    * Sponsor 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel working on it
      * Riseup 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 Anti-censorship · GitLab ? Do I need to ask someone to create a repository or can I just do it?
    * dcf wants to move other repositories there:
      * David Fifield / extor-static-cookie · GitLab
      * pluggable-transports/goptlib - Go pluggable transports library
    * 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 (Resynchronization with Upsteamed Remove HelloVerify countermeasure (#40258) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab)
    * Syncing with upstream will require dropping one version of golang from CI, are we okay with that?
    * Apply Skip Hello Verify Migration (!131) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab "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 (Counting Bloom filter - Wikipedia). 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
    * NDSS 2021 MADWeb - Detecting Tor Bridge from Sampled Traffic in Backbone Networks - YouTube
    * 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
        - Trial Lox integration (#116) · Issues · The Tor Project / Anti-censorship / Team · GitLab
        - 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 2023 February update - Open Collective
    - attended 2023-03-04 relay operators meetup and answered questions about snowflake [tor-relays] Next Tor Relay Operator Meetup - March 4, 2023 (19 UTC)
    - documented further sporadic blocking of cdn.sstatic.net in some networks in Iran Blocking of cdn.sstatic.net by SNI in Iran, 2023-01-16 to 2023-01-24 and sporadically thereafter (#115) · Issues · The Tor Project / Anti-censorship / Team · GitLab
    - 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 Apply Skip Hello Verify Migration (!131) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
    - noticed that conntrack changes did not persist after a reboot on the snowflake bridges, and started an experiment to measure the effect Make nf_conntrack changes persistent (#40259) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
  Next week:
    - migrate goptlib to gitlab migrate away from git.torproject.org (#86) · Issues · The Tor Project / Anti-censorship / Team · GitLab (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)

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: pc.LocalDescription() does not contain "a=candidate" · Issue #1143 · pion/webrtc · GitHub. 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.