15:59:25 <meskio> #startmeeting tor anti-censorship meeting
15:59:25 <MeetBot> Meeting started Thu Apr 21 15:59:25 2022 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:25 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:28 <meskio> hello
15:59:30 <shelikhoo> Hi~
15:59:34 <itchyonion> hello
15:59:37 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:59:45 <meskio> feel free to add what you've been working on and put items on the agenda
15:59:49 <arma2> dcf1: oh, i realized i had another question: i'm told that our telegram-distributed obfs4 bridges are wildly successful,
15:59:59 <arma2> and do we have any relay-search style graphs of what 'successful' means there?
16:00:10 <arma2> like, are most of the .ru users using those telegram obfs4 bridges? or?
16:00:28 <arma2> i tried looking up previous ones but irl had rotated them and relay-search had dropped their page
16:00:52 <arma2> (might be a question better for meskio)
16:01:21 <dcf1> I don't think relay search gives a per-country breakdown for each bridge, but the information is there in the bridge-extra-info descriptors
16:01:34 <arma2> right. i just figured, if they're telegram-distributed, most of their users are from .ru,
16:01:35 <meskio> we have some graphs in grafana about the bot requests
16:01:44 <irl> i have a script that was pulling out that per-country info
16:01:44 <arma2> and if they're wildly popular, then i should be able to find a relay-search graph with big numbers on it
16:01:52 <meskio> we can look in relay-search, as all the telegram bridges right now have the same name patter
16:01:57 <meskio> s/patter/pattern/
16:02:07 <meskio> ahh, irl scripts are better :)
16:02:24 <arma2> great. what do we mean by wildly popular? 100 users? 1000?
16:02:29 <irl> it was just a for loop over bridge extra info descriptors
16:02:32 <dcf1> https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40047#note_2796619 scripts have an example of extracting info for a single fingerprint, and
16:02:44 <shelikhoo> I think there isn't a lot of blocking of dynamic s96 bridges in russia right not...
16:02:53 <dcf1> https://gitlab.torproject.org/tpo/community/support/-/issues/40050#note_2796770 has an example of pulling info for a single fingerprint and a single country
16:02:53 <shelikhoo> I  think there isn't a lot of blocking of dynamic s96 bridges in russia right now
16:02:55 <irl> tens of thousands of "unique russian ip address days"
16:02:59 <meskio> arma2: until we do deploy telegram as part of rdsys bridges used by telegram are not assigned to the distribution mechanism 'telegram', so they don't appear in the graphs as so
16:03:26 <irl> i think it was roughly 700-1000 daily unique russian ip addresses
16:04:04 <irl> shelikhoo: you're currently only testing the moat bridges, the telegram bridges haven't been updated in a while now
16:05:09 <shelikhoo> I assume the telegram bridges will come from the shared repo?
16:05:31 <arma2> ok i will follow up after the meeting for more details. no need for me to derail :)
16:06:15 <shelikhoo> other bridges are static and updated manually
16:06:49 <shelikhoo> to get a bridge tested, send bridge line to the repo
16:07:44 <meskio> should we move on to the next topic?
16:07:52 <meskio> Is the reading group reading supposed to be "Web censorship measurements of HTTP/3 over QUIC"
16:08:05 <meskio> I miss last weeks conversations and I guess the context on it
16:08:15 <dcf1> I'm just curious if we're supposed to read the BBS and NTC threads, or the IMC paper about HTTP/3 blocking
16:08:23 <dcf1> (which precedes the blocking of HTTP/3 in Russia)
16:09:42 <dcf1> The paper is linked in the BBS thread (it's an IMC short paper)
16:10:08 <meskio> I will assume is the paper, isn't it?
16:10:08 <dcf1> One of the authors of the paper, I saw, has done some Russia-specific tests since then: https://github.com/kelmenhorst/quic-censorship/issues/4
16:11:16 <dcf1> the IMC paper is what I would have guessed
16:12:40 <meskio> let's do the paper, I guess the BBS thread is good source as context
16:13:00 <dcf1> ok
16:13:14 <shelikhoo> Yes~
16:13:26 <meskio> great, let's move on
16:13:31 <meskio> Snowflake Multi-Server Broker Testing
16:13:49 <meskio> shelikhoo: is it yours?
16:14:10 <shelikhoo> Yes. I have deployed Multi-Server Broker and it is ready for testing
16:14:41 <shelikhoo> there are 3 bridge known to it
16:15:06 <shelikhoo> and we can just compile and run the client with one of the fingerprint
16:15:13 <shelikhoo> to try this
16:15:15 <meskio> I see the ticket has instructions on how to test it, I'll give it a try tomorrow
16:15:20 <shelikhoo> yes!
16:15:29 <dcf1> shelikhoo: does it work if I configure 2 bridges in torrc at the same time?
16:15:35 <meskio> thanks for setting it up, is nice to see this advancing :)
16:15:42 <dcf1> I know it will do duplicate rendezvous, but does it work?
16:16:11 <shelikhoo> it should work in theory, please let me know if doesn't
16:16:32 <dcf1> ok, good
16:16:49 <dcf1> good work
16:17:31 <shelikhoo> meskio: I am afraid I am behind the Q2 OKR already.... hahahaha ( T_T )
16:18:02 <shelikhoo> yes, it still don't have user friendly message for new errors, but it should not be hard to add it
16:18:10 <meskio> uff, is hard to keep up with them
16:18:33 <shelikhoo> dcf1: Yes! Thanks!
16:18:45 <shelikhoo> If there is anything unexpected just let me know!
16:19:37 <itchyonion> I will also help test
16:20:30 <shelikhoo> The url used cloudflare worker to hide actual server IP address(or client address for attackers that know server IP), this will also be used for our vantage point - probe log collector connections
16:21:01 <shelikhoo> so that even if attacker know the server ip, they can't use it to get vantage ip
16:21:14 <shelikhoo> by looking who is connecting to that ip
16:21:54 <shelikhoo> I am also testing this in the same time
16:22:38 <meskio> I'm a bit confused the broker uses cloudflare?
16:23:03 <shelikhoo> cloudflare worker forward connection to the actual broker
16:23:22 <meskio> I see
16:23:23 <shelikhoo> for testing using cloudflare to forward connections
16:23:33 <shelikhoo> with worker
16:23:47 <meskio> you meant it as a circumvention mechanism? like domain fronting and so?
16:24:21 <meskio> ahh, is just to hide the IP where you are hosting it
16:25:03 <shelikhoo> the actual usage is to hide the vantage client that are connecting to log collector
16:25:29 <shelikhoo> since censor have no idea which worker is our's
16:25:42 <shelikhoo> but right now it is hiding server ip
16:26:01 <meskio> I see
16:26:31 <meskio> should we move to the next topic?
16:26:48 <meskio> Report of CDN Block in Turkmenistan
16:27:21 <shelikhoo> Yes, i have received a report that Turkmenistan are blocking IP associated with Cloudflare
16:27:37 <shelikhoo> and currently trying to confirm this
16:28:15 <arma2> i sent you some contacts we have at cloudflare / fastly
16:28:20 <shelikhoo> if fastly are blocked in a similar way, this might explain snowflake failure in the region
16:28:21 <arma2> let me know if i should do more there, e.g. send an introduction
16:29:07 <shelikhoo> thanks arma2, I will write to them to know if they are willing to share info about this.
16:29:15 <dcf1> RU (TSPU) was/is also blocking a couple of Cloudflare IP addresses in the past week: https://ntc.party/t/cloudflare-cdn/2245
16:29:49 <dcf1> The best guess as to the cause is accidental overblocking when trying to block a specific site: https://ntc.party/t/cloudflare-cdn/2245/24
16:31:13 <shelikhoo> from the screenshot, the blocking is quite extensive, so it is likely about blocking CDN as a whole...
16:31:14 <arma2> that guess is consistent with what we saw with blocking azure by ip address
16:31:38 <arma2> russia choosing to block cloudflare longterm would be... a huge step.
16:31:48 <dcf1> no, you are misunderstanding me
16:32:04 <arma2> (and i assume cloudflare would take steps to 'fix' it, socially or otherwise)
16:32:19 <dcf1> it does not look like a deliberate block of all of cloudflare, rather more like someone was lazy and blocked the 2 IP addresses a domain name happened to resolve to at the time
16:32:37 <dcf1> it is unlike what shelikhoo is describing in TM, I think
16:32:40 <shelikhoo> dcf1; i was talking about Turkmenistan situation, not russia
16:32:59 <dcf1> shelikhoo: aha, sorry for the confusion
16:33:05 <arma2> ok great. yes, i agree that russia probably did not mean to block cloudflare, and they wouldn't keep it up if they accidentally did.
16:33:15 <arma2> but it is intriguing that maybe .tm did.
16:33:24 <shelikhoo> I just said the thing in TM is could be more harsh...
16:33:47 <shelikhoo> in the meanwhile we should consider invest in a vantage point in TM if possible
16:34:00 <shelikhoo> and understand whether AMP works there
16:34:38 <meskio> shelikhoo: I agree, we should search for a vantage point in TM, we should check with gaba, but I doubt the money will be the issue for it
16:35:10 <anadahz> According to OONI data this is not something so new as it seems snowflake is being blocked since at least March 2022: https://explorer.ooni.org/chart/mat?probe_cc=TM&test_name=torsf&since=2022-03-01&until=2022-04-22&axis_x=measurement_start_day
16:35:26 <dcf1> regarding idle scan, that is basically what Censored Planet "Augur" is, an enhanced form of idle scan. it's possible Censored Planet data may have the necessary measurements.
16:35:46 <dcf1> https://censorbib.nymity.ch/#Pearce2017a
16:37:39 <anadahz> Many operators do not allow sending spoofed packets.
16:37:40 <shelikhoo> Yes... I will contact Cloudflare & fastly first since they will have more direct data
16:37:53 <dcf1> Hmm, although from https://data.censoredplanet.org/raw that may not be doing active Augur measurements lately
16:40:02 <shelikhoo> Anyway, the wishlist will be assistance from cf, fastly; vantage point in TM; and some idle scan if possible
16:40:25 <shelikhoo> sending spoofed packet would require special network access
16:40:53 <meskio> sounds great
16:40:59 <shelikhoo> yes
16:41:13 <dcf1> Augur is remote measurement. You don't spoof from a vantage point in the country. You spoof from outside, on a network that allows it. It doesn't matter whether the target allows spoofing.
16:41:30 <shelikhoo> Yes, the source need to allow spoofing
16:42:25 <meskio> anything else on this topic?
16:43:21 <meskio> the next topic is about adding a license to rdsys, it doesn't have one
16:43:57 <meskio> do we have a standard license in other tpo projects? I see bridgedb and tor ar 3-BSD, arti is unclear if is MIT
16:44:07 <arma2> most things are 3-bsd
16:44:09 <meskio> I don't have strong opinions on it
16:44:21 <arma2> doing what bridgedb did can't go too far wrong
16:44:42 <meskio> sounds good, I'll do that in the comming days
16:44:43 <arma2> mostly i wanted us to have *something*, since the defcon proposal quite reasonably asks "is it free software" and i was like "oh wait it isn't"
16:44:52 <meskio> :D
16:45:38 <meskio> last point in the agenda: dnstt, next steps
16:45:44 <meskio> anadahz?
16:46:16 <anadahz> Not sure if you have the chance to check: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/40001
16:47:01 <anadahz> Some weeks ago it was suggested that this is the first part to get things done.
16:47:51 <anadahz> threeletteracronym[m]: has already implemented in Orbot and can release once we have some public bridges.
16:48:24 <anadahz> Anything more I can do from my side?
16:48:28 <meskio> to me the next step is to add support to the PT spec in dnstt, AFAIK it doesn't understand commands over the SOCKS connection, isn't it?
16:48:45 <dcf1> that's correct, the program is not a pluggable transport
16:49:26 <meskio> dcf1: is that something you are willing to accept as a contribution in the current code?
16:49:30 <dcf1> you should feel free to fork it to make a PT-capable version
16:49:38 <dcf1> I don't think I want PT support in the main code
16:49:40 <anadahz> dcf1: What is needed for this to happen, is there a TODO/issue about it?
16:50:47 <meskio> ok, so I guess we should fork it in gitlab.tpo, and we'll need someone that has the time to implement it
16:51:26 <meskio> anadahz: there is point about it in the TODO list of the issue you linked
16:51:40 <meskio> but I don't know about any other issues about it
16:52:05 <dcf1> there are skeletons of PT applications at https://gitweb.torproject.org/pluggable-transports/goptlib.git/tree/examples to use as examples
16:52:41 <dcf1> anadahz: is the orbot team wanting multiple public bridges? why does there have to be more than one bridge?
16:53:07 <anadahz> dcf1: for redundancy/backup
16:53:15 <dcf1> ok
16:54:33 <anadahz> ggus  mentioned last time that we could to relay operators once we have something alpha.
16:57:01 <meskio> so if someone contributes the code to make it a PT I'm happy to review it, otherwise we'll try to add it to the anti-censorship team roadmap, but we are pretty full for the next few months
16:57:23 <anadahz> great
16:57:57 <meskio> thanks for poking back about and sorry if is moving slowly
16:58:11 <meskio> is almost one hour of meeting
16:58:12 <shelikhoo> Speaking of PT... I think PT only support per connection argument of 256 chars, is that correct?
16:58:35 <dcf1> shelikhoo: that's correct. I think it is different in PT 2.0 and 3.0.
16:59:27 <itchyonion> gotta jump to another meeting
16:59:42 <meskio> bye itchyonion
16:59:42 <shelikhoo> Yes. So it would be difficult to get an entire V2Ray configure file into it.... this is just a random thought, don't worry too much about this...
16:59:49 <shelikhoo> bye itchyonion
16:59:55 <itchyonion> bye guys
17:00:23 <meskio> shelikhoo: maybe you could pass a path to the file or split it into different pieces
17:01:07 <shelikhoo> yes, but that won't work well with tor browser. I don't think tor browser expects something like that
17:01:16 <dcf1> there is an ancient ticket: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10671
17:02:49 <meskio> anything else for today?
17:02:57 <shelikhoo> thanks dcf1~
17:04:01 <meskio> #endmeeting