15:58:51 #startmeeting anti-censorship team meeting 15:58:51 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:54 good morning, everybody 15:58:57 hi! 15:59:03 here's our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:04 hi everyone 15:59:07 Hey 15:59:38 how is everyone handling the transition to gitlab? any issues? 15:59:50 hi 16:00:22 heh i'm still getting used to it 16:00:31 I'm not sure what's the equivalent of the old needs_review/merge_ready/etc. states. 16:00:47 dcf1: I think we should talk about review workflow here 16:01:03 i saw a workflow from network team. not sure if we're doing similar things here 16:01:12 phw: can we add it to the agenda? on review workflow 16:01:19 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 gaba: already on it 16:01:23 :) 16:01:40 dcf1: right. that is what the network team is doing 16:02:05 this board has a stack for needs_review: https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards 16:02:08 that is the label 16:02:18 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 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 yeah 16:02:59 yes 16:03:03 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 (and i also got an email about it and it's in my to-do list on the actual site) 16:04:02 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 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 gaba: oh, that's neat 16:05:53 i think it's better to have branches in a user-specific fork 16:06:15 yes, and someone with super powers merge to the canonical (that is the intent with websites) 16:06:16 since you need pretty high permissions to push branches to the main repository 16:06:18 I see, this boards page is much wider than it appears at first. 16:07:00 cohosh: makes sense. i tried the originally but must have messed up something 16:07:05 s/the/that/ 16:07:11 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 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 yes 16:09:22 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 cohosh: that is my proposal 16:09:46 other teams are doing that 16:09:51 cool, that sounds good to me 16:09:54 s/teams/groups 16:10:03 like https://gitlab.torproject.org/tpo/ux/team 16:10:26 https://gitlab.torproject.org/tpo/ux/team/home 16:10:26 antonela: nice! 16:10:27 dcf1: does the above answer your question? 16:10:43 cohosh: (: still copy and pasting things 16:12:02 I think I will have to figure it out by doing. 16:12:26 dcf1: ahf just set it up to mirror the nsowflake gitweb repo to the gitlab 16:12:34 but we have to push to it in order to start the sync 16:12:41 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 right 16:12:56 it will go here: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake 16:13:11 phw: i think that's right 16:13:30 and then it's easiest if we mention the issue # in the merge request 16:13:54 https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/#code-review-with-gitlab 16:14:08 right, then it shows up in the issue's "timeline" 16:14:26 idk how closely we want to follow this guide but it's worth taking a look at 16:14:35 since i believe it's gitlab's intended workflow 16:15:38 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 yeah same 16:17:08 I want to add templates for issues to all repos but will send a proposal when I have something more specific 16:17:11 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 I think we should sync with ahf on how he and hiro and anarcat are doing mirroring 16:17:54 (by "not using" i mean that i consider the gitlab repo to be the canonical one) 16:17:57 I can talk with them next week and loop you in 16:18:01 yes 16:18:08 ok, thanks 16:18:09 I think that would be the ideal 16:18:26 oh i didn't know we were going to phase that out 16:18:27 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 as that affects more than the issues 16:18:47 cohosh: sysadmins want us to do that but it will require more time 16:18:52 phw: ahf set it up so we push to gitweb.tp.o and it's mirrored on gitlab 16:19:08 i suppose we could reverse the mirror? 16:19:52 i have already been pushing bridgedb code to three repositories. might as well make it five for now 16:20:30 anything else related to gitlab? 16:20:34 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 gaba: ah cool :) 16:21:01 oh, CI would mean i only have to push to four repositories 16:21:20 :) 16:22:04 cohosh: I could work on CI too for Snowflake Mobile project too if you would like me to. 16:22:17 HashikD: nice! let's make a ticket for that :) 16:22:40 Sure 16:23:08 shall we move on with our agenda? 16:23:17 the next item is about moving snowflake issues 16:23:48 right 16:24:21 is the idea to move all issues with "snowflake-webext" or "snowflake-mobile" keywords to each of those projects? 16:25:55 are you asking anyone specifically? 16:26:07 idk who made this discussion point 16:26:13 i'm assuming they had a plan 16:26:13 me neither 16:26:20 lol okay well 16:26:28 it was not me :) 16:26:32 i'm for it if we can figure out how to do it 16:26:40 i'll reach out to ahf later about it 16:27:05 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 cohosh: Can I move all Snowflake-mobile issues to the corresponding project? it'll be easier that way to make PRs. 16:28:21 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 HashikD: did you make this discussion point? 16:28:33 thanks cohosh 16:28:42 cohosh: Not me. 16:28:50 HashikD: okay. let me check in with ahf then 16:28:54 and get back to you about it 16:29:02 Okay! 16:29:46 ahf already has a script to bulk move issues 16:29:47 (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 lol 16:29:57 lol 16:30:17 xD 16:30:47 ok, let's move on to reviews 16:32:00 i could use a review for my (wip) #34260 branch and cohosh needs #34129 and #3780 16:32:15 i already started with #3780 but need a bit more time 16:32:21 phw: i have #34260 in my todo list i think 16:32:28 cohosh: perfect, thanks 16:33:10 okay i think i'm good then, since dcf1 is gonna take a look at #34129 16:33:18 ok, great 16:33:24 btw, do we have a new way to reference PRs/issues? 16:33:27 in irc 16:33:38 hanneloresx: i see that the riseup pad assigned you the best colour. i'm jealous 16:33:49 phw: :P 16:34:04 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 let me try one that postdates trac: #40001 16:34:29 phw: no worries. I probably won't have much time to take a look until the weekend 16:35:03 dcf1: the problem is, there will be several #40001 tickets heh 16:35:09 one for each project 16:35:27 yeah, bugs.torproject.org permalinks are not useful for new tickets I guess 16:35:31 before #4000 all the ticket numbers are unique and come from trac 16:35:42 for new tickets we need the namespace of group/project 16:35:49 silver lining: multiple people get to file #31337 16:36:27 phw: i don't think so, they all start at #40000, right? 16:36:33 aww :( 16:36:33 right 16:36:39 :P 16:36:55 * phw shakes fist at ggus 16:37:29 ok, we're done with reviews. shall we move on to the reading group? anything else before we do so? 16:37:41 not from me 16:37:45 phw, cohosh: sorry, I added the discussion point about the moving issues, but I'm not really around 16:38:02 arlolra: oh! nice, okay. yeah i'll talk with ahf about that 16:38:09 ty 16:38:12 but it sounds possible and like a good idea 16:38:57 so, today's topic is the geneva paper: https://censorbib.nymity.ch/#Bock2019a 16:39:06 i can provide a short summary 16:39:39 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 we know this since at least 1998: https://insecure.org/stf/secnet_ids/secnet_ids.html 16:40:36 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 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 this is where geneva comes in: it automates the discovery part (but the deployment part still takes work) 16:41:49 the idea is to let a genetic algorithm do all the work. it evolves successful circumvention strategies against a real censor 16:42:22 the authors tested geneva against deep packet inspection systems in china, india, and kazakhstan, and found a bunch of evasion strategies 16:42:45 that includes evasion strategies we already knew, but also previously unknown evasion strategies, which is exciting 16:43:08 that's the end of my summary 16:43:58 more recently, Geneva has also been applied in Iran: https://geneva.cs.umd.edu/posts/iran-whitelister/ 16:45:08 that is very cool 16:45:33 I'm am not sure what inspired the genetic algorithm approach, but it finds some good stuff. 16:46:02 what makes geneva a bit difficult to use for us is that we still need to deploy the evasion strategies 16:46:04 this is to find new evasion strategies but not to circumvent, right? 16:46:28 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 gaba: yeah 16:47:18 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 i'm not sure evasion on the fly is desirable either 16:47:35 gaba: there is another component to apply the strategies. 16:48:13 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 huh why is it private? 16:50:00 so they released a tool that implements the strategy their genetic algorithm found, but not the algorithm? 16:50:06 *strategies 16:50:06 right 16:50:46 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 sounds like fte, but for packet manipulation rather than payload generation 16:52:17 Yes sort of, I do find it appealing that they have a textual serialization format for strategies. 16:54:00 i love reading what the actual strategies are 16:54:00 unfortunately, it doesn't run on windows, or any platform other than linux because of its libnetfilter_queue dependency 16:54:16 "send two FIN packets *before* the TCP handshake" 16:56:19 a presentation on Geneva in youtube: https://www.youtube.com/watch?v=R9TWLO5N7mc&feature=youtu.be 16:57:11 Tor has never deployed a pluggable transport using this kind of evasion. 16:57:36 Part of the problem is, as phw said, that implementation is often platform-specific and probably requires elevated privileges. 16:58:02 it is also very specific to the region/censor policies that the client is in 16:58:08 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 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 And GoodbyeDPI actually has users, showing that a circumvention system based on ideas like this can be successufl. 16:59:05 there's also vecna's sniffjoke: https://github.com/vecna/sniffjoke 17:00:51 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 how difficult would it be to modify the genetic algorithm approach in geneva to detect server-side fixes? 17:01:35 since at Tor we have people connecting to relays/bridges anyway instead of directly to sites 17:04:35 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 that's a fine question for dave levin, though 17:05:29 (he responded to the symtcp thread on our mailing list) 17:05:52 yeah 17:06:12 because that would be cool, if we had a PT where the bridge did all the work 17:06:24 i think we discussed this last time during the sym tcp discussion 17:06:35 absolutely. most of our bridges already run on linux 17:08:36 any other thoughts or questions? 17:10:17 are you all answering the questions in the pad? :) 17:10:22 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 I didn't do any extra reading this time because I had already read and summarized this paper. 17:11:42 I think I may have to skip the next few because of other paper reviews I have to do. 17:12:16 my problem was/is that one week is not much time to find enough time to read a paper 17:12:34 maybe we can decide the next reading this time, so we have 2 weeks 17:12:54 yeah 17:13:01 it might also be 2 weeks is too often 17:13:08 i wouldn't mind 1x a month 17:13:31 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 that said, does anyone have a suggestion for our next paper or project? :) 17:14:39 goodbyeDPI? 17:14:48 yes, good idea 17:15:52 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 #endmeeting