15:59:25 #startmeeting tor anti-censorship meeting 15:59:25 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:28 hello 15:59:30 Hi~ 15:59:34 hello 15:59:37 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:45 feel free to add what you've been working on and put items on the agenda 15:59:49 dcf1: oh, i realized i had another question: i'm told that our telegram-distributed obfs4 bridges are wildly successful, 15:59:59 and do we have any relay-search style graphs of what 'successful' means there? 16:00:10 like, are most of the .ru users using those telegram obfs4 bridges? or? 16:00:28 i tried looking up previous ones but irl had rotated them and relay-search had dropped their page 16:00:52 (might be a question better for meskio) 16:01:21 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 right. i just figured, if they're telegram-distributed, most of their users are from .ru, 16:01:35 we have some graphs in grafana about the bot requests 16:01:44 i have a script that was pulling out that per-country info 16:01:44 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 we can look in relay-search, as all the telegram bridges right now have the same name patter 16:01:57 s/patter/pattern/ 16:02:07 ahh, irl scripts are better :) 16:02:24 great. what do we mean by wildly popular? 100 users? 1000? 16:02:29 it was just a for loop over bridge extra info descriptors 16:02:32 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 I think there isn't a lot of blocking of dynamic s96 bridges in russia right not... 16:02:53 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 I think there isn't a lot of blocking of dynamic s96 bridges in russia right now 16:02:55 tens of thousands of "unique russian ip address days" 16:02:59 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 i think it was roughly 700-1000 daily unique russian ip addresses 16:04:04 shelikhoo: you're currently only testing the moat bridges, the telegram bridges haven't been updated in a while now 16:05:09 I assume the telegram bridges will come from the shared repo? 16:05:31 ok i will follow up after the meeting for more details. no need for me to derail :) 16:06:15 other bridges are static and updated manually 16:06:49 to get a bridge tested, send bridge line to the repo 16:07:44 should we move on to the next topic? 16:07:52 Is the reading group reading supposed to be "Web censorship measurements of HTTP/3 over QUIC" 16:08:05 I miss last weeks conversations and I guess the context on it 16:08:15 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 (which precedes the blocking of HTTP/3 in Russia) 16:09:42 The paper is linked in the BBS thread (it's an IMC short paper) 16:10:08 I will assume is the paper, isn't it? 16:10:08 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 the IMC paper is what I would have guessed 16:12:40 let's do the paper, I guess the BBS thread is good source as context 16:13:00 ok 16:13:14 Yes~ 16:13:26 great, let's move on 16:13:31 Snowflake Multi-Server Broker Testing 16:13:49 shelikhoo: is it yours? 16:14:10 Yes. I have deployed Multi-Server Broker and it is ready for testing 16:14:41 there are 3 bridge known to it 16:15:06 and we can just compile and run the client with one of the fingerprint 16:15:13 to try this 16:15:15 I see the ticket has instructions on how to test it, I'll give it a try tomorrow 16:15:20 yes! 16:15:29 shelikhoo: does it work if I configure 2 bridges in torrc at the same time? 16:15:35 thanks for setting it up, is nice to see this advancing :) 16:15:42 I know it will do duplicate rendezvous, but does it work? 16:16:11 it should work in theory, please let me know if doesn't 16:16:32 ok, good 16:16:49 good work 16:17:31 meskio: I am afraid I am behind the Q2 OKR already.... hahahaha ( T_T ) 16:18:02 yes, it still don't have user friendly message for new errors, but it should not be hard to add it 16:18:10 uff, is hard to keep up with them 16:18:33 dcf1: Yes! Thanks! 16:18:45 If there is anything unexpected just let me know! 16:19:37 I will also help test 16:20:30 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 so that even if attacker know the server ip, they can't use it to get vantage ip 16:21:14 by looking who is connecting to that ip 16:21:54 I am also testing this in the same time 16:22:38 I'm a bit confused the broker uses cloudflare? 16:23:03 cloudflare worker forward connection to the actual broker 16:23:22 I see 16:23:23 for testing using cloudflare to forward connections 16:23:33 with worker 16:23:47 you meant it as a circumvention mechanism? like domain fronting and so? 16:24:21 ahh, is just to hide the IP where you are hosting it 16:25:03 the actual usage is to hide the vantage client that are connecting to log collector 16:25:29 since censor have no idea which worker is our's 16:25:42 but right now it is hiding server ip 16:26:01 I see 16:26:31 should we move to the next topic? 16:26:48 Report of CDN Block in Turkmenistan 16:27:21 Yes, i have received a report that Turkmenistan are blocking IP associated with Cloudflare 16:27:37 and currently trying to confirm this 16:28:15 i sent you some contacts we have at cloudflare / fastly 16:28:20 if fastly are blocked in a similar way, this might explain snowflake failure in the region 16:28:21 let me know if i should do more there, e.g. send an introduction 16:29:07 thanks arma2, I will write to them to know if they are willing to share info about this. 16:29:15 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 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 from the screenshot, the blocking is quite extensive, so it is likely about blocking CDN as a whole... 16:31:14 that guess is consistent with what we saw with blocking azure by ip address 16:31:38 russia choosing to block cloudflare longterm would be... a huge step. 16:31:48 no, you are misunderstanding me 16:32:04 (and i assume cloudflare would take steps to 'fix' it, socially or otherwise) 16:32:19 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 it is unlike what shelikhoo is describing in TM, I think 16:32:40 dcf1; i was talking about Turkmenistan situation, not russia 16:32:59 shelikhoo: aha, sorry for the confusion 16:33:05 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 but it is intriguing that maybe .tm did. 16:33:24 I just said the thing in TM is could be more harsh... 16:33:47 in the meanwhile we should consider invest in a vantage point in TM if possible 16:34:00 and understand whether AMP works there 16:34:38 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 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 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 https://censorbib.nymity.ch/#Pearce2017a 16:37:39 Many operators do not allow sending spoofed packets. 16:37:40 Yes... I will contact Cloudflare & fastly first since they will have more direct data 16:37:53 Hmm, although from https://data.censoredplanet.org/raw that may not be doing active Augur measurements lately 16:40:02 Anyway, the wishlist will be assistance from cf, fastly; vantage point in TM; and some idle scan if possible 16:40:25 sending spoofed packet would require special network access 16:40:53 sounds great 16:40:59 yes 16:41:13 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 Yes, the source need to allow spoofing 16:42:25 anything else on this topic? 16:43:21 the next topic is about adding a license to rdsys, it doesn't have one 16:43:57 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 most things are 3-bsd 16:44:09 I don't have strong opinions on it 16:44:21 doing what bridgedb did can't go too far wrong 16:44:42 sounds good, I'll do that in the comming days 16:44:43 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 :D 16:45:38 last point in the agenda: dnstt, next steps 16:45:44 anadahz? 16:46:16 Not sure if you have the chance to check: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/40001 16:47:01 Some weeks ago it was suggested that this is the first part to get things done. 16:47:51 threeletteracronym[m]: has already implemented in Orbot and can release once we have some public bridges. 16:48:24 Anything more I can do from my side? 16:48:28 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 that's correct, the program is not a pluggable transport 16:49:26 dcf1: is that something you are willing to accept as a contribution in the current code? 16:49:30 you should feel free to fork it to make a PT-capable version 16:49:38 I don't think I want PT support in the main code 16:49:40 dcf1: What is needed for this to happen, is there a TODO/issue about it? 16:50:47 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 anadahz: there is point about it in the TODO list of the issue you linked 16:51:40 but I don't know about any other issues about it 16:52:05 there are skeletons of PT applications at https://gitweb.torproject.org/pluggable-transports/goptlib.git/tree/examples to use as examples 16:52:41 anadahz: is the orbot team wanting multiple public bridges? why does there have to be more than one bridge? 16:53:07 dcf1: for redundancy/backup 16:53:15 ok 16:54:33 ggus mentioned last time that we could to relay operators once we have something alpha. 16:57:01 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 great 16:57:57 thanks for poking back about and sorry if is moving slowly 16:58:11 is almost one hour of meeting 16:58:12 Speaking of PT... I think PT only support per connection argument of 256 chars, is that correct? 16:58:35 shelikhoo: that's correct. I think it is different in PT 2.0 and 3.0. 16:59:27 gotta jump to another meeting 16:59:42 bye itchyonion 16:59:42 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 bye itchyonion 16:59:55 bye guys 17:00:23 shelikhoo: maybe you could pass a path to the file or split it into different pieces 17:01:07 yes, but that won't work well with tor browser. I don't think tor browser expects something like that 17:01:16 there is an ancient ticket: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10671 17:02:49 anything else for today? 17:02:57 thanks dcf1~ 17:04:01 #endmeeting