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

Hey everyone!

Here are our meeting logs:

ttp://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-02-17-15.59.html

And our meeting pad:

Anti-censorship work meeting pad

···

--------------------------------

Next meeting: Thursday February 17th 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: 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 30

    Sponsor 30 - Objective 2.1 · The Tor Project · GitLab

    Sponsor 30 - Objective 2.2 · The Tor Project · GitLab

    Sponsor 30 - Objective 2.3 · The Tor Project · GitLab

    Sponsor 30 - Objective 2.4 · The Tor Project · GitLab

    Sponsor 28

    must-do tickets: Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR) · The Tor Project · GitLab

    possible tickets: Issues · The Tor Project · GitLab

== Announcements ==

== Discussion ==

    obfs4proxy-0.0.12 causing connection failure warnings, before eventually succeeding

    Proxy Client: unable to connect OR connection | warings when starting with bridges (#40804) · Issues · The Tor Project / Applications / Tor Browser · GitLab

    It looks like an obfs4proxy-0.0.12 client connecting to a pre-0.0.12 server fails to connect some fixed fraction of the time, requiring multiple connection attempts before finally succeeding

    The Elligator2 fix in obfs4proxy-0.0.12 is documented to be backward compatible, but perhaps it is not fully

    internal/README.md · 77af0cba934d73c4baeb709560bcfc9a9fbc661c · Yawning Angel / obfs4 · GitLab

    "Representatives created by this implementation will correctly be decoded by existing implementations." "As the representative to public key transform should be identical, this change is fully-backward compatible"

    It could be that something about the altered (fixed) mathematical transform of Elligator2 is responsible for the handshake failures. Posts about Elligator2 and the cofactor distinguishability bug:

    Surrounded by Elligators: Implementing Crypto With Nothing to Compare to.

    Cofactor Explained: Clearing Elliptic Curves' dirty little secret

    https://www.reddit.com/r/crypto/comments/fd9t3m/elligator_with_x25519_is_broken_what_workaround/

    Aaron Johnson has looked into it, and says (according to immediate memory) that the Elligator2-encoded public keys of past versions of obfs4proxy are distinguishable from random in 7/8 cases. When both side have not upgraded, it is 63/64 cases. Or something along those lines.

    Roger will put us in touch with Aaron to understand the encoding bug and whether it could be leading to the connection failures.

    Shall we roll back the obfs4proxy version in Tor Browser until we figure it out?

    It seems to be a small number of users who are bothered enough by the log messages to post on #40804 and on the forum Bridges work but with error messages in log / TB 11.0.6 / Linux

    No rollback for now.

    We need to test a 0.0.12-to-0.0.12 connection, to see whether upgrading the server solves the connection failures. If it does, then (separately from fixing the problem in the client) we can push for server operators to upgrade.

    obfs4proxy-0.0.13 is already in Debian sid, it will take some time to work its way into testing and backports

    A non-upgraded server is detectable (with 7/8 probability) at the client. We could have the client log a message when that occurs, so the user can choose to use a different bridge, or encourage the bridge operator to upgrade.

    Tails's test suite caught the connection errors: Proxy Client: unable to connect OR connection | warings when starting with bridges (#40804) · Issues · The Tor Project / Applications / Tor Browser · GitLab

    uTLS for broker negotiation. Should we enable by default?

    the fingerprints in uTLS are pretty old, is it better to use them than go TLS?

    we are reachinging out to psiphon to see what they thing about uTLS maintenance

    V2 uses a "bring your own browser" model: the proxy forwards through a browser installed on the system to get a good TLS fingerprint.

    meek in Tor Browser used to do something similar, using the Firefox that is part of the bundle. Later meek got support for uTLS: uTLS for meek-client camouflage (#29077) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / meek · GitLab

    obfs4proxy's meek_lite implementation also got uTLS support, and the Tor Browser maintainers decided to switch to that (from mainline meek with browser forwarding) so that there would be only one binary to ship: Use uTLS for meek TLS camouflage in Tor Browser (#29430) · Issues · The Tor Project / Applications / Tor Browser · GitLab

== Actions ==

== Interesting links ==

== Reading group ==

    We will discuss "Weaponizing Middleboxes for TCP Reflected Amplification" on 2022-02-17

    The Internet censorship bibliography

    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: Increase number of cycles for felix bridges (!1) · Merge requests · The Tor Project / Anti-censorship / monit-configuration · GitLab

cecylia (cohosh): last updated 2022-02-17
Last week:
    - tried out snowflake experiments in shadow's preload mode
        - golang managed processes abort in preload mode · Issue #1549 · shadow/shadow · GitHub
    - deployed snowflake server fixes
    - reached out to default bridge operators
    - finished s28 prep and documentation
    - wrote some follow up code for Snowflake event channel
        - Add connection failure events for proxy timeouts (!77) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
This week:
    - mostly afk
Needs help with:

dcf: 2022-02-17

    Last week:

    - opened issues for some default obfs4 bridges being offline (smallerRichard) smallerRichard's obfs4 port is closed (#44) · Issues · The Tor Project / Anti-censorship / Team · GitLab (KauBridge{Pale,Blue,Dot}) KauBridge{Pale,Blue,Dot} default obfs4 bridges are offline since 2022-01-29 (#64) · Issues · The Tor Project / Anti-censorship / Team · GitLab

    - investigated "general SOCKS server failure" errors from obfs4proxy-0.0.12 Proxy Client: unable to connect OR connection | warings when starting with bridges (#40804) · Issues · The Tor Project / Applications / Tor Browser · GitLab

    - did some review of uTLS for snowflake-client Draft: uTLS Round-Tripper for Snowflake Client (!76) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab

    - posted snowflake bridge VPS cost estimates [anti-censorship-team] Snowflake bridge VPS cost estimates

    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-01-20

    Last week:

    - [added 2022-01-20 by dcf] ALPN support for pion DTLS Implement rfc7301 by arlolra · Pull Request #415 · pion/dtls · GitHub

    Next week:

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

    - Maybe add Chacha20Poly1305 to pion/dtls

    GitHub - pion/dtls: DTLS 1.2 Server/Client implementation for Go

    Make Snowflake's DTLS fingerprint more similar to popular WebRTC implementations (#40014) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab

    Help with:

    -

maxb: 2021-09-23

    Last week:

    - Worked on uTLS for broker negotiation (#40054) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab re: utls for broker negotiation

    - Had conversation with someone about upstream utls http round tripper feat: sketch out utls http.RoundTripper by bassosimone · Pull Request #74 · refraction-networking/utls · GitHub

    - Too busy with work :confused:

    Next week:

    - _Really_ want to get a PR for utls round tripper

meskio: 2022-02-17

    Last week:

    - make easier to test bridgedb after rdsys change (bridgedb#40034)

    - bridgedb reconnection issues with rdsys (bridgedb!34)

    - bridgestrap is not displaying the results (bridgestrap#31)

    - staging bridgedb configuration (bridgedb-admin!4)

    - remove bridgedb blockade to distribute bridges in certain contries (rdsys#89)

    - review snowflake uTLS roundtripper (snowflake!76)

    Next week:

    - circumvention settings fallback (bridgedb#40045)

Shelikhoo: 2022-02-17
   Last Week:
       - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64)
       - [Merge Request Done] Add verbosity switch to suppress diagnostic output (snowflake#40079, snowflake!74)
       - [Merge Request] uTLS for broker negotiation

      - [Discussion] Implement metrics to measure snowflake churn (snowflake#34075)

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

      - [Discussion] Proposal: Push Notification Based Signaling Channel

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

      - [Discussion] HTTPT & Websocket (O1.3: Implement bridges with pluggable transport HTTPT support. (#7) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / HTTPT · GitLab)

      - [Investigate] Is there a better moat/snowflake SNI than cdn.sstatic.net? (snowflake#40068)

      - [Investigate] Multi-instance Load Balanced Tor - Snowflake Deployment

      - [Investigate] China "Anti-Fraud" Webpage Redirection Censorship (censorship-analysis#40026)

      - [Investigate] S96 Bridge Performance

   Next Week:
       - [Discussion] Implement metrics to measure snowflake churn (snowflake#34075)
       - [Discussion] Proposal: Push Notification Based Signaling Channel
       - [Coding] uTLS for broker negotiation
       - [Coding] 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.