16:01:20 <Yawning> #startmeeting
16:01:20 <MeetBot> Meeting started Wed Oct 22 16:01:20 2014 UTC.  The chair is Yawning. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:20 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:28 <Yawning> ...
16:01:29 <Yawning> D:
16:01:42 <Yawning> Oh well.
16:01:50 <dcf1> You uttered a magic hashtag.
16:02:06 <dcf1> #etaoin #shrdlu
16:02:07 <Yawning> asn isn't going to be here today, so y'all are stuck with me.
16:02:16 <Yawning> Who's here for the PT meeting?
16:02:41 <Yawning> I see dcf1 and blanu, any others?
16:03:16 <Yawning> Well, guess we can hope people show up.
16:04:08 <Yawning> I've been in a hurry up and wait state for obfs4 deployment.  Latest and greatest is in Debian, the browser integration branch is good to go, and will be in the 4.5 alpha series of Tor Browser when it happens.
16:04:30 <Yawning> In other news I've been working on go-fw-helper, which is tor-fw-helper but different.
16:04:52 <Yawning> Having something that's less scary from a deployment standpoint would be cool for flashproxy.
16:05:00 <blanu> Is this obfs4proxy or obfs4 in obfsclient?
16:05:07 <Yawning> The fun can be tracked at https://trac.torproject.org/projects/tor/ticket/13338
16:05:14 <Yawning> obfs4proxy
16:05:30 <dcf1> I wanted to talk about go-fw-helper for a little bit.
16:05:37 <blanu> What is tor-fw-helper?
16:05:46 <Yawning> a nat-pmp/upnp client
16:05:51 <dcf1> So it has a hard-coded lease interval, right? (Just like tor-fw-helper does.)
16:06:03 <Yawning> it's in the tor source tree, but it pulls in scary library code thats.. sorta terribad
16:06:08 <Yawning> dcf1: yeah
16:06:20 <dcf1> I seem to remember hearing (I don't remember where, maybe on trac), that some routers have a bug
16:06:23 <Yawning> "indefinite", "1 week" or "2 hours" dpeending on the protocol
16:06:29 <dcf1> where they treat every lease as infinite.
16:06:37 <Yawning> kinda
16:06:45 <Yawning> there's a bug where, unless you request a indefinite lease
16:06:48 <Yawning> the router crashes
16:07:01 <Yawning> so everyone asks for indefinite ones when using UPnP 1.0
16:07:15 <Yawning> I changed the code back to do that just now
16:07:16 <dcf1> So I worry a little bit if we auto-select a port every time, and it ends up being infinite, and eventually we open up the whole firewall one port at a time.
16:07:33 <Yawning> nah, the table gets full and the upnp stack breaks horribly
16:07:36 <Yawning> before that happens
16:07:39 <dcf1> Okay, so I guess that means we have to be assiduous in sending "end lease" messages.
16:07:45 <dcf1> Oh, good :)
16:07:49 <Yawning> indeed
16:07:53 <Yawning> or use a set port
16:07:59 <dcf1> Or use a fixed port, yes.
16:08:09 <Yawning> the current architecture really isn't setup for proper lease management
16:08:09 <blanu> So this is for connecting to bridges behind firewalls?
16:08:19 <dcf1> However a fixed port makes it easy to port scan for flashproxy-client, and if we can mitigate that weakness we should.
16:08:23 <Yawning> yes, and flashproxy clients
16:08:24 <n8fr8> hello!
16:08:39 <blanu> n8fr8: Welcome!
16:08:50 <Yawning> dcf1: daemonizing it is on my "things to look into" list but I want the code to work first
16:08:50 <dcf1> I'm thinking of how we would handle this in client programs.
16:09:09 <Yawning> daemonize the helper, purge leases on termination
16:09:33 <dcf1> Have a loop that calls tor-fw-helper every 30 minutes (or whatever), send "end lease" in the SIGINT handler, and do what we need to to prevent ProcessTerminate on Windows from preventing use from sending it.
16:09:35 <Yawning> as a stopgap I'm extending the command line args to actually support purging leases
16:09:51 <Yawning> hmm
16:09:54 <dcf1> Oh, I didn't realize it wasn't in the interface already.
16:10:11 <Yawning> there's just get address and new lease currently
16:10:13 <Yawning> :(
16:10:32 <dcf1> tor-fw-helper's isn't the most convenient interface.
16:10:32 <Yawning> the backend code is easy-ish but a bunch of design decisions need to happen
16:10:37 <Yawning> indeed
16:10:51 <Yawning> hi n8fr8
16:11:03 <Yawning> anyway, shouldn't hold up the meeting with this, who wants to go next?
16:11:05 <dcf1> But let me be clear I think we should first build and deploy go-fw-helper so that it is compatible with tor-fw-helper, and not let it rot in a vague design phase for something better forever.
16:11:26 <blanu> I can go next.
16:11:29 <Yawning> dcf1: indeed, apart from "nat-pmp portability/misc cleanup" master is compatbile I think
16:11:36 <Yawning> or really close
16:11:40 <Yawning> ok, go for it ^_^
16:12:25 <dgoulet> is there someone here familiar enough with the FreeBSD kernel code that can point me to the place where Unix fd passing is handled?
16:13:10 <Yawning> (you ask this after I get rid of my references on my move)
16:13:20 <blanu> I've been working on the Dust API and I've had a revelation that the original plan for exporting a simple C API is not going to be viable. The Dust engine needs to keep a lot of internal state which it would have to pass back and forth over the C API. So instead I am constructed a very simple RPC protocol over stdin/stdout. Not sure if this is going to work better, but it was a simple solution.
16:13:38 <blanu> The upside is that for obfs4proxy we can have a straight Go API and ditch the C API intermediary.
16:13:58 <blanu> It does mean that Dust will be running as its own process. I'm not sure if this has any implications for Android.
16:14:19 <blanu> My understand is that obfs4proxy is already running as its own process from Tor. So maybe this is unproblematic?
16:14:43 <n8fr8> That is fine
16:14:49 <Yawning> should be ok, go's subprocess management is reasonably decent
16:15:22 <blanu> That's pretty much it for me. I'll keep working on the API until it seems suitable for integration into obfs4proxy or obfsclient. If anyone has any comments on the docs please let me know. https://github.com/blanu/Dust/raw/master/docs/DustSpecification.pdf
16:15:49 <Yawning> I still owe you review on that sorry, been busy
16:15:58 <blanu> Good to hear that everything should work fine. I am cautiously optimistic.
16:16:08 <blanu> Hey no problem, plenty of time still.
16:16:13 <Yawning> I've heard rumors of a kickoff meeting for this, but not sure if I'm going or not due to the international travel aspect
16:16:18 <n8fr8> I need to do some Go xcompiling experiments just to make sure I am fully comfortable with it all still
16:16:37 <n8fr8> yes... would be open to calling in via encrypted SIP/VoIP link?
16:16:50 <n8fr8> it can be arranged! :)
16:16:55 <Yawning> uh, not sure
16:17:01 <blanu> Yawning: Are you not in the US? I think the kickoff meeting is in the US.
16:17:17 <Yawning> yeah that's international for me :P
16:17:31 <Yawning> I moved a  few months bac
16:17:34 <blanu> Ah! I thought someone said you were in the US. Fair enough.
16:17:42 <n8fr8> Anyhow, happy to help facilitate there. Otherwise, my update is also a technical challenge
16:17:52 <Yawning> dgoulet: sys/kern/sys_generic.c
16:18:15 <n8fr8> We've been working on implementing an Android VPNService capability into Orbot which routes all packets through a tuntap interface
16:18:21 <n8fr8> we then use tun2socks to push packets into Tor
16:18:38 <n8fr8> as part of this, you have to mark sockets you don't want routed through the VPN as "protected"
16:18:43 <Yawning> If it comes to it I could probably write a pure go Dust implementation via sheer force of will, but we probably don't want to do that >.>
16:19:07 <Yawning> (But it is an option)
16:19:21 <n8fr8> our currently impl sets a localhost outbound proxy for Tor, that we then use toi mark all outbound sockets from that as protected
16:19:35 <Yawning> ooof
16:19:45 <Yawning> that won't play nice with PTs
16:19:50 <n8fr8> i am hoping we can come up with a solution both for Tor and PT's
16:19:57 <n8fr8> that invovles a "i just created a socket" callback
16:20:14 <n8fr8> so we can mark it protected, etc from there.
16:20:34 <Yawning> dest addr/port sufficient?
16:20:50 <n8fr8> possibly, as we can use that to look it up in the system etc
16:20:55 <Yawning> ah
16:21:07 <n8fr8> file descriptor?
16:21:14 <Yawning> you could make the current thing work with PTs but it requires me adding a bunch of code to obfsclient
16:21:21 <dcf1> Most of the PTs also support an upstream proxy.
16:21:22 <Yawning> (or using obfs4proxy)
16:21:29 <dcf1> Maybe you could do the same proxy trick.
16:21:36 <Yawning> yeah but they don't have the #8402 fix backported
16:21:47 <Yawning> and obfsclient doesn't yet >.>
16:21:47 <n8fr8> right, that is what i had seen
16:21:50 <n8fr8> okay
16:22:19 <n8fr8> so short term would be to fix that and add the config args/options, long term would be to implement a callback
16:22:21 <Yawning> it's sort of low priority, esp if obfs4proxy works on ndroid
16:22:25 <n8fr8> i can write up the socket created callback ticket
16:22:47 <Yawning> I have a pach for you that fixes that sec
16:23:01 <Yawning> it's in tor-0.2.6.x but I assume you don't want to use bleeding edge yet :P
16:23:05 <n8fr8> this is a nice to have for now, and not required within our scope for this new PT work
16:23:38 <Yawning> https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/patches/bug8402-master.patch
16:23:40 <n8fr8> otherwise, Orbot latest does use tor-0.2.5.x now in production so scramblesuit set is broadly supported
16:23:46 <Yawning> you're on 0.2.5.x right?
16:23:46 <n8fr8> not sure if I reported that before
16:23:50 <n8fr8> yes
16:24:02 <Yawning> that patch adds 8402 to 0.2.5.x
16:24:12 <Yawning> but needs the pt side support
16:24:27 <Yawning> but the failure is more graceful so it's probably worth applying
16:25:00 <Yawning> (also guess I need to put scramblesuit in obfs4proxy)
16:25:17 <n8fr8> ok thats all for now
16:26:11 <Yawning> n8fr8: someone was complaining on the tor blog about orbot not working with scramblesuit, but it works fine, dunno what was wrong
16:26:35 <Yawning> prolly a bridge that was down or something
16:26:57 <Yawning> Are there other people (or ther PT things to discuss)?
16:27:16 <dcf1> Just a little from me.
16:27:37 <Yawning> Shoot
16:27:54 <dcf1> Interesting thing, GFW recently (last 30 days) started DNS-poisoning the magic Akamai domain a248.e.akamai.net.
16:27:58 <dcf1> https://en.greatfire.org/https/a248.e.akamai.net
16:28:26 <n8fr8> dang
16:28:27 <dcf1> Someone suggested to me that it may have been in response to people hosting mirrors of circumvention software under that domain.
16:28:47 <dcf1> I don't think it hurts the meek/domain-fronting scenario, but it means we'll have to pick a different front domain.
16:29:08 <dcf1> And Akamai isn't deployed yet, so it's not a current issue anyway. But still interesting that it's blocked.
16:29:25 <dcf1> However note that it's DNS blocked, not IP blocked (you can click on one of the dates in the calendar).
16:30:00 <dcf1> IP blocking would be much less likely because of the number of services that go through that domain and the numbers of IPs it can resolve to (I heard tens of thousands?).
16:30:21 <dcf1> Other fun fact
16:30:53 <dcf1> GoAgent recently fixed their longstanding security bug where they install a CA with a known private key.
16:30:57 <dcf1> https://github.com/goagent/goagent/commit/77c8e7f131f9eb7d857cded9c0bc2f662e80b78a
16:31:15 <Yawning> hahahhahahaha
16:31:19 <Yawning> I forgot about that
16:31:22 <dcf1> I haven't been able to figure out exactly what prompted it after almost a year of them knowing about it.
16:31:30 <dcf1> Maybe the recent new MITM against Google and iCloud.
16:31:52 <dcf1> There is a repo of CA certs for Chinese users to blacklist (I think, I don't speak Chinese):
16:31:54 <dcf1> https://github.com/chengr28/AntiChinaCerts
16:32:03 <dcf1> And GoAgent's is on it too.
16:32:17 <dcf1> Last thing is meek usership since the 4.0 release.
16:32:22 <dcf1> https://trac.torproject.org/projects/tor/wiki/doc/meek#Users
16:32:31 <dcf1> Up up and away.
16:32:48 <dcf1> So far I haven't gotten any problem reports and the bridges are holding steady.
16:32:50 <Yawning> \o/
16:33:09 <dcf1> It reminds me that I should ask the help desk if they are starting to receive problem reports.
16:33:16 <Yawning> oh, so that's why people were complaining about not being able to edit tor browser's cert store
16:33:27 <dcf1> Yawning, yes I think so.
16:33:40 <dcf1> I hadn't realized, but I guess some people manually remove CNNIC every time.
16:33:52 <Yawning> playing the game of "which CAs we trust" is probably not great ;_;
16:34:01 <Yawning> but guess this deservs a ticket?
16:34:27 <dcf1> I dunno. I didn't read carefully what they were asking for.
16:34:30 <dcf1> That's all from me.
16:34:45 <Yawning> aight, unless there's more stuffs, short-ish meeting
16:35:07 <n8fr8> dcf1: wait so https://github.com/chengr28/AntiChinaCerts are pro-China or anit-China I am confused :)
16:35:25 <n8fr8> they certs for Chinese users to block that might be used for MiTM outbound through GFW?
16:35:41 <Yawning> looks that way
16:35:41 <dcf1> n8fr8, that's my understanding.
16:35:53 <dcf1> Google Translate does an okay job.
16:35:55 <n8fr8> so why is GoAgent's in there?
16:36:04 <n8fr8> oh... because the private key was public
16:36:05 <n8fr8> got it
16:36:11 <dcf1> The author of GoAgent is aware too, they retweeted this: https://twitter.com/chengr28/status/523128397677854721.
16:36:20 <dcf1> https://www.bamsoftware.com/sec/goagent-advisory.html
16:36:51 <n8fr8> tx
16:36:52 <dcf1> I'd like to update the advisory once I can verify that their fix works.
16:38:52 <Yawning> Welp
16:38:58 <Yawning> #endmeeting *blorch*