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