15:59:37 #startmeeting tor anti-censorship meeting 15:59:37 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:37 feel free to add what you've been working on and put items on the agenda 15:59:37 Meeting started Thu Jun 16 15:59:37 2022 UTC. The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:37 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:54 hi~ 16:04:11 shelikhoo: do you need any assistance or information for the distributed snowflake bridge merge? 16:05:50 dcf1: I don't think i will need any. there is a last minute amendment to add a $ sign at end of allowed domain name pattern, I am not sure if it needs an additional review before merge 16:05:56 otherwise it is all good 16:05:59 and ready to merge 16:06:59 in fact I originally intent to merge it just after cohosh approve my amendment after approval 16:07:01 if you don't hear any objections, I would go ahead and merge 16:07:08 yes 16:07:26 I think I could merge it 16:07:29 (reminds me of how folks found websites like 'doctorproject.org' filtered in china :) 16:07:37 (also hi, i am around if you need anything from me) 16:07:58 shelikhoo: and deploying the new code to the broker, do you feel confident about that? 16:08:50 It should be fine, but I would prefer a full crew day to do that 16:09:10 yes, sounds good 16:09:18 I can write the amended config file first 16:09:24 before run the deployment 16:09:38 since this time, the config need to change 16:09:53 If I understand correctly, the next step is to then deploy multi-bridge capable proxies? 16:10:17 yes, we need to contact users to update their snowflake proxy 16:10:19 And once the proxies exist, then anyone can start using the snowflake-02 bridge instead of snowflake-01 by editing their torrc? 16:10:52 yes, once the proxies exist, and we reject outdated proxies 16:11:03 everyone can connect to snowflake 2 16:11:22 by update snowflake-client and edit torrc 16:11:55 we have metrics to monitor how many proxies have updated 16:12:04 snowflake-01 is still within its capacity, but it is good to get the second bridge starting to go. thanks for your work on this. 16:12:24 so that we don't shoot ourself in the foot in rejecting old proxies 16:12:52 yes! thanks! you are welcome, and thank for your contribution to this task as well! 16:12:52 snowflake-01 has started to peak at over 1 Gbps during periods of highest usage, but that's still okay since ln5 upgraded it to a 10 Gbps link. 16:13:50 neat 16:15:02 I intent to deploy both distributed snowflake and snowflake proxy ip change rate measurement in one go 16:15:06 it is more risky 16:15:21 but the downtime will be decreased 16:16:09 that sounds okay 16:17:39 does that mean we solved the ticket where the broker couldn't figure out which version the proxy is running? (i am hunting for the ticket but haven't found it yet) 16:17:52 yes. let's see how it goes. I will create a ticket to describe this deployment, since this is a major functional update 16:18:35 that is the end of announcement for Distributed Snowflake, IP Change Rate Measurement is ready for merge src Shell 16:19:04 arma2: no, we still don't have a way to find out that yet 16:19:55 Okay my discussion point is about DTLS fingerprinting in Russia 16:20:05 however, for this time, we will have a metrics for whether the proxy have updated to a version with distributed snowflake support or not 16:20:15 yes 16:20:27 right now, according to the vantage point we have 16:20:49 snowflake is working in our vantage point in russia 16:20:55 The summary is that UDP packets matching the pattern `^\x16\xfe[\xfd\xff].{X}\x00\x1d\x00\x17\x00\x18` are getting blocked, where X is a small number of distinct offsets 16:21:45 My understanding is that snowflake only works in some configurations of pion/browser and client/server. Sorry, let me check my notes quick. 16:22:56 The concise way of saying it is: snowflake fails to connect if either side uses a Pion client. 16:23:05 Pion peer acts as TLS server -> ok 16:23:11 *DTLS 16:23:17 Browser peer acts as DTLS client -> ok 16:23:29 Pion peer acts as DTLS client -> not ok 16:23:53 Pion peer could be snowflake-client, or could be proxy-go. 16:24:21 The choice of whether a user's snowflake-client acts as a DTLS client or server may depend on their NAT 16:24:32 So the blocking rule may affect some NAT types more than others 16:25:15 Another way of stating the above rule is: snowflake only works if using a browser proxy (not a proxy-go proxy), and only if snowflake-client takes the DTLS server role in the connection 16:26:02 ValdikSS has a pull request with pion https://github.com/pion/dtls/pull/474 to change up the supported_groups extension that is part of the matching rule 16:26:23 I'm not so sure about this idea, because it may make the snowflake fingerprint even more distinctive 16:26:50 shelikhoo: sounds like we might want to split the vantage point test into several tests, where we try various types of snowflake proxies 16:27:19 One thought I had was to insert a padding or other no-op extension to adjust the offsets. that would create a new fingerprint too, but is probably less work to implement and more agile 16:28:25 There is perhaps no need for urgent action on this, but I am wondering if there is some class of users for whom snowflake is completely blocked. maybe, maybe not 16:28:31 dcf1: yes, and we would need a world wide deployment of this for the snowflake proxy 16:28:44 shelikhoo: no, not necessarily. 16:29:47 If we patch snowflake-client, that takes care of one end of the connection. If the blocking rule was "Pion client", and it happened that all of a certain class of users were *always* clients, then altering the Pion fingerprint on the client side alone could be sufficient 16:30:46 One way forward would be to (temporarily) fork pion/dtls in the Tor Browser alpha. Then we could ask users to try the alpha release. Or even a one-off special build of the browser like we sometimes do. 16:31:17 arma2: I think right now we don't have a way to specify whether a WebRTC peer is a client or server 16:31:32 but I can look into this 16:31:57 dcf1: Yes. we can try to create a version of snowflake-client with the patch applied 16:32:00 https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=7ffd69a21b8a408a2be9cfdbe7401e1a7f974310 16:32:04 and see how it works 16:32:12 ^ example of when we temporarily forked pion/dtls before 16:33:47 https://archive.org/details/@torproject 16:33:53 https://archive.org/details/snowflake-ru_snowflake_fix-20211208-ae7cc478fd34 16:33:58 https://archive.org/details/tor-browser-snowflake-ampcache-10.5.3 16:34:09 ^ examples of one-off Tor Browser builds made for testing 16:35:29 That is all from me on this topic, I just wanted to refresh awareness of it 16:35:32 I will create a ticket for creating an specialized version of snowflake with this patch applied 16:35:44 is there such a ticket already? 16:36:15 not that I'm aware, there is only https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030 for the general observation of blocking 16:37:22 No, I think I can create one. It should give this issue more visibility 16:39:28 anything more on this topic? 16:39:45 that's all from me 16:39:45 we will have a reading group next week: 16:39:59 Even Censors Have a Backup: Examining China's Double HTTPS Censorship Middleboxes 16:40:27 anything more we want to discuss in this meeting? 16:42:29 okay, I think this the end of this meeting. thanks everyone! 16:42:29 #endmeeting