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

Thu Feb 17 17:17:13 UTC 2022

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

== Discussion ==

    obfs4proxy-0.0.12 causing connection failure warnings, before eventually succeeding

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

    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

    https://gitlab.com/yawning/obfs4/-/blob/77af0cba934d73c4baeb709560bcfc9a9fbc661c/internal/README.md

    "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:

    https://loup-vaillant.fr/articles/implementing-elligator

    https://loup-vaillant.fr/tutorials/cofactor

    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 https://forum.torproject.net/t/bridges-work-but-with-error-messages-in-log-tb-11-0-6-linux/2112

    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: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804#note_2778826

    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: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/29077

    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: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29430

== Actions ==

== Interesting links ==

== Reading group ==

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

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

    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-02-17
Last week:
    - tried out snowflake experiments in shadow's preload mode
        - https://github.com/shadow/shadow/issues/1549
    - deployed snowflake server fixes
    - reached out to default bridge operators
    - finished s28 prep and documentation
    - wrote some follow up code for Snowflake event channel
        - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/77
This week:
    - mostly afk
Needs help with:

dcf: 2022-02-17

    Last week:

    - opened issues for some default obfs4 bridges being offline (smallerRichard) https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/44#note_2777044 (KauBridge{Pale,Blue,Dot}) https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/64

    - investigated "general SOCKS server failure" errors from obfs4proxy-0.0.12 https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804#note_2777135

    - did some review of uTLS for snowflake-client https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/76

    - posted snowflake bridge VPS cost estimates https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/000219.html

    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 https://github.com/pion/dtls/pull/415

    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

    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-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 (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/httpt/-/issues/7#note_2773546)

      - [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.
-------------- 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/20220217/30ffd718/attachment.sig>