15:58:51 <phw> #startmeeting anti-censorship team meeting 15:58:51 <MeetBot> Meeting started Thu Jun 25 15:58:51 2020 UTC. The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:51 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:54 <phw> good morning, everybody 15:58:57 <gaba> hi! 15:59:03 <phw> here's our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:04 <hanneloresx> hi everyone 15:59:07 <HashikD> Hey 15:59:38 <phw> how is everyone handling the transition to gitlab? any issues? 15:59:50 <cohosh> hi 16:00:22 <cohosh> heh i'm still getting used to it 16:00:31 <dcf1> I'm not sure what's the equivalent of the old needs_review/merge_ready/etc. states. 16:00:47 <gaba> dcf1: I think we should talk about review workflow here 16:01:03 <hanneloresx> i saw a workflow from network team. not sure if we're doing similar things here 16:01:12 <gaba> phw: can we add it to the agenda? on review workflow 16:01:19 <dcf1> Seems like there's a dichotomoy between issues and merge requests, and issues don't have such states maybe? So a workaround is to use labels on the issue? 16:01:19 <phw> gaba: already on it 16:01:23 <gaba> :) 16:01:40 <gaba> dcf1: right. that is what the network team is doing 16:02:05 <gaba> this board has a stack for needs_review: https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards 16:02:08 <gaba> that is the label 16:02:18 <phw> to be clear: the network team is doing labels like 'needs review' because their code isn't on gitlab yet (and therefore merge requests are not possible) 16:02:18 <cohosh> my understanding is that the typical gitlab workflow is not use a needs_review label and just rely on the existence/state of merge requests 16:02:30 <cohosh> yeah 16:02:59 <gaba> yes 16:03:03 <phw> for bridgedb, cohosh and i did a merge request (because the code base is already on gitlab), so we didn't need labels. i just pointed cohosh to the merge request 16:03:51 <cohosh> (and i also got an email about it and it's in my to-do list on the actual site) 16:04:02 <gaba> phw, cohosh: in that case we have MR to get reviewed in https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests ? 16:05:02 <phw> what i'm not sure about is: should a branch for a merge request be pushed to the canonical repository? or is a user-specific fork also possible/desirable? 16:05:28 <phw> gaba: oh, that's neat 16:05:53 <cohosh> i think it's better to have branches in a user-specific fork 16:06:15 <antonela> yes, and someone with super powers merge to the canonical (that is the intent with websites) 16:06:16 <cohosh> since you need pretty high permissions to push branches to the main repository 16:06:18 <dcf1> I see, this boards page is much wider than it appears at first. 16:07:00 <phw> cohosh: makes sense. i tried the originally but must have messed up something 16:07:05 <phw> s/the/that/ 16:07:11 <gaba> so this is the query for all the merge requests that needs reviewers: https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&assignee_id=None 16:08:06 <phw> we should document our review process because this won't be the last time we're talking about it. i hear we will have our anti-censorship team wiki page soon 16:09:00 <gaba> yes 16:09:22 <cohosh> okay so to be clear, the plan on that is to make a "team" project and put all of our existing trac wiki pages there? 16:09:41 <gaba> cohosh: that is my proposal 16:09:46 <gaba> other teams are doing that 16:09:51 <cohosh> cool, that sounds good to me 16:09:54 <gaba> s/teams/groups 16:10:03 <antonela> like https://gitlab.torproject.org/tpo/ux/team 16:10:26 <antonela> https://gitlab.torproject.org/tpo/ux/team/home 16:10:26 <cohosh> antonela: nice! 16:10:27 <phw> dcf1: does the above answer your question? 16:10:43 <antonela> cohosh: (: still copy and pasting things 16:12:02 <dcf1> I think I will have to figure it out by doing. 16:12:26 <cohosh> dcf1: ahf just set it up to mirror the nsowflake gitweb repo to the gitlab 16:12:34 <cohosh> but we have to push to it in order to start the sync 16:12:41 <phw> one can assign a person to a merge request. my understanding is that this person should be the reviewer, but maybe i'm mistaken. 16:12:49 <gaba> right 16:12:56 <cohosh> it will go here: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake 16:13:11 <cohosh> phw: i think that's right 16:13:30 <cohosh> and then it's easiest if we mention the issue # in the merge request 16:13:54 <cohosh> https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/#code-review-with-gitlab 16:14:08 <phw> right, then it shows up in the issue's "timeline" 16:14:26 <cohosh> idk how closely we want to follow this guide but it's worth taking a look at 16:14:35 <cohosh> since i believe it's gitlab's intended workflow 16:15:38 <phw> oh, neat. i haven't read the document yet but i'm a fan of following their workflow unless we have a good reason not to 16:15:49 <cohosh> yeah same 16:17:08 <gaba> I want to add templates for issues to all repos but will send a proposal when I have something more specific 16:17:11 <phw> gaba: when can/should we phase out gitweb.tp.o? i don't mind pushing bridgedb code to several repositories but i won't be using gitweb.tp.o anymore 16:17:38 <gaba> I think we should sync with ahf on how he and hiro and anarcat are doing mirroring 16:17:54 <phw> (by "not using" i mean that i consider the gitlab repo to be the canonical one) 16:17:57 <gaba> I can talk with them next week and loop you in 16:18:01 <gaba> yes 16:18:08 <phw> ok, thanks 16:18:09 <gaba> I think that would be the ideal 16:18:26 <cohosh> oh i didn't know we were going to phase that out 16:18:27 <gaba> If we do that let's be sure we all agree on the roles and permissions in the group and the repositories 16:18:33 <gaba> as that affects more than the issues 16:18:47 <gaba> cohosh: sysadmins want us to do that but it will require more time 16:18:52 <cohosh> phw: ahf set it up so we push to gitweb.tp.o and it's mirrored on gitlab 16:19:08 <cohosh> i suppose we could reverse the mirror? 16:19:52 <phw> i have already been pushing bridgedb code to three repositories. might as well make it five for now 16:20:30 <phw> anything else related to gitlab? 16:20:34 <gaba> ahf is also looking into how to run CI on the repos in gitlab. Not sure if you all are talking with him about it 16:20:44 <cohosh> gaba: ah cool :) 16:21:01 <phw> oh, CI would mean i only have to push to four repositories 16:21:20 <gaba> :) 16:22:04 <HashikD> cohosh: I could work on CI too for Snowflake Mobile project too if you would like me to. 16:22:17 <cohosh> HashikD: nice! let's make a ticket for that :) 16:22:40 <HashikD> Sure 16:23:08 <phw> shall we move on with our agenda? 16:23:17 <phw> the next item is about moving snowflake issues 16:23:48 <cohosh> right 16:24:21 <cohosh> is the idea to move all issues with "snowflake-webext" or "snowflake-mobile" keywords to each of those projects? 16:25:55 <phw> are you asking anyone specifically? 16:26:07 <cohosh> idk who made this discussion point 16:26:13 <cohosh> i'm assuming they had a plan 16:26:13 <phw> me neither 16:26:20 <cohosh> lol okay well 16:26:28 <gaba> it was not me :) 16:26:32 <cohosh> i'm for it if we can figure out how to do it 16:26:40 <cohosh> i'll reach out to ahf later about it 16:27:05 <HashikD> If wanted to make a bulk move it's we have to write a script it seems Reference: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#moving-issues-in-bulk 16:28:21 <HashikD> cohosh: Can I move all Snowflake-mobile issues to the corresponding project? it'll be easier that way to make PRs. 16:28:21 <cohosh> okay i'll check in with ahf to make sure we're not stepping on his toes here. he might also have an easy way to do it 16:28:29 <cohosh> HashikD: did you make this discussion point? 16:28:33 <phw> thanks cohosh 16:28:42 <HashikD> cohosh: Not me. 16:28:50 <cohosh> HashikD: okay. let me check in with ahf then 16:28:54 <cohosh> and get back to you about it 16:29:02 <HashikD> Okay! 16:29:46 <gaba> ahf already has a script to bulk move issues 16:29:47 <phw> (my new hobby: adding random discussion points to other team's meeting pads and have fun watching them trying to figure it out) 16:29:56 <gaba> lol 16:29:57 <cohosh> lol 16:30:17 <HashikD> xD 16:30:47 <phw> ok, let's move on to reviews 16:32:00 <phw> i could use a review for my (wip) #34260 branch and cohosh needs #34129 and #3780 16:32:15 <phw> i already started with #3780 but need a bit more time 16:32:21 <cohosh> phw: i have #34260 in my todo list i think 16:32:28 <phw> cohosh: perfect, thanks 16:33:10 <cohosh> okay i think i'm good then, since dcf1 is gonna take a look at #34129 16:33:18 <phw> ok, great 16:33:24 <cohosh> btw, do we have a new way to reference PRs/issues? 16:33:27 <cohosh> in irc 16:33:38 <phw> hanneloresx: i see that the riseup pad assigned you the best colour. i'm jealous 16:33:49 <hanneloresx> phw: :P 16:34:04 <phw> hanneloresx: also, i still owe you an email with tickets. i'm 95% sure that it'll come today, sorry about the delay 16:34:26 <dcf1> let me try one that postdates trac: #40001 16:34:29 <hanneloresx> phw: no worries. I probably won't have much time to take a look until the weekend 16:35:03 <cohosh> dcf1: the problem is, there will be several #40001 tickets heh 16:35:09 <cohosh> one for each project 16:35:27 <dcf1> yeah, bugs.torproject.org permalinks are not useful for new tickets I guess 16:35:31 <gaba> before #4000 all the ticket numbers are unique and come from trac 16:35:42 <gaba> for new tickets we need the namespace of group/project 16:35:49 <phw> silver lining: multiple people get to file #31337 16:36:27 <cohosh> phw: i don't think so, they all start at #40000, right? 16:36:33 <phw> aww :( 16:36:33 <gaba> right 16:36:39 <cohosh> :P 16:36:55 * phw shakes fist at ggus 16:37:29 <phw> ok, we're done with reviews. shall we move on to the reading group? anything else before we do so? 16:37:41 <cohosh> not from me 16:37:45 <arlolra> phw, cohosh: sorry, I added the discussion point about the moving issues, but I'm not really around 16:38:02 <cohosh> arlolra: oh! nice, okay. yeah i'll talk with ahf about that 16:38:09 <arlolra> ty 16:38:12 <cohosh> but it sounds possible and like a good idea 16:38:57 <phw> so, today's topic is the geneva paper: https://censorbib.nymity.ch/#Bock2019a 16:39:06 <phw> i can provide a short summary 16:39:39 <phw> a censor's deep packet inspection systems aren't perfect and are fundamentally unable to fully reconstruct the state between a client and server 16:39:49 <phw> we know this since at least 1998: https://insecure.org/stf/secnet_ids/secnet_ids.html 16:40:36 <phw> by manipulating a client and/or server's tcp/ip behavior, one can often fool these deep packet inspection devices. we have exploited this a few times, eg with the brdgrd tool, which manipulated tcp's window size 16:41:05 <phw> some of these tcp/ip tricks can be effective but the problem is that discovering and deploying such evasion strategies takes a lot of manual work 16:41:27 <phw> this is where geneva comes in: it automates the discovery part (but the deployment part still takes work) 16:41:49 <phw> the idea is to let a genetic algorithm do all the work. it evolves successful circumvention strategies against a real censor 16:42:22 <phw> the authors tested geneva against deep packet inspection systems in china, india, and kazakhstan, and found a bunch of evasion strategies 16:42:45 <phw> that includes evasion strategies we already knew, but also previously unknown evasion strategies, which is exciting 16:43:08 <phw> that's the end of my summary 16:43:58 <dcf1> more recently, Geneva has also been applied in Iran: https://geneva.cs.umd.edu/posts/iran-whitelister/ 16:45:08 <cohosh> that is very cool 16:45:33 <dcf1> I'm am not sure what inspired the genetic algorithm approach, but it finds some good stuff. 16:46:02 <phw> what makes geneva a bit difficult to use for us is that we still need to deploy the evasion strategies 16:46:04 <gaba> this is to find new evasion strategies but not to circumvent, right? 16:46:28 <dcf1> it reminds me of a software fuzzer, in how quickly it finds a lot of whacky inputs 16:47:00 * phw imagines a PT that uses geneva to find evasion strategies on the fly 16:47:16 <cohosh> gaba: yeah 16:47:18 <dcf1> And it's true that a lot of the strategies would not have been considered a priori by a human. "This strategy works by sending *nine copies* of the ACK packet during the 3-way handshake." 16:47:29 <cohosh> i'm not sure evasion on the fly is desirable either 16:47:35 <dcf1> gaba: there is another component to apply the strategies. 16:48:13 <dcf1> Actually the circumvention part is the only part they have released so far. The actual genetic algorithm part is (still) private. https://github.com/Kkevsterrr/geneva 16:48:47 <cohosh> huh why is it private? 16:50:00 <cohosh> so they released a tool that implements the strategy their genetic algorithm found, but not the algorithm? 16:50:06 <cohosh> *strategies 16:50:06 <dcf1> right 16:50:46 <dcf1> my understanding is you feed to tool a file full of strings like https://github.com/Kkevsterrr/geneva/blob/master/strategies.md and then it acts as a traffic-manipulating proxy. 16:51:37 <phw> sounds like fte, but for packet manipulation rather than payload generation 16:52:17 <dcf1> Yes sort of, I do find it appealing that they have a textual serialization format for strategies. 16:54:00 <cohosh> i love reading what the actual strategies are 16:54:00 <phw> unfortunately, it doesn't run on windows, or any platform other than linux because of its libnetfilter_queue dependency 16:54:16 <cohosh> "send two FIN packets *before* the TCP handshake" 16:56:19 <gaba> a presentation on Geneva in youtube: https://www.youtube.com/watch?v=R9TWLO5N7mc&feature=youtu.be 16:57:11 <dcf1> Tor has never deployed a pluggable transport using this kind of evasion. 16:57:36 <dcf1> Part of the problem is, as phw said, that implementation is often platform-specific and probably requires elevated privileges. 16:58:02 <cohosh> it is also very specific to the region/censor policies that the client is in 16:58:08 <dcf1> But I understand that https://github.com/ValdikSS/GoodbyeDPI is an existing system that uses these sorts of evasions. I could be wrong; maybe it only does HTTP header manipulation and such. 16:58:44 <dcf1> https://github.com/ValdikSS/GoodbyeDPI#active-dpi "TCP-level fragmentation for first data packet" "TCP-level fragmentation for persistent (keep-alive) HTTP sessions" "Replacing Host header with hoSt" 16:59:01 * cohosh wants to read up on goodbyedpi more, maybe for a future reading group 16:59:03 <dcf1> And GoodbyeDPI actually has users, showing that a circumvention system based on ideas like this can be successufl. 16:59:05 <phw> there's also vecna's sniffjoke: https://github.com/vecna/sniffjoke 17:00:51 <phw> we could work around the portability issue by using a userspace tcp stack but that would come with its own problems. it's complex and can be fingerprinted by the censor 17:01:19 <cohosh> how difficult would it be to modify the genetic algorithm approach in geneva to detect server-side fixes? 17:01:35 <cohosh> since at Tor we have people connecting to relays/bridges anyway instead of directly to sites 17:04:35 <phw> at the very least, i would imagine it to require some (complex?) coordination with a client, so you can comprehensively test your way through the tcp handshake 17:05:07 <phw> that's a fine question for dave levin, though 17:05:29 <phw> (he responded to the symtcp thread on our mailing list) 17:05:52 <cohosh> yeah 17:06:12 <cohosh> because that would be cool, if we had a PT where the bridge did all the work 17:06:24 <cohosh> i think we discussed this last time during the sym tcp discussion 17:06:35 <phw> absolutely. most of our bridges already run on linux 17:08:36 <phw> any other thoughts or questions? 17:10:17 <gaba> are you all answering the questions in the pad? :) 17:10:22 <phw> on a more general note: what are your thoughts on our reading group format? i'm asking because i found it difficult to take a careful look at our last two or three readings 17:11:31 <dcf1> I didn't do any extra reading this time because I had already read and summarized this paper. 17:11:42 <dcf1> I think I may have to skip the next few because of other paper reviews I have to do. 17:12:16 <phw> my problem was/is that one week is not much time to find enough time to read a paper 17:12:34 <hanneloresx> maybe we can decide the next reading this time, so we have 2 weeks 17:12:54 <cohosh> yeah 17:13:01 <cohosh> it might also be 2 weeks is too often 17:13:08 <cohosh> i wouldn't mind 1x a month 17:13:31 <phw> hanneloresx: agreed. imo, we don't have to follow our 2-week-cycle religiously. if nobody suggests a paper right away, we can skip a week 17:14:17 <phw> that said, does anyone have a suggestion for our next paper or project? :) 17:14:39 <cohosh> goodbyeDPI? 17:14:48 <phw> yes, good idea 17:15:52 <phw> i think we're all set for today. anything else before i close the meeting? 17:15:59 * phw waits for two minutes 17:17:46 <phw> #endmeeting