15:59:28 #startmeeting tor anti-censorship meeting 15:59:28 Meeting started Thu Feb 24 15:59:28 2022 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:28 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:32 hello!!! 15:59:38 Hi~ 15:59:41 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:55 please add what you've been working on and put items on the agenda 16:01:11 we have a pretty empty agenda 16:01:25 I added a point about obfs4 issues, but I'm not sure we have much to update there 16:02:07 https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804 16:02:26 yawning knows about the issue, but is not clear is interested on fixing it 16:02:46 he asks people to update the server side so the problem goes away 16:02:56 We've not heard back from Aaron Johnson yet, whom arma contacted after last week's meeting 16:04:03 obfs4proxy package is in its way to debian testing, I guess as soon as it hits testing we should ask acute to upload it to backports so we get more servers to fix the problem on their side 16:04:13 but still will be nice to have a fix for the problem 16:04:38 Did we test if upgrade will solve this issue? 16:04:49 Yes, an upgraded server solves it. 16:05:49 Yes.... So we can either find a way to get most of server update their obfs4 version, or try to find a client side fix. 16:06:16 I expect it will take many months to get a decent number of bridges to update the version 16:06:42 How about starting with the Tor Browser default bridges? 16:06:50 +1 16:07:53 Yes, and if this kind of urgent update happen too frequently, we might wants to invest in a way to deploy new change more quickly 16:08:22 Yes, and if this kind of urgent update happen too frequently, we might wants to invest in a creating way to deploy new change more quickly 16:09:05 I can build a docker image with the new version, maybe people automatically update their dockers 16:09:46 Yes, we might also wants to update our deployment guide to point to containerised deployment 16:10:29 instead of rely on Debian package 16:10:34 I'm assuming we are moving forward here and don't consider going back to the previous version an option... 16:10:39 There is a ticket for having PT bridges report their versions, which would help with tracking the progress of upgrades: https://gitlab.torproject.org/tpo/core/tor/-/issues/11101#note_2770219 16:12:56 Do we need to amend PT spec to do this in a well defined way? 16:13:22 Having that implemented would be helpful ^^^ 16:13:58 shelikhoo: not necessarily, there is a STATUS message that could have a defined format for reporting the version 16:14:19 is the version already being reported by snowflake and obfs4? 16:14:33 no 16:14:52 meskio: do you have an estimate time when the new obfs4 package will be released on Debian? 16:15:08 there's no protocol defined for doing it. STATUS is a free-form message without defined sematics for specific messages, some defined semantics is what is needed. 16:15:28 ggus: is already in unstable, so it should be <10 days 16:15:54 that is the time to get it into testing, once is in testing you can upload it to backports, but I've never done that, I think this is pretty fast 16:16:44 maybe we should create a task on our side to start reporting the version of snowflake, as a first step for it 16:16:49 task == issue 16:17:09 once we are reporting the version we can check back with the network team to do their part 16:17:48 Yes. I think we might wants to ask network team about their preferred way of receiving version information 16:17:52 Past notes on version reporting using STATUS: https://lists.torproject.org/pipermail/tor-project/2021-October/003194.html 16:20:12 http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-09-30-16.00.log.html#l-10 16:20:26 I'll add those links to #11101 16:21:10 shelikhoo: sounds good, I can start the conversation with the network team in #11101 and see what will be the preferred format 16:21:23 Yes..... 16:22:34 ggus: do you want to contact the default bridges about the obfs4 upgrade? or should I do it? (I guess I can find their contact somewhere in the wiki) 16:23:05 I hope we don't get PT spec spammed with 10 different ways to report version... 16:23:30 I hope not 16:24:02 meskio: I can do that. Tell me when 16:24:43 I guess we can already ask them what they need to update, and if the package in debian backports is a block for them 16:25:31 Ok! Let’s open a ticket to track this 16:26:15 thanks for taking care of it, I'm happy to be in cc if you want 16:26:52 anything more about this topic? 16:26:55 Ack! Thank you! 16:27:32 uTLS in Snowflake Client Broker Communication 16:27:48 Yes 16:28:09 We received reply from Rod Hynes 16:28:29 The TLDR is that uTLS is working for now 16:29:07 And there are other optional improvement we can use to improve it 16:30:27 Since it is a client side feature, we should be able to ship change to get it back to working status quickly 16:31:18 "Since it is a client side feature, we should be able to ship change to get it back to working status quickly" is from me 16:32:08 are you proposing that we enable uTLS by default in snowflake? 16:33:32 The thing I wish to propose is that we first ship a version with uTLS, and allow user to try it first 16:33:59 with the intention to make it default if no issue were discovered 16:34:16 or when a censorship can be evaded by it 16:34:23 sounds good 16:34:45 in that case I think we should pick a default fingerprint, so it can be enabled without having to understand what a fingerprint is 16:35:02 (that might require changes in the proposed params) 16:35:13 remember we have a censorship map in the pipeline 16:35:55 so it should allow us to ship targeted change as soon as user have done testing of utls 16:35:56 I see where you are going, but then we should be able to enable uTLS from the SOCKS connection 16:36:07 the same way we pass the obfs4 params 16:36:29 that's how it works in meek-client and obfs4proxy, utls=xxx in the SOCKS params 16:36:39 nice 16:37:02 https://gitweb.torproject.org/pluggable-transports/meek.git/tree/doc/meek-client.1.txt?h=v0.37.0#n46 16:37:12 Yes, I will amend the merge request to make it happen 16:37:20 I guess is something you put in the bridge line, isn't it? 16:37:35 correct, the SOCKS params are in the bridge line 16:39:01 I will coordinate with TB people, because we don't have anything yet in the circumvention settings for that, but I think should be possible to add 16:39:17 In goptlib, the args end up in the Args field of each SocksRequest https://pkg.go.dev/git.torproject.org/pluggable-transports/goptlib.git#SocksRequest 16:40:03 meskio: that's why there used to be a separate meek-google, meek-amazon, etc. Those were settings that could have been controlled via SOCKS params, but there was not interface for choosing SOCKS params independently of a bridge line. 16:41:17 Yes, and it is much easier to change the bridge line in Tor browser, than to change PT plugin settings 16:41:17 I see, should not be a problem for the circumvention settings, as there is already a way to provide the bridge line, but I'm not sure if we were doing it for snowflake 16:42:45 good, we have a path forward for this 16:42:54 The intention we I am not yet considering enable it for everyone by default is because of the imperfection of uTLS 16:43:12 we don't wants to break someone's setup unnecessarily 16:43:39 but this is not an issue if the non-utls is already censored 16:44:34 +1 16:44:59 anyway, the first step will be amend merge request to receive utls setting from bridge line 16:46:32 good, anything else on this topic? any other topic to discuss? 16:47:23 EOF 16:47:31 I have an anouncement: I'm planning to deploy rdsys+bridgedb in production next monday 16:47:45 so many bridges will change distribution mechanisms 16:47:57 but hopefully this is the only change visible 16:48:09 I'll send emails to tor-project and tor-relays 16:49:11 do we want to pick the next paper for our reading group? or want to wait for cecylia? (she will be around next week) 16:50:05 I am fine either way 16:50:22 * meskio looks into https://censorbib.nymity.ch/ for interesting papers 16:52:02 the titles that sound interesting to me are: How Great is the Great Firewall? Measuring China's DNS Censorship 16:52:04 Throttling Twitter: an emerging censorship technique in Russia 16:52:22 Web censorship measurements of HTTP/3 over QUIC 16:53:46 any preferences? 16:55:07 Throttling Twitter: an emerging censorship technique in Russia? we have got 5-10kb/s download speed on some of s96 bridges 16:55:43 changing to bbr made most of them finish bootstrap, but some of them still have poor download speed 16:56:08 maybe we can have some inspiration from paper? 16:56:08 good, let's do that one, two weeks, 10 March? 16:56:16 that is a good reason 16:56:40 ok, I think we are done with the meeting 16:56:54 I'll wait a minute to close it just in case someone has something else to say 16:58:04 #endmeeting