15:58:45 #startmeeting tor anti-censorship meeting 15:58:45 Meeting started Thu Aug 11 15:58:45 2022 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:45 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:49 hi everyone! 15:58:52 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:57 feel free to add what you've been working on and put items on the agenda 15:59:16 I kept the two points that are from last week, not sure if we need to discuss them 16:00:56 let's see, the first one of those is the snowflake fingerprint situation in russia, any news on that? 16:01:25 no I am not working on that issue right now 16:01:57 ok, should we remove this from the pad? 16:02:57 I think we can move it somewhere else and bring it back once there is any news.... 16:04:17 this somewhere else might be https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030 ? 16:04:24 or should we open an issue on snowflake side for it? 16:05:11 It is quite mixed with all kinds of things. We already have issues for some specific topics in it... 16:05:49 I suggest we just move it to that ticket just in case we got any news. 16:06:33 I agree, let's do that, do you want to do it? 16:06:38 yes 16:07:03 thanks 16:07:04 I will do this after the meeting 16:07:23 no need to block the discussion 16:07:24 hello 16:07:36 hello 16:07:51 the next topic from last week is the snowflake one 16:07:57 I see is actually two: 16:08:03 snowflake.tpo website 16:08:13 docker CI build 16:08:32 there are issues for both of them, anything to discuss or can we move on? 16:09:30 for the docker CI 16:10:18 I understand that meskio don't wish trust the gitlab with docker registry token 16:10:35 maybe we can let it build the image and maybe binaries 16:10:47 and then someone can push manually 16:11:00 this prevent the leak of docker registry token 16:11:13 yes, I'm not sure I'm confortable giving gitlab access to the docker registry 16:11:25 but don't protect against supply chain attack 16:11:31 but I'm happy with building everything 16:12:00 yes, we can let it build everything, then push to the docker registry manually 16:12:11 I will investigate if that is possible 16:12:18 the same will goes to webext 16:12:25 +1 16:12:42 build all the files, but deploy to production will be done manually 16:13:14 so that we will have change to intervene if something obviously goes wrong 16:13:16 yes 16:13:35 I have nothing more on this topic 16:13:39 shelikhoo: I did move the issue into docker-snowflake-proxy, but I'm not sure is the right place, feel free to move it back 16:14:54 the next topic is the use of azure for snowflake domain fronting 16:15:11 yes. we can discuss everything in the docker repo, but the deployment will need to happen on the snowflake 16:15:50 great 16:15:52 The reason we wants to that is because we suspect the fronted broker is not reachable in TM 16:16:21 in the https://snowflake-broker.freehaven.net/metrics 16:16:29 we didn't see a lot of TM users 16:16:41 at snowflake-ips 16:17:36 have we ever had more TM users in past? 16:17:50 however, when we try to test it with a open proxy in TM, the sstatic.net is reachable 16:19:43 ok, we could try to domain front with azure 16:19:52 meskio: i think snowflake is blocked in TM since last year 16:20:45 I'll check with TB people to see if connect assist will use the bridgeline we provide for snowflake, we could distribute azure configuration only to TM 16:20:50 ggus: thanks, makes sense 16:20:59 yes, we could try. But i am unsure the root cause of blocking now 16:21:18 ggus: do you know who has access to meek-azure account? 16:21:24 the exact way it snowflake is blocked in TM is currently unknown right now 16:21:54 would be nice to have a vantage point in TM 16:21:56 I was trying see if we can got a vantage point in TM 16:22:03 :) 16:22:04 meskio: maybe cohosh? idk 16:22:16 and there isn't any easy way to get one 16:22:33 apart from a really expensive one 16:22:49 all others do not have automatic setup 16:23:04 so we need to talk to sales to get one 16:23:24 either when searching in english or chinese 16:23:54 meskio can try if there is any good option when searching in Spanish 16:24:18 I can try that, I will be surprised that there is info about it in spanish 16:24:24 I guess we might have more luck in russian 16:24:31 the sekret partnership between spain and tm :) 16:24:37 but I didn't find a way to buy one at a reasonable price without talking to a human 16:24:45 there are way more chinese result than english ones 16:24:57 we could ask nina to help with the search in russian 16:25:03 so I just assume it wouldn't hurt to try 16:25:15 sure, I will 16:25:20 i saw some websites hosted in telecom using russian domain registers 16:25:42 let's say this one is in russian 16:25:42 https://telecom.tm/ru/hosting/ 16:25:44 but 16:26:00 it do not support self-service purchase 16:26:04 (seems) 16:26:21 we could try some social engineering... 16:26:29 (maybe here is not the best place to talk about that) 16:27:03 yes... we can discuss about this later in the voice team sync 16:27:20 but anyway it is not easy 16:27:34 I'll try to find who has access to the meek-azure stuff 16:27:41 yes 16:27:48 and figure out if we can change it from the circumvention settings api 16:27:57 but let's investigate more the TM vantage point 16:28:16 and the censorship on AGTS and TM Telecom appears to be slightly different 16:28:50 :( 16:29:30 yes, I think a lot of eccentric chinese vps providers also sells vps in iran in additional to TM 16:29:47 beyond using meek-azure for snowflake, there is also a patch fix for vanilla tor connections that valdikss submitted to core/tor 16:30:27 if we decide to pursue that route we might set up more than one vantage point in targeted location 16:30:53 https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40029#note_2826894 16:31:13 https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/599 16:31:49 wow, nice 16:32:54 but i think someone needs to resolve nickm's comments, then ship it to tor browser 16:34:04 I see is stuck since 3 weeks 16:35:20 and obfs4 bridges are also blocked because they are blocking a bunch of ip range too 16:35:27 I'll check with nickm how he feels about valdikss answers and try to give it a push 16:35:57 meskio: great! ty! 16:36:52 ggus: I think we should focus on fixing snowflake in TM and once this is working let's see if we can do something about bridges, step by step 16:37:58 anything else on this topic? 16:38:03 meskio: for bridges i think we need to find providers that are not blocked in TM. i heard about some IP ranges in contabo (isp in de). 16:38:22 but the IP address that i got from contabo didn't work 16:38:50 i agree with fixing snowflake in tm and then figuring out what to try next :) 16:39:03 I see, we could use some allowlist just for TM with IPs that work, but we need to find what are those 16:39:37 yeah, and this is the hard task because they are blocking the whole internet, except wikipedia, skype and gmail 16:40:10 we should ask those to run bridges ;P 16:40:41 :P 16:42:59 it is only slightly easier than ask oppressor to respect human rights 16:43:20 haha 16:43:34 should we move on to talk about HTTPT? 16:43:38 yes 16:43:50 shelikhoo do you want to introduce it? 16:43:54 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/httpt/-/issues/1#note_2826601 16:44:43 HTTPT is a transport we have decided to include in Tor Browser but haven't decide exactly how to 16:45:08 On server, It is designed to be used together with a forwarder 16:45:45 for people without the knowledge of secret url, then the forwarder like nginx act like an ordinary web server 16:45:56 display a website 16:46:16 but when client request to connect to an specific path 16:46:34 the forwarder will send that connection to HTTPT 16:46:54 creating an bidirectional connection between HTTPT client and server 16:47:14 this prevents active probe by having an website as cover 16:48:12 but also make it harder to passively classify the connection by making sure the client server connections are standard complaint HTTP connections 16:48:32 and can be seen as HTTPS traffic 16:49:15 in this issue, i outline the deployment pattern we could purpose 16:49:42 On server, there is a HTTPT pluggable transport managed by C-Tor program 16:50:02 which is listened on a local port 16:50:15 and forwarder like nginx forward connection to this local port 16:50:56 and the bridge operator ordinarily run their own Tor and HTTPT 16:51:40 is there any questions so far? 16:51:46 I think this proposal sounds pretty good, I think is fair to assume bridge operators will run both tor and the web server for HTTPT 16:52:31 yes, we could in theory run a public HTTPT server, but it will create the same scale issue we encountered on snowflake 16:52:55 let's decentralize and let bridge operators pay for the traffic... 16:52:58 :) 16:53:02 yes... 16:53:16 snowflake is special as we can not run tor as browser plugin 16:53:53 (maybe we could, but wow, that would be fun compiling C-tor into wasm...) 16:54:28 yes, that's true, and tor don't support distributed servers on its own 16:54:48 we need to specifically work around some tor's design to get it working 16:55:17 we cannot run tor in browser as it is not possible to create arbitrary tcp connections in browser 16:55:52 it can only send HTTP or other browser approved traffic 16:56:04 yes, true, that is the real reason :) 16:56:11 I can begin the implementation of HTTPT right now, do we wants to do that? 16:56:27 I can begin the implementation of HTTPT PT right now, do we wants to do that? 16:56:36 your plan sounds good 16:56:49 I'm eager to see what you produce with it :) 16:57:09 yea the whole HTTPT thing sounds really interesting 16:58:11 yeah. I take it as a yes meskio 16:58:40 +1 16:58:46 anything else for today? 16:58:55 nothing from me 16:59:16 me neither 16:59:24 great, let's close the meeting then 16:59:28 #endmeeting