15:59:59 #startmeeting anti-censorship meeting 15:59:59 Meeting started Thu Jul 1 15:59:59 2021 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:11 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 16:00:11 hello 16:00:17 feel free to add things to the agenda and update it with what you've been working on :) 16:01:19 meskio, what's "OONI training"? 16:01:32 I was on a OONI training this week 16:01:44 I spend most of my time the last three days doing that 16:01:49 Oh so it was OONI training you, not the other way around, I see 16:02:08 no, I didn't know much of ooni before this week :) 16:02:32 anyway, it was pretty interesting 16:03:06 I see one point in the agenda about snowflake performance 16:03:18 dcf1: was it you? do you want to go ahead about it? 16:03:23 Yes I posted a summary this week, https://lists.torproject.org/pipermail/anti-censorship-team/2021-July/000178.html 16:03:41 I want to see if I can answer any questions about it. 16:03:59 For what KCP and smux are and how they fit together, see a summary at https://github.com/net4people/bbs/issues/14 16:04:32 I'm wondering what are the implications of increasing the buffer? will that affect the memory footprint? 16:04:42 These together form a userspace reliability protocol, which is what we use to migrate a Snowflake connection from one proxy to another. 16:05:30 KCP has some congestion control features, which we have experimented with, but only recently have I seen that smux v2 also has its own congestion control features 16:05:53 Yes, I expect it will increase memory footprint, though I haven't measured it. 16:05:59 I see, so it should only affect the client and not the proxies, isn't it? 16:06:14 I believe the settings are maximums, so it doesn't necessarily use that full amount all the time, though it could use up to that amount. 16:06:36 Right, this does not affect proxies at all, they are ignorant of KCP/smux. Only affects clients and the bridge. 16:06:39 I would personally be fine increasing the memory consumption of the client, it should not really noticable 16:07:07 Maybe on mobile it's a concern. I know that e.g. Android VPN apps are contrained in how much memory they can use. 16:07:24 But like I said, I haven't measured it. 16:07:39 hey! 16:08:14 hello, nice to see you around :) 16:08:39 +1 to increasing buffer sizes 16:08:47 we did this before with kcp i think, 16:09:03 KCP we did: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40026 16:09:21 SetWindowSize 32 -> 1024 16:09:47 I think increasing smux MaxStreamBuffer is the most important setting, and it will probably have a bigger effect than kcp SetWindowSize. 16:09:55 i have some scripts written for snowflake performance testing somewhere 16:10:03 that's great news 16:10:33 I noticed this when I saw that smux v1 doesn't have the same congestion features (so it goes faster but is not constrained in memory) and that kcptun uses higher settings than the defaults. 16:10:37 maybe it'll make snowflake#25723 actually useful 16:11:19 yes, perhaps 16:12:47 it looks like we have an agreement to increase the buffer size, who will send a merge-request? 16:13:43 it looks like there's a couple values to play with 16:13:54 so we could make a new ticket and I can run the performance scripts i have 16:14:03 I think the idea needs some experimentation and testing, which is the annoying part. 16:14:19 and test it with the multiplexing nsowflakes 16:14:20 I wasn't planning to submit an MR myself, just wanted to post my observations so far. 16:14:43 heh this was exactly what snowflake#40026 was for, but we didn't really have time to dig into it 16:14:56 But also, if it's an easy win, I vote for just finding a reasonable setting and if we need to, we can tune it more later. 16:15:06 i think with these observations now that we have some concrete values to try we can move forward on it 16:15:15 sounds good 16:15:35 it's easy to test configs at the client in production but harder at the server 16:15:46 so maybe we can make a guess, deploy it at the server and run some tests 16:15:55 and if they aren't good enough, try something else 16:16:08 we also have a beefier server machine now :) 16:16:18 nice :) 16:16:42 snowflake#40051 16:17:53 good, should we continue in #40026 or a new issue? or do we need to talk more about it here? 16:18:54 I assume silence means let's continue 16:19:08 I just added another point to the agenda 16:19:46 in the OONI training I found out that they were getting blocked in some countries because the golang TLS implementation did trigger some blocking rules 16:19:52 I forget where I saw you posted that link earlier, meskio, but I read it and it was interesting. 16:19:59 https://ooni.org/post/making-ooni-probe-android-more-resilient/#changing-our-android-tls-fingerprint 16:20:30 specifically in android, there the cypher suite is different and produced some false positive, they think for another circunvention tool 16:20:49 I'm wondering if snowflake could have the same problem 16:21:01 Yeah and the ciphersuite ordering depends on whether golang detects hardware AES acceleration at runtime, something like that? 16:21:06 I would expect DTLS not to be in the same blocking list than TLS, but who knows 16:21:16 dcf1: exactly 16:21:23 So we have some information about this regarding snowflake. 16:21:28 OONI people had patched the golang TLS implementation to change that 16:22:01 A list of snowflake detection research so far is at https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/Fingerprinting 16:22:48 I am a coauthor of https://arxiv.org/abs/1605.08805, and DTLS fingerprinting is mentioned in Section 2 and 5. 16:23:16 here is an issue about this fingerprinting paper, and I did add the ooni link to the issue 16:23:27 nice! 16:23:31 My coauthor Mia wrote a script for Zeek (then it was called Bro) for extracting DTLS fingerprints for research purposes. https://github.com/miagilepner/DTLS-fingerprint 16:23:33 but I didn't check if your paper contains already this info and is duplicated, sorry 16:24:18 the related issue: snowflake#40014 16:24:22 Another point, for TLS fingerprinting in general, see https://tlsfingerprint.io/ and https://tlsfingerprint.io/static/frolov2019.pdf. 16:25:25 Sergey and Eric's research is the source of the uTLS library, which is a version of golang crypto/tls patched to imitate different fingerprints. 16:25:58 uTLS is what is currently used for TLS camouflage of meek in Tor Browser (using obfs4's implementation) 16:26:27 OONI's writeup also mentioned uTLS as a possibility. 16:27:06 (hi!) 16:27:09 I guess we should keep in mind this if we see snowflake being blocked on android devices somewhere 16:27:20 One last point, there is a TLS fingerprinting tool called JA3: https://github.com/salesforce/ja3 16:28:14 is snowflake already deployed on android devices? 16:28:43 Ah, actually snowflake#40014 is a different (more recent) paper 16:29:30 https://arxiv.org/abs/2008.03254 not https://arxiv.org/abs/1605.08805 16:30:05 That's all for my short infodump about TLS fingerprinting. 16:30:15 :) 16:30:31 I don't know if any censors anywhere do DTLS detection the way they do TLS detection, it's a good question. 16:30:53 There is also the issue that not all WebRTC sessions use DTLS -- media streams use different encryption. 16:31:32 This is "Media vs. data transport" at https://arxiv.org/pdf/1605.08805.pdf#page=2 16:31:54 meskio: Do you know which countries used to block OONI probes? 16:32:39 if they say it I missed it, but I guess we can ask them 16:33:05 not sure why is not in their blogpost neither in the issue 16:33:33 Also did they block access to everyone trying to access OONI's backend, all only traffic from OONI probes (tricky)? 16:33:59 only android ooni probes connecting to the backend 16:34:10 the blocking was not targeted to ooni, or that is what they thing 16:34:17 s/thing/think/ 16:34:41 they believe the censor was blocking something else that also uses golang TLS implementation and as side effect they got blocked 16:35:41 ah interesting, do you know what the censor tries to block? 16:35:42 golang TLS blocking is itself interesting, it has long been recognized as something to be concerned about, but people have debated whether it's actually feasible to block a golang TLS fingerprint 16:36:09 anadahz: I did ask them, and they were not sure, there are many anti-censor tools using golang, psyphon for example 16:36:27 Psiphon uses uTLS, I believe. At least they are active in the uTLS repository. 16:36:50 maybe that is the reason they use uTLS... 16:37:14 maybe there is an open ticket in the golang TLS repo. 16:37:57 I didn't see any linked from ooni issue, but I didn't search for it 16:37:57 Oh, and maxb from our meeting pad is also a committer. I didn't know that. https://github.com/refraction-networking/utls/commits?author=max-b 16:38:40 I guess we should keep an eye if we see snowflake being censored in android 16:38:58 anything more to talk about this topic? 16:39:37 btw dtls is not in the golang standard library, we get it from pion: https://github.com/pion/dtls 16:39:54 Maybe pion forked crypto/tls for it or uses crypto/tls internally, I don't know. 16:40:10 ohh, nice, we might be off the hook, or easier to fingerprint 16:42:13 alright anyone need reviews that aren't already assigned? 16:43:36 that seems like no, I'll wait few minutes before ending the meeting :) 16:45:34 re: OONI training, they are working on a new tool called Measurement Aggregation Toolkit. you can check ISPs blocking Tor and check other results: https://explorer.ooni.org/experimental/mat?since=2021-06-23&until=2021-07-02&test_name=tor&axis_x=measurement_start_day&axis_y=probe_cc 16:46:03 they mentioned is not public, so please don't share it around 16:46:07 it's still under development, so expect some bugs 16:46:16 yep, also that! 16:47:18 #endmeeting