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