15:59:59 <meskio> #startmeeting anti-censorship meeting
15:59:59 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:11 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
16:00:11 <dcf1> hello
16:00:17 <meskio> feel free to add things to the agenda and update it with what you've been working on :)
16:01:19 <dcf1> meskio, what's "OONI training"?
16:01:32 <meskio> I was on a OONI training this week
16:01:44 <meskio> I spend most of my time the last three days doing that
16:01:49 <dcf1> Oh so it was OONI training you, not the other way around, I see
16:02:08 <meskio> no, I didn't know much of ooni before this week :)
16:02:32 <meskio> anyway, it was pretty interesting
16:03:06 <meskio> I see one point in the agenda about snowflake performance
16:03:18 <meskio> dcf1: was it you? do you want to go ahead about it?
16:03:23 <dcf1> Yes I posted a summary this week, https://lists.torproject.org/pipermail/anti-censorship-team/2021-July/000178.html
16:03:41 <dcf1> I want to see if I can answer any questions about it.
16:03:59 <dcf1> 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 <meskio> I'm wondering what are the implications of increasing the buffer? will that affect the memory footprint?
16:04:42 <dcf1> 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 <dcf1> 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 <dcf1> Yes, I expect it will increase memory footprint, though I haven't measured it.
16:05:59 <meskio> I see, so it should only affect the client and not the proxies, isn't it?
16:06:14 <dcf1> 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 <dcf1> Right, this does not affect proxies at all, they are ignorant of KCP/smux. Only affects clients and the bridge.
16:06:39 <meskio> I would personally be fine increasing the memory consumption of the client, it should not really noticable
16:07:07 <dcf1> 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 <dcf1> But like I said, I haven't measured it.
16:07:39 <cohosh> hey!
16:08:14 <meskio> hello, nice to see you around :)
16:08:39 <cohosh> +1 to increasing buffer sizes
16:08:47 <cohosh> we did this before with kcp i think,
16:09:03 <dcf1> KCP we did: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40026
16:09:21 <dcf1> SetWindowSize 32 -> 1024
16:09:47 <dcf1> I think increasing smux MaxStreamBuffer is the most important setting, and it will probably have a bigger effect than kcp SetWindowSize.
16:09:55 <cohosh> i have some scripts written for snowflake performance testing somewhere
16:10:03 <cohosh> that's great news
16:10:33 <dcf1> 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 <cohosh> maybe it'll make snowflake#25723 actually useful
16:11:19 <dcf1> yes, perhaps
16:12:47 <meskio> it looks like we have an agreement to increase the buffer size, who will send a merge-request?
16:13:43 <cohosh> it looks like there's a couple values to play with
16:13:54 <cohosh> so we could make a new ticket and I can run the performance scripts i have
16:14:03 <dcf1> I think the idea needs some experimentation and testing, which is the annoying part.
16:14:19 <cohosh> and test it with the multiplexing nsowflakes
16:14:20 <dcf1> I wasn't planning to submit an MR myself, just wanted to post my observations so far.
16:14:43 <cohosh> heh this was exactly what snowflake#40026 was for, but we didn't really have time to dig into it
16:14:56 <dcf1> 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 <cohosh> i think with these observations now that we have some concrete values to try we can move forward on it
16:15:15 <cohosh> sounds good
16:15:35 <cohosh> it's easy to test configs at the client in production but harder at the server
16:15:46 <cohosh> so maybe we can make a guess, deploy it at the server and run some tests
16:15:55 <cohosh> and if they aren't good enough, try something else
16:16:08 <cohosh> we also have a beefier server machine now :)
16:16:18 <meskio> nice :)
16:16:42 <dcf1> snowflake#40051
16:17:53 <meskio> good, should we continue in #40026 or a new issue? or do we need to talk more about it here?
16:18:54 <meskio> I assume silence means let's continue
16:19:08 <meskio> I just added another point to the agenda
16:19:46 <meskio> 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 <dcf1> I forget where I saw you posted that link earlier, meskio, but I read it and it was interesting.
16:19:59 <dcf1> https://ooni.org/post/making-ooni-probe-android-more-resilient/#changing-our-android-tls-fingerprint
16:20:30 <meskio> specifically in android, there the cypher suite is different and produced some false positive, they think for another circunvention tool
16:20:49 <meskio> I'm wondering if snowflake could have the same problem
16:21:01 <dcf1> Yeah and the ciphersuite ordering depends on whether golang detects hardware AES acceleration at runtime, something like that?
16:21:06 <meskio> I would expect DTLS not to be in the same blocking list than TLS, but who knows
16:21:16 <meskio> dcf1: exactly
16:21:23 <dcf1> So we have some information about this regarding snowflake.
16:21:28 <meskio> OONI people had patched the golang TLS implementation to change that
16:22:01 <dcf1> 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 <dcf1> I am a coauthor of https://arxiv.org/abs/1605.08805, and DTLS fingerprinting is mentioned in Section 2 and 5.
16:23:16 <meskio> here is an issue about this fingerprinting paper, and I did add the ooni link to the issue
16:23:27 <cohosh> nice!
16:23:31 <dcf1> 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 <meskio> but I didn't check if your paper contains already this info and is duplicated, sorry
16:24:18 <meskio> the related issue: snowflake#40014
16:24:22 <dcf1> Another point, for TLS fingerprinting in general, see https://tlsfingerprint.io/ and https://tlsfingerprint.io/static/frolov2019.pdf.
16:25:25 <dcf1> 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 <dcf1> uTLS is what is currently used for TLS camouflage of meek in Tor Browser (using obfs4's implementation)
16:26:27 <dcf1> OONI's writeup also mentioned uTLS as a possibility.
16:27:06 <anadahz> (hi!)
16:27:09 <meskio> I guess we should keep in mind this if we see snowflake being blocked on android devices somewhere
16:27:20 <dcf1> One last point, there is a TLS fingerprinting tool called JA3: https://github.com/salesforce/ja3
16:28:14 <meskio> is snowflake already deployed on android devices?
16:28:43 <dcf1> Ah, actually snowflake#40014 is a different (more recent) paper
16:29:30 <dcf1> https://arxiv.org/abs/2008.03254 not https://arxiv.org/abs/1605.08805
16:30:05 <dcf1> That's all for my short infodump about TLS fingerprinting.
16:30:15 <meskio> :)
16:30:31 <dcf1> 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 <dcf1> There is also the issue that not all WebRTC sessions use DTLS -- media streams use different encryption.
16:31:32 <dcf1> This is "Media vs. data transport" at https://arxiv.org/pdf/1605.08805.pdf#page=2
16:31:54 <anadahz> meskio: Do you know which countries used to block OONI probes?
16:32:39 <meskio> if they say it I missed it, but I guess we can ask them
16:33:05 <meskio> not sure why is not in their blogpost neither in the issue
16:33:33 <anadahz> Also did they block access to everyone trying to access OONI's backend, all only traffic from OONI probes (tricky)?
16:33:59 <meskio> only android ooni probes connecting to the backend
16:34:10 <meskio> the blocking was not targeted to ooni, or that is what they thing
16:34:17 <meskio> s/thing/think/
16:34:41 <meskio> they believe the censor was blocking something else that also uses golang TLS implementation and as side effect they got blocked
16:35:41 <anadahz> ah interesting, do you know what the censor tries to block?
16:35:42 <dcf1> 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 <meskio> anadahz: I did ask them, and they were not sure, there are many anti-censor tools using golang, psyphon for example
16:36:27 <dcf1> Psiphon uses uTLS, I believe. At least they are active in the uTLS repository.
16:36:50 <meskio> maybe that is the reason they use uTLS...
16:37:14 <anadahz> maybe there is an open ticket in the golang TLS repo.
16:37:57 <meskio> I didn't see any linked from ooni issue, but I didn't search for it
16:37:57 <dcf1> 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 <meskio> I guess we should keep an eye if we see snowflake being censored in android
16:38:58 <meskio> anything more to talk about this topic?
16:39:37 <dcf1> btw dtls is not in the golang standard library, we get it from pion: https://github.com/pion/dtls
16:39:54 <dcf1> Maybe pion forked crypto/tls for it or uses crypto/tls internally, I don't know.
16:40:10 <meskio> ohh, nice, we might be off the hook, or easier to fingerprint
16:42:13 <meskio> alright anyone need reviews that aren't already assigned?
16:43:36 <meskio> that seems like no, I'll wait few minutes before ending the meeting :)
16:45:34 <ggus> 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 <meskio> they mentioned is not public, so please don't share it around
16:46:07 <ggus> it's still under development, so expect some bugs
16:46:16 <ggus> yep, also that!
16:47:18 <meskio> #endmeeting