15:59:37 <shelikhoo> #startmeeting tor anti-censorship meeting
15:59:37 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:59:37 <shelikhoo> feel free to add what you've been working on and put items on the agenda
15:59:37 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:54 <shelikhoo> hi~
16:04:11 <dcf1> shelikhoo: do you need any assistance or information for the distributed snowflake bridge merge?
16:05:50 <shelikhoo> 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 <shelikhoo> otherwise it is all good
16:05:59 <shelikhoo> and ready to merge
16:06:59 <shelikhoo> in fact I originally intent to merge it just after cohosh approve my amendment after approval
16:07:01 <dcf1> if you don't hear any objections, I would go ahead and merge
16:07:08 <shelikhoo> yes
16:07:26 <shelikhoo> I think I could merge it
16:07:29 <arma2> (reminds me of how folks found websites like 'doctorproject.org' filtered in china :)
16:07:37 <arma2> (also hi, i am around if you need anything from me)
16:07:58 <dcf1> shelikhoo: and deploying the new code to the broker, do you feel confident about that?
16:08:50 <shelikhoo> It should be fine, but I would prefer a full crew day to do that
16:09:10 <dcf1> yes, sounds good
16:09:18 <shelikhoo> I can write the amended config file first
16:09:24 <shelikhoo> before run the deployment
16:09:38 <shelikhoo> since this time, the config need to change
16:09:53 <dcf1> If I understand correctly, the next step is to then deploy multi-bridge capable proxies?
16:10:17 <shelikhoo> yes, we need to contact users to update their snowflake proxy
16:10:19 <dcf1> 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 <shelikhoo> yes, once the proxies exist, and we reject outdated proxies
16:11:03 <shelikhoo> everyone can connect to snowflake 2
16:11:22 <shelikhoo> by update snowflake-client and edit torrc
16:11:55 <shelikhoo> we have metrics to monitor how many proxies have updated
16:12:04 <dcf1> 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 <shelikhoo> so that we don't shoot ourself in the foot in rejecting old proxies
16:12:52 <shelikhoo> yes! thanks! you are welcome, and thank for your contribution to this task as well!
16:12:52 <dcf1> 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 <arma2> neat
16:15:02 <shelikhoo> I intent to deploy both distributed snowflake and snowflake proxy ip change rate measurement in one go
16:15:06 <shelikhoo> it is more risky
16:15:21 <shelikhoo> but the downtime will be decreased
16:16:09 <dcf1> that sounds okay
16:17:39 <arma2> 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 <shelikhoo> 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 <shelikhoo> that is the end of announcement for Distributed Snowflake, IP Change Rate Measurement is ready for merge src Shell
16:19:04 <shelikhoo> arma2: no, we still don't have a way to find out that yet
16:19:55 <dcf1> Okay my discussion point is about DTLS fingerprinting in Russia
16:20:05 <shelikhoo> 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 <shelikhoo> yes
16:20:27 <shelikhoo> right now, according to the vantage point we have
16:20:49 <shelikhoo> snowflake is working in our vantage point in russia
16:20:55 <dcf1> 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 <dcf1> 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 <dcf1> The concise way of saying it is: snowflake fails to connect if either side uses a Pion client.
16:23:05 <dcf1> Pion peer acts as TLS server -> ok
16:23:11 <dcf1> *DTLS
16:23:17 <dcf1> Browser peer acts as DTLS client -> ok
16:23:29 <dcf1> Pion peer acts as DTLS client -> not ok
16:23:53 <dcf1> Pion peer could be snowflake-client, or could be proxy-go.
16:24:21 <dcf1> The choice of whether a user's snowflake-client acts as a DTLS client or server may depend on their NAT
16:24:32 <dcf1> So the blocking rule may affect some NAT types more than others
16:25:15 <dcf1> 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 <dcf1> 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 <dcf1> I'm not so sure about this idea, because it may make the snowflake fingerprint even more distinctive
16:26:50 <arma2> 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 <dcf1> 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 <dcf1> 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 <shelikhoo> dcf1: yes, and we would need a world wide deployment of this for the snowflake proxy
16:28:44 <dcf1> shelikhoo: no, not necessarily.
16:29:47 <dcf1> 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 <dcf1> 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 <shelikhoo> 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 <shelikhoo> but I can look into this
16:31:57 <shelikhoo> dcf1: Yes. we can try to create a version of snowflake-client with the patch applied
16:32:00 <dcf1> https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=7ffd69a21b8a408a2be9cfdbe7401e1a7f974310
16:32:04 <shelikhoo> and see how it works
16:32:12 <dcf1> ^ example of when we temporarily forked pion/dtls before
16:33:47 <dcf1> https://archive.org/details/@torproject
16:33:53 <dcf1> https://archive.org/details/snowflake-ru_snowflake_fix-20211208-ae7cc478fd34
16:33:58 <dcf1> https://archive.org/details/tor-browser-snowflake-ampcache-10.5.3
16:34:09 <dcf1> ^ examples of one-off Tor Browser builds made for testing
16:35:29 <dcf1> That is all from me on this topic, I just wanted to refresh awareness of it
16:35:32 <shelikhoo> I will create a ticket for creating an specialized version of snowflake with this patch applied
16:35:44 <shelikhoo> is there such a ticket already?
16:36:15 <dcf1> 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 <shelikhoo> No, I think I can create one. It should give this issue more visibility
16:39:28 <shelikhoo> anything more on this topic?
16:39:45 <dcf1> that's all from me
16:39:45 <shelikhoo> we will have a reading group next week:
16:39:59 <shelikhoo> Even Censors Have a Backup: Examining China's Double HTTPS Censorship Middleboxes
16:40:27 <shelikhoo> anything more we want to discuss in this meeting?
16:42:29 <shelikhoo> okay, I think this the end of this meeting. thanks everyone!
16:42:29 <shelikhoo> #endmeeting