15:58:08 #startmeeting tor anti-censorship meeting 15:58:08 Meeting started Thu Mar 11 15:58:08 2021 UTC. The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:08 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:13 hey everyone 15:58:24 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:39 there's not much on the agenda for today 15:59:08 someone has helpfully translated the public bug-reporting pad to Chinese https://pad.riseup.net/p/tor-anti-censorship-bugs-keep 15:59:41 hanneloresx: are you here? can you say if the translation is any good? I will put the English back, but if the Chinese is fine, might as well keep it as well 15:59:42 oh nice! 16:00:15 the translation is great 16:00:40 thanks for checking 16:01:11 no prob 16:01:59 anybody need help or reviews for anything? 16:02:21 cohosh: I have some of your issues in my inbox waiting for attention 16:02:27 notably snowflake!30 16:02:34 ah thanks! 16:02:50 yeah i'm interested in your thoughts on that issue since it is related to turbotunnel 16:03:32 about https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40002#note_2728512 16:03:52 were the bridge lines you sent obfs4 or vanilla? If vanilla, the problem may not be enumeration but active probing 16:04:00 we gave both 16:04:10 none of the vanilla bridges were blocked 16:04:21 only default and email distributed obfs4 bridges are blocked 16:04:27 and tor relays 16:04:40 hmm interesting 16:04:42 so we think it's specifically not dpi or active probing 16:04:46 hi 16:05:06 yeah, and actually only one email distributed bridge wasn't blocked and it was created at the end of february 16:05:13 agix: hi! 16:05:38 so i sent a few more bridge lines to check to see if we can pin down when the enumeration happened (if it did) 16:05:56 yeah this is really interesting 16:06:35 also the blocking itself looks unusal to me. do we know of more blocked that happens at the last ACK of the TCP handshake? 16:06:42 no RST or FIN packets 16:06:49 yeah that is familiar from something else 16:06:52 just everything disappears 16:06:54 ah ok 16:07:04 maybe the recent ESNI block in China was like that, server->client? 16:08:46 cool, maybe we can figure out what hardware/software the censors are using 16:08:49 er, I mean, if I understand correctly the situation in Belarus, the connection is blocked only after the server's SYN/ACK (which arrives at the client) 16:08:55 yup 16:09:46 with enumerating the bridges from the email bucket in bridgedb 16:10:02 it makes sense in some ways that that would be the distributor they go for 16:10:17 if they blocke bridges.torproject.org they might not think to enumerate those 16:10:50 and it's probably more difficult to write a script to enumerate moat bridges because of the CAPTCHA 16:11:38 all you need is a email address and a script that gets bridges like once a day and you're pretty much undetectable 16:11:45 *a gmail adress 16:13:48 anyway, i'm curious to see what happens 16:15:03 i wonder if we should put more effort into distributing private bridges in belarus 16:15:23 moat bridges still work and that's our most popular distributor 16:16:03 i'm also looking into the snowflake situation in china 16:16:21 it has become unusable and i'm not sure yet whether that's because of performance or if snowflake IPs are getting blocked 16:16:28 hopefully i'll have an udpate next week :) 16:17:06 yeah it's really hard to say 16:18:37 any other discussion for this week? 16:21:10 okay i'll end the meeting here 16:21:13 thanks everyone 16:21:17 #endmeeting