15:57:58 <shelikhoo> #startmeeting tor anti-censorship meeting
15:57:58 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:57:58 <shelikhoo> feel free to add what you've been working on and put items on the agenda
15:57:58 <MeetBot> Meeting started Thu Sep  1 15:57:58 2022 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:57:58 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:19 <shelikhoo> hi~
15:58:36 <meskio> hello
15:58:53 <shelikhoo> I think this meeting bot's time is out of sync...
15:58:59 <cohosh> hi
15:58:59 <anadahz> hi!
15:59:22 <meskio> 2mins :D
16:00:44 <itchyonion> hi
16:00:58 <dbarradas> hi all
16:01:08 <cohosh> dbarradas: welcome :)
16:01:29 <cohosh> here's the meeting pad with the agenda (since you joined after it was linked): https://pad.riseup.net/p/tor-anti-censorship-keep
16:01:51 <dbarradas> thanks!
16:05:12 <meskio> hello dbarradas
16:05:22 <fsilva> hey everyone!
16:05:38 <shelikhoo> hey~
16:06:14 <shelikhoo> okay, let's begin the meeting.
16:06:14 <shelikhoo> the first announcement is that
16:06:14 <shelikhoo> There will not be a meeting Sept 15th
16:06:53 <meskio> some of us will be meeting in person date date
16:07:59 <shelikhoo> yes, anything more on this topic?
16:08:16 <meskio> not from my side
16:08:40 <shelikhoo> The next topic will be:
16:08:40 <shelikhoo> Conjure PT ready to try out: https://lists.torproject.org/pipermail/anti-censorship-team/2022-August/000240.html
16:08:40 <shelikhoo> Congrats to cohosh!
16:09:00 <meskio> \o/
16:09:06 <meskio> amazing work
16:09:09 <cohosh> thanks :)
16:09:19 <anadahz> cohosh: Congrats!!!
16:09:24 <cohosh> it needs some work, but is ready for an initial testing phase
16:09:58 <itchyonion> awesome
16:10:12 <dbarradas> great work! :-)
16:12:09 <shelikhoo> anything more on this topic?
16:12:10 <cohosh> thanks! that's all from me on that, feel free to reach out with bugs/comments/questions
16:12:50 <shelikhoo> now is the discussion phase
16:12:57 <shelikhoo> a topic from last week
16:12:59 <shelikhoo> Snowflake in Turkmenistan: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40024
16:12:59 <shelikhoo> we are providing a different snowflake bridgeline with specific port for stun servers and azure and domain front
16:12:59 <shelikhoo> the changes seems to work for AGTS (one ISP) but not for others, as they block port 3478 and 3479
16:13:20 <meskio> we did deploy the changes last week
16:13:26 <shelikhoo> so we have tried to fix that, but there isn't a significant increase of user
16:13:29 <shelikhoo> I think....
16:13:36 <meskio> but I haven't seeing any increase on snowflake usage in metrics.tpo
16:13:46 <meskio> I see there are more and more obfs4 users
16:13:50 <meskio> also meek ones
16:14:16 <meskio> not sure if the fix is not working or just not so many people using directly connect assist
16:14:42 <meskio> ggus: do you have any reports of people in TM succesfully connecting using Connect Assist?
16:15:02 <cohosh> do we know how many large the user base is for Turkmentelecom vs AGTS?
16:15:21 <meskio> I have no idea
16:15:51 <cohosh> shelikhoo: i've been thinking about the comment you made regarding STUN servers
16:16:03 <cohosh> if one fails, does that mean everything fails?
16:16:19 <cohosh> i've been meaning to follow up with testing, but maybe you have already
16:16:20 <dcf1> if you want to run your own local analysis if the number of users in one country, you can start from these scripts for Russia: https://gitlab.torproject.org/tpo/community/support/-/issues/40050#note_2826459
16:17:35 <ggus> meskio: i'm going afk and nina is afk today too.
16:17:50 <shelikhoo> cohosh: Yes, I have tested that with wireshark and it send stun packet to all servers
16:17:55 <cohosh> shelikhoo: the comment was here: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40029#note_2831554
16:18:12 <shelikhoo> (or a lot of server)
16:18:12 <meskio> ggus: ok, thanks
16:18:27 <cohosh> shelikhoo: okay that was my assumption, but if one fails does it cause the snowflake client to give up? or is it sufficient for at least one to work?
16:18:56 <shelikhoo> no it will work if at least one of them is working
16:19:04 <cohosh> great, thanks!
16:19:25 <shelikhoo> The thing I am unsure is that whether snowflake select a subset of server and input that into WebRTC ICE
16:19:32 <shelikhoo> I didn't check that part
16:19:57 <cohosh> it does
16:20:21 * cohosh goes to find code line
16:21:09 <cohosh> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/client/lib/snowflake.go#L124
16:21:35 <cohosh> it randomizes it and then selects half of them (rounded up) as long as there are greater than 2 servers provided
16:22:35 <shelikhoo> yes, so it means if it is not working, then a random selection of half of them is not working
16:23:12 <cohosh> that's possible
16:24:05 <cohosh> we haven't tested IPv6 STUN servers
16:24:57 <shelikhoo> I have to say I don't think a lot of people in TM will have IPv6 connectivity
16:26:53 <cohosh> okay that's good to know
16:27:32 <shelikhoo> one of way we think we could get around this stun block is by avoiding TM's unidirectional block of connection
16:27:42 <shelikhoo> by forging UDP packets
16:28:28 <shelikhoo> if we already know client IP, in theory we could forge 65536 packet to make a IP fully accessible
16:29:23 <shelikhoo> according to the blocking rule shared by valdikss
16:30:14 <anadahz> According to RIPE stats 50% of networks in Turkmenistan have no IPv6 support -- https://ripeness.ripe.net/pies.html
16:31:45 <meskio> shelikhoo: the UDP fix would be very interesting to try out, will be nice to look into how much work it would require to implement
16:32:22 <shelikhoo> the first step would be getting a actual test environment...
16:32:33 <shelikhoo> which we don't have yet
16:33:20 <meskio> do you want to make a proposal about that? make an issue and some idea on how this would look like
16:33:28 <meskio> I mean the test environment
16:34:13 <shelikhoo> I mean a vantage point in TM
16:34:24 <meskio> ahh, ok
16:34:33 <meskio> yes, that would be pretty useful
16:34:48 <trinity-1686a> shlikhoo: probably half or a quarter of the work is enough, /proc/sys/net/ipv4/ip_local_port_range is 32768-60999 on my system, and on windows 10 `netsh int ipv4 show dynamicport udp` gives me 49152-65535
16:34:48 <meskio> I thought you were talking about some kind of staging/CI/...
16:35:38 <shelikhoo> trinity-1686a: yes....
16:35:59 <shelikhoo> but anyway this will be super interesting to bypass censorship with packet forging
16:36:17 <shelikhoo> yet, we need to have a vantage point first
16:36:39 <shelikhoo> anything more on this topic?
16:36:47 <meskio> not from me
16:37:29 <shelikhoo> TorCloak Integration with BridgeDB
16:37:29 <shelikhoo> We are currently developing a new Tor Pluggable Transport called TorCloak. TorCloak's basic mechanism is to conceale Tor traffic on the video streams of WebRTC-based video conferencing services.
16:37:29 <shelikhoo> We are now coming to a stage on our project in which we are discussing solutions to disseminate our bridges.
16:37:29 <shelikhoo> Sent a draft of the solution via the mailing list.
16:37:29 <shelikhoo> https://lists.torproject.org/pipermail/anti-censorship-team/2022-August/000239.html
16:37:30 <shelikhoo> Get everyone's opinion and feedback on the solution
16:38:38 <fsilva> Hey. Thank you for your time first of all.
16:38:55 <meskio> TorCloak looks pretty cool, I wanted to reply to the list but I haven't find the time for it
16:39:09 <fsilva> First we would just like to get some feedback from the team about our presented solution.
16:39:12 <fsilva> Thank you :)
16:40:00 <cohosh> do you have a link to the source code?
16:40:08 <meskio> I have some doubts if it makes sense to incorporate it to bridgedb, as it will be some work and TorCloak should not need the features that bridgedb provides (making hard for censors to list the bridges)
16:40:34 <meskio> I think it should use a similar system that snowflake does, having a broker that coordinates the connection between bridges and clients
16:41:40 <fsilva> Where can we find some details to the implementation of snowflakes broker?
16:42:04 <cohosh> fsilva: yeah, Conjure is another PT that doesn't use BridgeB, because the phantom IP addresses are too ephemeral and specific to the client
16:42:04 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tree/main/broker
16:42:23 <shelikhoo> This is the source of snowflake's broker
16:43:03 <fsilva> cohosh: about the source code, not yet, still in early development
16:43:15 <fsilva> so you think its easier to develop our broker instead of using BridgeDB for our purpose?
16:43:20 <meskio> I think it might make sense to set up an API over domain fronting for clients to get the rooms they should connect to
16:44:07 <meskio> I think your broker/API endpoint will be easier to implement and will let you test it without needing to coordinate with bridgedb
16:44:31 <dcf1> alternative model to consider: the client *tell* the server what room/password it intends to use, that way rendezvous can be one-way
16:45:04 <meskio> :)
16:45:36 <meskio> that might make possible to do it over dns or another slow transport, but as a first phase I think is easier to create an http API for it
16:45:46 <fsilva> dcf1: wouldn't that solution make it easier for a censor to identify this kind of communication?
16:45:51 <cohosh> this is how the tapdance registration of conjure works, you'll probably still need a broker/rendezvous point to get that info to the bridge(s)
16:46:21 <cohosh> i guess unless the bridge is the rendezvous point for itself
16:47:35 <fsilva> and using a broker such as snowflake does, does that introduce a single point of failure or blocking?
16:47:36 <dcf1> notes on rendezvous from the in-progress snowflake paper: https://github.com/turfed/snowflake-paper/blob/6489ffc97180bb74ff39f2dc4a37106aac534d2b/snowflake.tex#L180
16:48:09 <dcf1> fsilva: I don't see why a one-way rendezvous is more identifiable than a two-way rendezvous, maybe I don't understand you
16:48:18 <cohosh> fsilva: it does, but one thing to consider is that it doesn't require a large amount of data transfer
16:48:35 <meskio> fsilva: yes, the broker (like bridgedb) needs a channel to avoid censorship, like domain fronting or AMP cache
16:48:43 <cohosh> so things like domain fronting which aren't sustainable for proxying all traffic are an option
16:48:54 <dbarradas> Thanks for your suggestions. So in the model proposed by dcfl, one would tell the broker about a rendezvous chatroom ID, and the broker would instruct a bridge to use that particular (and ideally ephemeral) chatroom ID, correct?
16:48:54 <meskio> but that is "easy"to plug on an http API
16:49:27 <dcf1> either you connect to something and send, or connect to something and receive, or connect to something and send+recv. but don't get hung up on that point, it's not really material I think.
16:51:05 <fsilva> ok, this seems like a good idea, using a similar method to snowflake.
16:51:19 <meskio> :)
16:51:51 <fsilva> we will look into it, thank you everyone for the help!
16:52:03 <shelikhoo> Yes! anything more on this topic?
16:52:13 <shelikhoo> Next Step for WebTunnel
16:52:13 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/tree/7e7bebb499a46345b9adf030666698427965e953
16:52:31 <shelikhoo> WebTunnel(aka HTTPT) is now in MVP
16:52:43 <meskio> congrats \o\
16:52:46 <meskio> /o/
16:52:49 <cohosh> shelikhoo: nice!
16:52:50 <shelikhoo> yes!
16:52:52 <meskio> so many new PTs
16:53:07 <meskio> is 2022 the year of the anti-censorship?
16:53:21 <itchyonion> great work!
16:53:56 <shelikhoo> anyway, it still need a lot of work(see issues) to get into tor browser and rdsys
16:54:02 <meskio> I have reviewed the code and is pretty small, so cool :)
16:54:20 <anadahz> shelikhoo: Congrats!!
16:54:25 <shelikhoo> thanks!
16:54:53 <shelikhoo> the code could be larger as we support more things like
16:54:54 <anadahz> fsilva, dbarradas Congrats for your great work!
16:54:58 <shelikhoo> utls
16:55:18 <shelikhoo> or early data
16:55:19 <fsilva> anadahz: thank you!
16:55:37 <shelikhoo> or additional tor integration
16:55:42 <dbarradas> Another cool nugget, shelikhoo! Very nice!
16:55:53 <shelikhoo> yes! thanks!
16:56:38 <shelikhoo> It is actually from HTTPT paper here; https://censorbib.nymity.ch/#Frolov2020b
16:56:57 <dbarradas> yep yep, rings a bell :)
16:57:00 <shelikhoo> and the version just working is its tor pt integration
16:57:53 <shelikhoo> (the demo server shown in README is temporary)
16:58:07 <shelikhoo> anything more on this topic?
16:58:12 <fsilva> very nice shelikhoo, congrats!
16:58:30 <shelikhoo> fsilva: yes, thanks! congrats on your work as well!
16:59:44 <shelikhoo> okay, anything else we wants to discuss in this meeting?
17:00:01 <cohosh> we have a reading group next meeting, right?
17:00:06 <shelikhoo> yes!
17:00:37 <meskio> dbarradas, fsilva: keep us updated on the adavance on TorCloak, specially when you release the code
17:00:54 <fsilva> meskio: will do, thank you all!
17:01:00 <meskio> what do you use for webrtc? an actual browser? or some standalone library like pion?
17:01:22 <fsilva> we use a modified instance of chromium
17:01:31 <dbarradas> certainly. we'll also reach out for additional clarifications in the close future
17:01:35 <meskio> nice
17:02:11 <dbarradas> it turns out that getting a chromium distribution is some countries (say China) is not trivial, though
17:02:34 <meskio> yep
17:03:01 <dbarradas> the usual repositories are blocked as well, so we ought to do something better there in the future
17:03:40 <shelikhoo> the linux repo is actually fully accessible in china
17:03:43 <shelikhoo> like arch
17:03:52 <shelikhoo> actually hosts v2ray's binary inside china
17:03:55 <shelikhoo> without issue
17:04:19 <dbarradas> do you know whether pion supports video streaming? (or if headless video streaming could be a thing for a typical WebRTC video client?)
17:04:45 <shelikhoo> while when we(V2Ray) try to host it on cdnjs, they specifically blocked v2ray
17:05:07 <dbarradas> ah, that's very interesting
17:06:00 <dbarradas> did you reach out to, say, arch in some way? to get v2ray hosted inside china?
17:06:02 <meskio> I would expect that you need some video library to do video over pion, but I don't know much the details
17:06:47 <shelikhoo> dbarradas: it is a software package you can get with pacman.
17:07:13 <shelikhoo> so it is not like we reached to them, it is just how linux distribution works
17:07:28 <meskio> there are some pion examples sending video: https://github.com/pion/webrtc/blob/v1.1.1/examples/README.md
17:07:45 <dbarradas> pardon for my ignorance here, but so, as long as arch supports your package, then it does not get blocked in china?
17:08:08 <meskio> but pion is blocked by fingerprint in some places, we've being trying to improve that
17:08:22 <shelikhoo> china didn't contact arch to remove v2ray's package
17:08:30 <shelikhoo> the same is probable true for debian
17:08:35 <shelikhoo> and other linux distributions
17:08:45 <dbarradas> right, got it
17:09:28 <shelikhoo> okay, anything more we wish to discuss in this meeting?
17:09:28 <dbarradas> had no idea this was going on, thanks!
17:09:39 <meskio> EOF
17:09:49 <anadahz> Though they could block downloading a specific package if for instance the package manager uses HTTP (was the case in Debian)
17:10:19 <anadahz> Fortinet DPI has this capability ^
17:10:29 <shelikhoo> if that mirror is inside china then probably it does not pass GFW
17:11:38 <anadahz> ah yes that makes sense, local mirrors should not be affected
17:11:39 <shelikhoo> so GFW's DPI won't work
17:12:02 <dbarradas> I see, clever :)
17:12:47 <shelikhoo> but typically if you host something they don't like inside China, they will call operator in midnight to get it removed in 15 minutes
17:13:12 <shelikhoo> a call from an anonymous official
17:13:24 <shelikhoo> (may call in midnight)
17:13:43 <shelikhoo> okay, anything more we wants to discuss in this meeting?\
17:14:24 <shelikhoo> #endmeeting