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

meskio meskio at torproject.org
Thu Mar 3 17:39:40 UTC 2022 

Hey everyone!

Here are our meeting logs:

http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-03-03-15.59.html

And our meeting pad:

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

Next meeting: Thursday March 10th 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 checkin about the status of anti-censorship work at Tor.
Coordinate collaboration between people/teams on anti-censorship at Tor.

== 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 30

    https://gitlab.torproject.org/groups/tpo/-/milestones/4

    https://gitlab.torproject.org/groups/tpo/-/milestones/7

    https://gitlab.torproject.org/groups/tpo/-/milestones/5

    https://gitlab.torproject.org/groups/tpo/-/milestones/6

    Sponsor 28

    must-do tickets: https://gitlab.torproject.org/groups/tpo/-/milestones/10

    possible 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


== Announcements ==

    Centralized Probe Result Collector on trial deployment

    Russia, Turkey, Beijing probetests are integrated

    BridgeDB is now using rdsys


== Discussion ==

    obfs4 fail to connect issue

    https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804

    we are coordinating with builtin bridges to update, many has already updated

    there is now a docker image with the new version

    the obfs4proxy 0.0.13 package will land in debian backports soon

    snowflake load and bottlenecks

    do we need more proxies?

    next steps for bridge capacity

    probetest is at is capacity

    could standalone proxies (which can make direct TCP connections) bypass snowflake-server and connect directly to the tor ExtORPort

    no, snowflake-server holds the turbo tunnel state

    we want to move into a design where there are multiple snowflake-servers and multiple bridges

    idea: partition snowflake-servers and bridges into non-overlapping "pools"

    i.e., snowflake-server A forwards to a set of bridges, snowflake-server B forwards to *its* set of bridges, and they share no bridges in common

    (which is a generalization of the current case, where there is 1 snowflake-server and 1 bridge)

    (there could be distinct brokers for different pools, but that is orthogonal)

    partitioning the set of bridges has this effect: when a broker/proxy wants to connect a client's traffic to a snowflake-server, for a specific bridge there is *one and only one* snowflake-server that is associated with that bridge

    therefore multiple connections in the same session, which use the same bridge, will also use the same snowflake-server, and therefore not lose turbo tunnel state

    it can work like this:

    the client torrc specifies the desired bridge fingerprint in its bridge line as a SOCKS param (redundantly with the fingerprint that is already there as part of the syntax)

    e.g. `Bridge snowflake 1111222233334444aaaabbbbccccdddd 192.0.2.3:1 url=https://snowflake.torproject.net/ front=front.example.com ice=... fingerprint=1111222233334444aaaabbbbccccdddd`

    the client sends the desired bridge fingerprint along with its offer to the broker

    the broker has a mapping of bridge fingerprints to snowflake-server WebSocket URLs. when the broker matches the client with a proxy, the broker informs the proxy of the WebSocket URL to connect to (i.e., which snowflake-server to connect to). it will always be the same snowflake-server URL for the same bridge fingerprint, because the mapping is consistent.

    the proxy connects to the WebSocket URL provided by the broker, and it includes the bridge fingerprint in the URL query string when it makes the connection (the same way the client IP address is communicated: e.g. `?client_ip=1.2.3.4:5678&fingerprint=1111222233334444aaaabbbbccccdddd`)

    the snowflake-server has its own mapping of bridge fingerprint to ExtORPort addresses. if it's an existing turbo tunnel session, it just resumes the ExtORPort TCP it already has. if it's a new session, it connects to the ExtORPort address corresponding to the bridge fingerprint.

    such a design alleviates the state-sharing concerns with multiple snowflake-servers. as long as a client uses a consistent bridge fingerprint during a session (which it will), it will get mapped to the same snowflake-server.

    arlolra is planning to write a patch for including the bridge fingerprint as a bridge line SOCKS param, and passing it to the broker, which is a necessary step for any of this

    then there can be multiple snowflake bridge lines in torrc, each with different bridge fingerprints. load balancing will come from the tor client's local random selection.

    there is a "thundering herd" concern with the way tor currently uses multiple bridge lines. tor will attempt to connect to all of them at once, and keep using only one of them. This means N broker transactions and N STUN exchanges, and possibly N-1 proxies held idle.

    maybe it's not such a big problem, if N is not too large

    an alternative would be a modification to tor where it shuffles its bridge list, and tries only one at a time

    another alternative is to write the torrc file dynamically: choose a random bridge line, then write torrc containing only that one randomly selected bridge line

    https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651

    need to consider backward compatibility: a client that doesn't communicate its desired fingerprint gets mapped to the existing 


== Actions ==


== Interesting links ==

    https://archive.org/details/ptim2021 Pluggable Transports Implementers Meeting 2021 videos


== Reading group ==

    We will discuss "Throttling Twitter: an emerging censorship technique in Russia" on 10 March

    https://dl.acm.org/doi/pdf/10.1145/3487552.3487858

    https://censorbib.nymity.ch/#Xue2021a

    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.


anadahz: 2022-01-27

    Last week:

    - Increase timeout check cycles for default-bridge-felix-1 and default-bridge-felix-2 as they have been generating too many alerts: https://gitlab.torproject.org/tpo/anti-censorship/monit-configuration/-/merge_requests/1


cecylia (cohosh): last updated 2022-03-03
Last week:
    - updated version of snowflake in Tor Browser to include logged events
        - https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40440
    - started work on conjure PT for Tor (conjure#1)
        - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure
    - reviewed and merged some small snowflake MRs
        - snowflake!79
        - snowflake!80
    - checked out shadow fixes for go programs
        - https://github.com/shadow/shadow/issues/1549
    - helped monitor snowflake broker stats
        - https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/000225.html
    - commented on adding more snowflake bridges (snowflake#28651)
This week:
    - continued work on conjure PT
    - continue to monitor snowflake broker stats
Needs help with:

dcf: 2022-03-03

    Last week:

    - posted summary of snowflake bridge outage on 2022-02-18 https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/000224.html

    - tried porting extor-static-cookie to rust https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/000226.html

    - tried the bridgedb+rdsys setup https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/000230.html

    - inquired with OTF about funding for the snowflake bridge

    - posted about hardware limitations at the snowflake bridge https://lists.torproject.org/pipermail/tor-project/2022-March/003301.html

    - posted notes on using STATUS for PT version reporting https://gitlab.torproject.org/tpo/core/tor/-/issues/11101#note_2781418

    - commented on space changes for STATUS VERSION https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/63

    Next week:

    Help with:


agix: 2021-02-10

    Last week:

    - Continued work on gettor-twitter

    Next week:

    - Hopefully finish the task

    Help with:

    -


arlolra: 2022-03-03

    Last week:

    - 

    Next week:

    - Figure out where in pion/webrtc ALPN should be configured and used

    - Maybe add Chacha20Poly1305 to pion/dtls

    https://github.com/pion/dtls#planned-features

    https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40014#note_2764731

    - Pass bridge fingerprint in SOCKS param to the broker

    Help with:

    - 


maxb: 2021-09-23

    Last week:

    - Worked on https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40054 re: utls for broker negotiation

    - Had conversation with someone about upstream utls http round tripper https://github.com/refraction-networking/utls/pull/74

    - Too busy with work :/

    Next week:

    - _Really_ want to get a PR for utls round tripper


meskio: 2022-03-03

    Last week:

    - deploy rdsys + bridgedb in production (rdsys#12)

    - update docker obfs4-bridge image with the new obfs4proxy (docker-obfs4-bridge#12)

    - coordinate with TPA to clean up the old email setup in BridgeDB

    - coordinate with metrics so the new assignments file

    - work on an update of the pt-spec to include the version on the STATUS message

    Next week:

    - use rdsys bridges in circumvention settings (bridgedb#40045)


Shelikhoo: 2022-03-03
   Last Week:
       - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64)
       - [Merge Request Awaiting] uTLS for broker negotiation

      - [Discussion] Proposal: Support for Dynamic IP obfs4 bridges with unattended proxy information update (aka "Subscription")

      - [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54)

   Next Week:
       - [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54)

HackerNCoder: 2021-12-16
This week:
    Last/done:
        Setup web mirror on tor.encryptionin.space
    Next:
        Get (new VPs with) new IP and setup new web mirror on new domain

hanneloresx: 2021-3-4

    Last week: 

    - Submitted MR for bridgestrap issue #14

    Next week:

    - Finish bridgestrap #14

    - Find new issue to work on

    Help with:

    - 




-- 
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/20220303/5e3c2338/attachment.sig>

More information about the tor-project mailing list