15:59:45 <cohosh> #startmeeting tor anti-censorship meeting 15:59:45 <MeetBot> Meeting started Thu Nov 11 15:59:45 2021 UTC. The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:45 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:50 <cohosh> hi everyone! 16:00:03 <cohosh> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 16:00:17 <cohosh> we have reading group at the end of the meeting today, but otherwise an empty agenda 16:00:36 <cohosh> please feel free to add items and also update us on what you've been up to :) 16:00:38 <meskio> hello 16:01:28 <shelikhoo> hi~ 16:03:01 * cohosh waits a few mins to allow for updates and agenda items 16:03:27 <cohosh> (but feel free to jump in with topics) 16:04:37 <cohosh> oh, as just a quick update, i was thinking of posting our monthly reports on discourse 16:05:02 <cohosh> after reading ahf's awesome network team update: https://forum.torproject.net/t/updates-from-the-network-team-october-2021/442 16:05:08 <meskio> :) 16:05:12 <meskio> sounds good to me 16:05:18 <cohosh> \o/ 16:05:27 <ahf> <3 16:05:43 <ahf> maybe more people will check out the forum with more content there \o/ 16:06:37 <cohosh> yea! 16:07:06 <cohosh> we used to post our reports on the blog but stopped because the interaction we were getting wasn't constructive 16:07:14 <cohosh> discourse seems to be a much better setup for that 16:07:38 <meskio> at least it has a more fluid moderation 16:08:40 <cohosh> yeah 16:08:56 <meskio> I finally got bridgedb talking to rdsys, the mr is pretty long, but is mostly deleted lines 16:09:19 <meskio> I'm drafting a plan on how to test it as I would like a bit more testing than just what I've done in my machine 16:09:29 <cohosh> :o 16:09:32 <cohosh> amazing 16:10:08 <shelikhoo> Yes, I am really worried my code will interact with other part of the system in unexpected way 16:10:17 <cohosh> that is a lot of work finally coming to fruition 16:10:25 <shelikhoo> Maybe we can create a staging environment? 16:10:44 <meskio> shelikhoo: yep, this is more or less what I would like to do with bridgedb 16:11:24 <meskio> I was wondering if I want to propouse using containers for that, as right now our deployment mechanism is a bit manual 16:12:00 <meskio> but I'm not sure TPI will be happy to provide an environment to run containers, I guess is something we are not doing in production (yet) 16:12:35 <cohosh> sounds like a good thing to talk to the sysadmin team about 16:12:47 <cohosh> polyanthum is honestly kind of a mess right now 16:13:04 <meskio> yes, I'm a bit scared to touch things there, containers could help 16:13:21 <meskio> anyway, I can go next monday to the TPI office hours and talk with them and see what they think 16:13:22 <shelikhoo> It would be great if we can just apply a yaml or tfplan to get everything working 16:13:44 * meskio looks up tfplan 16:13:54 <shelikhoo> terraform plan file 16:14:04 <meskio> ahh, I see, never used terraform before :) 16:14:06 <shelikhoo> just a description of server setup 16:14:28 <cohosh> i think there was experimentation with ansible in the past 16:14:34 <cohosh> not sure whether it's used in production now though 16:14:45 <shelikhoo> let say we pack each part of software in a container 16:15:11 <meskio> I have used ansible in the past, is not too bad 16:15:45 <shelikhoo> and use kubernetes to run it? It is hard to make a desion without investigation 16:16:08 <meskio> yep, let's talk with TPI (the sysadmin team) and see what they think about it 16:16:29 <cohosh> awesome! 16:17:03 <cohosh> anything else before we move onto reading group? 16:17:14 <ggus> oh, nice that AC team wants to use the forum to publish the reports! :D 16:17:18 <shelikhoo> V2Ray/Fly Developers is investigating the report of the current wave of blocking of Shadowsocks and VMess+TCP servers during China's CCP meeting session. Blocking of Shadowsocks is observed on developer-controlled servers. 16:17:26 <ggus> let me know if you need help with it 16:18:42 <cohosh> ggus: thanks! i watched the discourse training and am writing up the report now :) 16:18:52 <shelikhoo> Although the exact identification method isn't clear yet 16:19:00 <cohosh> shelikhoo: oh interesting, i didn't know shadowsocks was being blocked 16:19:07 <meskio> I've seen this discusion on the topic: https://github.com/net4people/bbs/issues/69 16:19:58 <meskio> but I didn't follow up, it looks like several providers are talking about it 16:20:11 <cohosh> how do you observe the blocking? by usage metrics? 16:20:52 <shelikhoo> No, we control some of server that are blocked, so we can directly observe it 16:21:23 <shelikhoo> It is a kind of port block 16:21:52 <shelikhoo> packet capture is running, but I am not sure the root cause can be discovered. 16:23:04 <shelikhoo> The block of VMess is reported by user, but so far we cannot reproduce it(https://github.com/v2fly/v2ray-core/issues/1377[Chinese]) 16:23:23 <meskio> did I understand that it looks like the GFW is able to block it just by observing the traffic? 16:23:50 <shelikhoo> Yes, shadowsockets is know to have some weakness 16:24:06 <shelikhoo> and the developers have no plan to fix it 16:24:20 <shelikhoo> since they perfer a stable protocol 16:24:42 <meskio> I see, I didn't know it was a known problem 16:24:46 <shelikhoo> since they prefer a stable protocol 16:25:45 <cohosh> :/ 16:25:50 <shelikhoo> And some iOS client always send header without the first client payload data 16:26:16 <shelikhoo> so the packet length give GFW additional infomation 16:26:57 <shelikhoo> Their decision is not understandable, currently most Shadowsockets servers are running inside firewall 16:26:58 <cohosh> but the blocking method is by port? 16:27:07 <shelikhoo> yes, not by IP 16:27:50 <shelikhoo> and these server just accept Shadowsockets protocol traffic from user, and send these traffic with another tunnel 16:28:56 <shelikhoo> so it is usually just used for accepting traffics, not actually tunnel traffic through GFW 16:29:27 <shelikhoo> so don't change the protocol means all existing client softwares will still work 16:30:26 <shelikhoo> and even if the protocol is blocked by GFW, it is still working for sending traffic to a server inside firewall 16:32:10 <cohosh> does the workaround at the end of the net4people/bbs thread still work? 16:32:14 <shelikhoo> It is not like it is instantly blocked, usually it is after a few days of usage and only during sensitive period. So it is really hard to know the exact method of blocking 16:33:18 <shelikhoo> I have't tried, but it should work. Since it is block by port. 16:33:47 <shelikhoo> It is not like it is instantly blocked, usually it is after a few days of usage and only during sensitive period. So it is really hard to know the exact method of identification 16:33:53 <cohosh> i wonder if the bridge blocks we see are also by port 16:34:18 <cohosh> perhaps obfs4 bridge operators don't need to rotate their IP, just change their port 16:34:25 <cohosh> to get unblocked 16:35:16 <cohosh> the blocks we see are from enumeration through BridgeDB/built-in bridge settings, but it would be an interesting thing to try 16:35:33 <meskio> we should test that, should be easy to check as obfs4 bridges do usually also have a vanilla port that we could try out if the obfs4 one get blocked 16:36:05 <meskio> (or this is what I understood reading the bridgeauthority files) 16:36:06 <cohosh> +1 16:36:16 <shelikhoo> usually when a server is blocked by IP, then ping will timeout as well 16:37:26 <shelikhoo> if we still have a account at a cloud provider, we can just automate the server setup and destory process with terraform 16:37:41 <shelikhoo> and instantly recreate any blocked server 16:38:02 <cohosh> we have volunteers running obfs4 bridges with terraform i believe 16:38:08 <cohosh> in general, tor doesn't run most bridges 16:38:26 <cohosh> the snowflake bridge is an exception in that way 16:38:40 <cohosh> "we write and maintain the code, we don't run the network" 16:38:40 <shelikhoo> Yes... maybe we have have some tool to auto recreate a bridges with a new ip when it is blocked? 16:38:56 <cohosh> shelikhoo: yep! that's the idea 16:39:54 <cohosh> censorship-analysis#40020 16:40:08 <cohosh> but we were assuming we had to rotate IP addresses. if it's just ports our job is easier 16:41:08 * meskio wonders how long will take the GFW to start blocking IPs if bridges start rotating ports 16:41:20 <meskio> but is a nice cat and mouse play 16:41:46 <cohosh> yeah 16:42:12 <shelikhoo> well, it could be stable... if we haven't been deplatformed from AWS meek... 16:42:51 <shelikhoo> Let's say AWS Lambda can also be used if they allow us. 16:43:56 <cohosh> yeah, again it can't be us, it has to be volunteers 16:44:15 <cohosh> we have volunteers who are already doing this so after we test it, the next step is to talk to them 16:45:03 <cohosh> i think they already have some nice setups for doing the rotation 16:45:14 <cohosh> hopefully if this works it'll make their lives easier :) 16:46:38 <cohosh> thanks for bringing up this topic shelikhoo! this was really informative and helpful 16:46:58 <meskio> yes, I've learned a lot here :) 16:47:06 <cohosh> is there a way we can help with the v2ray/shadowsocks users who are affected by this? 16:49:33 <shelikhoo> I think VMess + WebSocket + TLS is not blocked, so they can just change some config and get everything working 16:49:57 <cohosh> okay nice 16:50:20 <shelikhoo> I can't think a way that we can help them right now. 16:50:50 <cohosh> okay, thanks shelikhoo 16:51:13 <cohosh> let's move on to the reading for today, unless there's something else? 16:51:33 <meskio> +1 16:51:58 <shelikhoo> I have tested that about 2 of 3 of obfs4 bridge given to me is blocked by IP 16:52:04 <shelikhoo> +1 16:52:07 <cohosh> awesome, today's reading was a FOCI paper from this year 16:52:17 <cohosh> "Measuring QQMail's automated email censorship in China" 16:52:42 <cohosh> by Knockel and Ruan 16:52:51 <cohosh> paper link: https://dl.acm.org/doi/10.1145/3473604.3474560 16:53:11 <cohosh> net4people/bbs summary: https://github.com/net4people/bbs/issues/95 16:53:27 <cohosh> anyone else have a quick summary they want to share? 16:53:49 <meskio> I think the bbs one is pretty good 16:54:40 <cohosh> +1 16:56:51 <shelikhoo> The my first though on this paper is that QQMail reused the spam filter system to implement a censorship system. 16:57:38 <cohosh> heh that makes sense 16:57:57 <meskio> I found pretty interesting to see the keyword distribution, we keep hearing the example of tibet or tiananmen as censored content and I got surprised to see those topics having very few keywords 16:58:13 <meskio> I'm happy to be reminded that I don't know much about the topic 16:58:57 <meskio> (at least uyrughurs were high in the keyword list) 16:59:37 <cohosh> meskio: you mean that you think the authors missed testing a lot of relevant keywords? 16:59:56 <meskio> no, I mean that I don't know what kind of content is censored in china 17:00:04 <cohosh> ah i see 17:00:05 <meskio> and we keep using outdated examples 17:00:07 <shelikhoo> The number of term discovered is surprisingly low. I think these are just words that get rejected immediately. 17:00:45 <shelikhoo> Maybe there is an another list that will trigger a manual review after delivery. 17:01:18 <meskio> or maybe they have other blocking mechanisms that doesn't trigger a 550 smtp error code 17:01:37 <meskio> I mean the paper keeps saying that they are surprised that no phising or porn was blocked 17:01:52 <meskio> but they only know that they didn't get a 440 smtp error 17:02:04 <meskio> there might be a long pipeline of blocking/spam mechanisms there 17:02:11 <meskio> s/440/550/ 17:02:25 <meskio> and only one of the pieces return an error on the smtp connection 17:02:51 <cohosh> yeah 17:03:22 <meskio> being as big as qqmail is I will be surprised that they don't have any anti-phising mechanism 17:03:48 <shelikhoo> actually there is, but mostly just send these kind of email to spam folder 17:04:07 <meskio> I see 17:06:09 <cohosh> there's this line at the end of dcf's summary: A further bit of weirdness is that QQMail does not censor incoming mail to a recipient that has previously sent mail to the sender, which is behavior more characteristic of a spam filter than a content filter. 17:06:38 <cohosh> did they test that these emails actually arrived at the end point? 17:06:52 <cohosh> or just that they didn't trigger the 550 smtp error? 17:07:02 <shelikhoo> No, they send email to a non-exist mail address 17:07:02 <meskio> yes, the paper even explores if this behaviour is not intentional to monitor the conversations of dissidents 17:07:16 <cohosh> aha okay 17:07:43 <meskio> they said they set up a test address, but only run few tests against it 17:07:53 <meskio> most of the tests where against a non-existant address 17:08:47 <meskio> they even report this behaviour as a security issue to qqmail, as it will let them discover if someone has sent an email address to a certain address 17:09:58 <cohosh> oof 17:12:19 <meskio> I'm wondering if they censor only messages in chineese or also in other languages, I guess other languages are a small minority that might not matter for the censor 17:13:10 <shelikhoo> Usually the sensitive words are in Chinese... 17:14:33 <shelikhoo> https://zh.m.wikiversity.org/zh-hans/%E4%B8%AD%E8%8F%AF%E4%BA%BA%E6%B0%91%E5%85%B1%E5%92%8C%E5%9C%8B%E5%AF%A9%E6%9F%A5%E8%BE%AD%E5%BD%99%E5%88%97%E8%A1%A8 17:14:55 <shelikhoo> You can see these is some english words in the list 17:15:42 <shelikhoo> (Its title is China's sensitive word list) 17:15:51 <cohosh> this paper includes some discussion of the blocking arabic script: https://www.usenix.org/system/files/conference/foci15/foci15-paper-knockel.pdf 17:16:03 <meskio> I see 17:18:52 <shelikhoo> The thing I am thinking is how do we protect our users in the Salmon system. Let's say what will happen if they share the invitation data on an adversary-controlled channel? 17:20:38 <cohosh> that's a good thought, know that plaintext messages can be monitored and processed for information 17:21:11 <cohosh> one option is to steer users towards certain behaviours through the UI 17:21:37 <cohosh> we could, for example, make it hard for users to copy/paste invite info into any channel 17:21:45 <meskio> do I remember correctly that the invitation data is only valid to create one account? so if the user creats it first and the adversary can't do much with it, the problem is if the adversary is faster will be nice to be able to revoke invitations on those cases 17:21:57 <cohosh> and instead have them scan a friend's QR code on their phone 17:22:06 <cohosh> meskio: yes that's correct 17:22:22 <cohosh> or atleast, that's the intention 17:22:41 <cohosh> for whatever design we actually end up settling on 17:23:02 <shelikhoo> Since the communication channel in for example China is associated with government issued ID, being discovered for using Tor isn't a good thing 17:23:14 <shelikhoo> even if the adversary cannot use that token 17:23:18 <meskio> I like your approach of thinking on the UI instead of crazy crypto mechanisms if possible 17:24:35 <shelikhoo> Although it is unlikely that a punishment will be made solely based on using tor 17:26:20 <cohosh> yeah :-S 17:26:56 <cohosh> the tor opsec thing is very tricky and dependent on the region or even individual 17:27:50 <cohosh> we're almost 30 mins past --- any last discussion? 17:28:05 <shelikhoo> Nope 17:28:16 <meskio> I'm good 17:28:53 <cohosh> okay thanks everyone! this was an awesome meeting and reading group :D 17:29:10 <meskio> yep, it was pretty good 17:29:18 <shelikhoo> Yes! 17:29:29 <cohosh> #endmeeting