16:04:54 <Yawning> #startmeeting pts
16:04:54 <MeetBot> Meeting started Wed Sep 24 16:04:54 2014 UTC.  The chair is Yawning. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:54 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:05:16 <Yawning> Hihi, I see dcf1 and blanu, anyone else here for the pet meeting?
16:05:56 <blanu> n8fr8: Are you around for the PT meeting?
16:06:01 <Yawning> *tumbleweeds* *crickets*
16:06:07 <dcf1> Let me talk.
16:06:11 <dcf1> I don't have too much.
16:06:12 <Yawning> go for it
16:06:12 <n8fr8> Haha, oh yes! It was on my calendar thing.
16:06:19 <blanu> Great!
16:06:28 <Yawning> oh good n8fr8 is here
16:06:29 <atagar> karsten: Your 'if event.purpose == [tons of stuff]' conditional should instead be 'if event.purpose in (foo, bar, other thing):'.
16:06:45 <dcf1> I got meek working on Microsoft Azure, which is Microsoft's cloud thingy, kind of like AWS.
16:07:04 <n8fr8> Similar pricing, flexibility, etc?
16:07:04 <kernelcorn> well done!
16:07:17 <Yawning> (Does it also set X-Forwarded-For?)
16:07:18 <nickm> Yawning: can you have a look at my libscrypt_trunnel branch some time?  It adds trunnel.
16:07:22 <dcf1> https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure
16:07:24 <dcf1> https://trac.torproject.org/projects/tor/ticket/13189
16:07:32 <Yawning> nickm: after the pt meeting sure
16:07:38 <dcf1> The nice thing about Azure it it's going to be free for a year because I applied for a special grant.
16:07:40 <nickm> thanks!
16:07:41 <infinity0> ah i'm here too
16:07:52 <Yawning> oh nice
16:07:56 <dcf1> The bad news is it won't be free after a year.
16:08:22 <infinity0> it's a trap!
16:08:29 <dcf1> So far I'm not sure we'll add it to the TBB with a "meek-azure", as long as meek-google and meek-amazon are working for people.
16:08:53 <dcf1> I think Azure is the most "industrial strength" of the ones we have working so far.
16:09:01 <atagar> karsten: Your three lines around 'if id not in self.circuits: self.circuits[id] = Circuit(id)' can be replaced with one: 'self.circuits.setdefault(id, Circuit(id)).add_event(event.hs_state, arrived_at)'.
16:09:11 <dcf1> In the CDN world, App Engine and AWS are still regarded as kind of hobbyist affairs.
16:09:38 <dcf1> If you want to try it, the bridge line is
16:09:42 <dcf1> Bridge meek 0.0.2.0:3 url=https://az668014.vo.msecnd.net/ front=ajax.aspnetcdn.com
16:09:46 <Yawning> do you have a rough idea on what pricing will be after a year?
16:10:09 <dcf1> https://azure.microsoft.com/en-us/pricing/details/cdn/
16:10:22 <dcf1> $0.12 to $0.19 per GB, about the same as the others.
16:10:34 <armadev> dcf1: have you learned how much load that bridge can handle? like, 10k users from china?
16:10:49 <atagar> karsten: Around 'isinstance(event, stem.response.events.CircuitEvent) or...' the isinstance() function can accept multiple types. For example: 'isinstance('hello', (int, str))'.
16:11:04 <dcf1> Which reminds me, I put out a call for an experienced bridge operator to run the bridge that the CDN forwards you to.
16:11:16 <Yawning> dcf1: on a kind of related note, the per-country per-pt usage stats is probably going to be a SponsorS deliverable :/
16:11:17 <armadev> did that work out? we can get one at waterloo or umn if not.
16:11:19 <atagar> karsten: EOF. That's all I'm spotting off the top of my head.
16:11:19 <dcf1> I think we'll be fine on that front as I got a few replies.
16:11:32 <karsten> atagar: wow, thanks!
16:11:42 <Yawning> (at least I put that in my e-mail to armadev)
16:12:05 <dcf1> I think the meek-server part of it will be fine, as Psiphon is already using it at quite a large scale.
16:12:42 <dcf1> Speaking of users, the other interesting thing we found is that it turns out your stats get mixed up if you run two pluggable transports on one descriptor.
16:12:48 <dcf1> https://lists.torproject.org/pipermail/tor-dev/2014-September/007483.html
16:13:08 <dcf1> I fixed that about a week ago for websocket and meek.
16:13:11 <dcf1> https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&start=2014-06-26&end=2014-09-24&transport=websocket&transport=meek#userstats-bridge-transport
16:13:21 <dcf1> See if you can guess where it changed.
16:13:43 <dcf1> karsten says the right way to fix the problem is to fix #8786.
16:13:57 <dcf1> But for now I just started running two tor processes
16:14:02 <dcf1> which actually is not even hard to do.
16:14:02 <Yawning> *adds to my list of stuff to do*
16:14:19 <dcf1> That is all I have to say.
16:15:11 <dcf1> Yawning, to answer your question about X-Forwarded-For, no Azure does not set it, because
16:15:48 <dcf1> you have to make your own outgoing connections (with e.g. Python, Curl); Azure's CDN is not one you can just point at an arbitrary domain.
16:15:52 <dcf1> It's like App Engine in that regard.
16:16:02 <Yawning> ahh gotcha
16:16:15 <dcf1> The Azure installation is running this WSGI: https://gitweb.torproject.org/pluggable-transports/meek.git/blob/e28a053e89b9fbdf83283203c26053a39fa72038:/wsgi/reflect.py
16:16:18 <armadev> for my PT part: i've just been signed up to do a one-hour keynote this coming tuesday, at a gathering of darpa / academics in dc.
16:16:22 <dcf1> It also works great with Arlo's PHP.
16:16:35 <armadev> the topic is "the arms race in censorship technologies"
16:16:42 <Yawning> oh boy
16:17:15 <Yawning> do you need anything from us for that?
16:17:57 <armadev> i'm not sure yet. if you have something, yes please. :)
16:18:11 <arlolra> dfc: I'm just a happy little coder.
16:18:16 <Yawning> aight
16:18:27 <n8fr8> So, we've moved Orbot over to 0.2.5.x so we can now do ScrambleSuit, I believe. Haven't done extensive testing on that front yet, but we will.
16:18:36 <Yawning> ok.
16:18:43 <Yawning> it should just work
16:18:53 <n8fr8> I am still waiting/hoping/dreaming for QR code support on bridges.tpo to make it easy to provision
16:19:00 <Yawning> with the caveat that brridgedb is handing out bridges that do not work
16:19:05 <Yawning> due to missing password
16:19:13 <n8fr8> ah
16:19:13 <Yawning> approx 1/7th of them will be broken this way
16:19:15 <armadev> n8fr8: you might like #13213 (won't be in tor until 0.2.6 though)
16:19:36 <armadev> n8fr8: do i remember correctly that orbot turns on 'disablenetwork' sometimes?
16:19:49 <n8fr8> yes. there was an issue fixed with that recently?
16:19:56 <armadev> n8fr8: oh, there was a blog question: where should orfox tickets go?
16:20:01 <n8fr8> regarding circuit construction.
16:20:07 <Yawning> but it's something that we'll address and doesn't directly affect orbot.
16:20:50 * asn is around
16:20:59 <infinity0> i think i will file a bug to ask tor to automatically use 4 hops for unauthenticated bridges
16:21:04 <Yawning> oh good, tag, you're it I'm not that good at running theese
16:21:26 <asn> infinity0: that's an interesting idea.
16:21:27 <Yawning> #2764
16:21:35 <Yawning> probably covers that
16:21:40 <infinity0> at the moment, meek is using an unauthenticated bridge, which means an mitm between the user and the bridge can figure out what the middle node is
16:21:41 <asn> a bit more generic.
16:22:04 <infinity0> there are two designs going forward on the PT side, but if tor automatically does a 4-hop for an unauthenticated bridge, both designs are possible
16:22:06 <Yawning> and I'm in the camp that all bridge circuits should be 4 hop
16:22:14 <n8fr8> armadev: that is a good question re: orfox bug tracking. i think I need to do some project clean up
16:22:43 <asn> (i can also do a bit of status report today)
16:22:59 <Yawning> uh, sure, go for it
16:23:00 <blanu> infinity0: What is an unauthenticated bridge?
16:23:08 <Yawning> blanu: no fingerprint
16:23:10 <infinity0> blanu: Bridge line without fingerprint, tor doesn't check it
16:23:13 <asn> i mainly worked on little-t-tor stuff again, but
16:23:25 <asn> during the week I did some work with hellais on the bridge_reachability test
16:23:37 <infinity0> we could also examine the case for meek, where the reflector (e.g. google/azure) can be authenticated via x509, but i am not sure if it is worth the effort
16:23:49 <asn> i debugged one OONI in China, which was choking because the test was so parallel that the OOM killer was getting raised.
16:24:12 <asn> hellais solved the problem by making the test less parallel (test less bridges simultaneously)
16:24:28 <asn> also, (not my status report but) sysrqb sent a big categorized list of bridges to hellais
16:24:42 <asn> which will be imported to the OONI meters.
16:25:20 <asn> i also did some sysadmin work on my bridge which is getting super CPU stressed
16:25:20 <armadev> infinity0: seems to me that you should want the "use a guard for your second hop
16:25:21 <Yawning> \o/
16:25:29 <n8fr8> armadev: brand new project here, to start separating it from orweb/orbot tickets: https://dev.guardianproject.info/projects/orfox-private-browser
16:25:33 <Yawning> asn: hmm, is that my fault?
16:25:36 <asn> i have a plan of putting a HAProxy in front of the bridge.
16:25:41 <asn> Yawning: no.
16:25:44 <infinity0> Yawning: for the 4-authenticated-hop scenario, you mentioned that you wanted the 2nd node to act as the guard. does that still satisfy all the security properties? i thought the trust you place in the guard is that it knows your IP address
16:25:51 <asn> Yawning: it's the same CPU usage as when obfsproxy was used.
16:26:08 <Yawning> infinity0: yeah, you pick the guard as normal
16:26:08 <infinity0> armadev: ah, what I just asked Yawning ^
16:26:10 <asn> i might get help from a friend and put a haproxy in front of the bridge, which will allow it to scale some more.
16:26:17 <asn> and that's it from me. the show must go on.
16:26:51 <Yawning> so you get a bridge from god knows where, and make a circuit to 3 hops the client picks
16:27:02 <Yawning> past the bridge
16:27:09 <Yawning> anyway, mine is also quick
16:27:11 <armadev> basically, you want the tor network to think you're a client
16:27:16 <armadev> or rather, to think your bridge is you
16:27:31 <Yawning> wrote a bunch of e-mails to try to nail down the SponsorS stuff
16:27:41 <armadev> if your circuits don't use guards, you're not acting like a tor user
16:27:43 <Yawning> obfs4proxy is in debian-unstable now
16:27:52 <Yawning> (yay)
16:27:58 <Yawning> thanks to Lunar^
16:28:28 <Yawning> I did the fix for #13213
16:28:43 <Yawning> and I just pushed a minor change to obfs4proxy that makes it easier for people to give bridge lines out
16:29:05 <Yawning> my plans for the next bit are, do another round of tor browser + obfs4 snapshots
16:29:12 <Yawning> try to get bridge people to run obfs4 bridges
16:29:21 <Yawning> and SponsorS stuff
16:29:45 <infinity0> at the moment, you use the same few set of bridges, so they act as if they're your guards
16:29:59 <Yawning> I also still need to figure out what our answer to the mobile side of obfs4 is going to be
16:30:11 <Yawning> but that's just code so >.>
16:30:22 <n8fr8> oh, it is so much more!
16:30:39 <Yawning> oh, obfs4 bridge lines are even more of a UX disaster than scramblesuit by the way
16:30:51 <blanu> Yawning: What do you mean by the mobile side of obfs4?
16:30:51 <Yawning> Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> node-id=1ecccfcb7bd67e3b0448210ea3d641911bfacd0f public-key=f59861f373c6ab174cb64a9c05af75a1b0cbbcacad33c9aa321117dbcf775d17 iat-mode=0
16:31:04 <Yawning> probably "how to build go code"
16:31:15 <Yawning> "for android"
16:31:16 <asn> Yawning: you could merge all the options up in a big blog. it's not like the users care.
16:31:25 <n8fr8> nice. well, we have two plans related to easing adoption of bridges 1) device to device sharing of bridge configs between friends/trusted peoples
16:31:28 <asn> Yawning: that would make it smaller, and more suspicious looking.
16:31:33 <Yawning> I am hoping qrcodes will fix it
16:31:56 <n8fr8> and 2) some other interesting mechanism that is better than email, but uniquely mobile somehow
16:32:11 <n8fr8> i.e. push notifications, or SMS or something of that variety
16:32:41 <n8fr8> and that very least, we should make it much easier to kick off the email to bridges@
16:33:14 <n8fr8> We are also investigating refactoring Orbot to be more modular
16:33:38 <n8fr8> breaking out into a libAndroidTor and libAndroidPT for example
16:33:57 <n8fr8> since there is using both by other apps, outside of just Orbot
16:34:13 <Yawning> asn: I might try to coerce base64 back in again somehow
16:35:54 <blanu> I have some updates as well. Can I jump in now?
16:35:55 <n8fr8> Yawning dcf1 will be reaching out to you in coming weeks/months on using obfsclient, meek, etc w/o Tor managing them
16:36:13 <Yawning> yeah, I was gonna write an externalizer
16:36:19 <Yawning> blanu: go for it
16:36:37 <blanu> So I documented the Dust handshake protocol. In this process I found some places where it differs necessarily from the ntor paper, so it would be nice to have someone take a look at that. I will be sending that out soon for people to read.
16:37:01 <blanu> Next step for documentation is the API. So that's what I'm working on now.
16:37:26 <n8fr8> blanu: is there are project tracker/wiki for Dust?
16:38:01 <blanu> On the code side, I have a couple of blockers. First, I am going to be getting another programmer, contracted through Guardian, to help on some of the PTs-on-Android stuff.
16:38:22 <blanu> n8fr8: There is a github: https://github.com/blanu/Dust
16:38:45 <Yawning> pts on android should be in ok-shape right now
16:38:59 <Yawning> if not it's my fault and I'll fix things
16:39:20 <blanu> The second is that we need some consensus between Yawning, n8fr8, and myself as to whether we will be using obfsclient or obfs4proxy.
16:39:54 <n8fr8> python on android is still not a real possibility
16:39:57 <blanu> Yawning: Well specifically I should have said "getting Dust to run on Android as a PT inside of obfsclient/obfs4proxy". I am going to work more on core Dust stuff.
16:40:05 <Yawning> ahh gotcha
16:40:16 <blanu> n8fr8: This is why I'm glad you're here, because this is a surprising statement to me!
16:40:23 <n8fr8> well, last time I looked hard. technically possible, but for end-user bundling/adoption is tricky.
16:40:45 <Yawning> last time I looked at it it seemed like ab it of a mess
16:40:49 <n8fr8> i would love to be proven wrong and solve it, in a way that doesn't require a 20MB runtime
16:40:59 <Yawning> but that was a long time ago, before I wrote obfsclient
16:41:09 <n8fr8> yes, and fortunate for us we have an angel (Yawning) that solved it for us :)
16:41:23 <blanu> So then there are three possible platforms under consideration. We need to pick one before I can start building a PT. Also, for Dust we will need to provide a server, so that is part of the trade-offs in choosing the client platform.
16:42:26 <n8fr8> maybe python-for-android has improved: https://github.com/kivy/python-for-android will do some digging
16:42:31 <blanu> So I don't know how to move this decision process forward, but at least we have all of the stakeholders in a conversation about it now.
16:43:27 <blanu> Ultimately Guardian has to decide what they want to ship, but it would be handy if I could be in that conversation since the choice of platform determines how hard my job of writing a Dust PT will be.
16:43:31 <karsten> armadev: you need something for a presentation, right? how about something simple like https://people.torproject.org/~karsten/volatile/cells-pos-type.jpg ?
16:44:13 <dcf1> What would be easiest for you, blanu?
16:44:14 <armadev> karsten: yeah that looks good
16:44:23 <blanu> n8fr8: So what are you feelings on obfs4proxy? That's the new option that wasn't around the last time I considered PTs on Android.
16:44:47 <jcam> blanu: well, Dust-as-a-PT is slightly differentiated from Dust-as-a-PT-that-works-on-Android, yes?
16:45:28 <karsten> armadev: cool. I can write that graph code tonight. let me know when you have some numbers for me.
16:45:58 <blanu> dcf1: Well obfsclient already works on Android, which is a plus, but there is no server side. obfs4proxy looks attractive. pyobfsproxy I am worried about getting to build on Android.
16:46:30 <n8fr8> blanu: what do you mean there is no server side?
16:46:39 <blanu> jcam: A Dust PT that works on Android should work everywhere. For purposes of this particular project I am only worried about Android.
16:46:46 <Yawning> well, obfsclient is "client" >.>
16:47:03 <dcf1> The server side doesn't necessarily have to be the same platform; i.e., doesn't have to run on Android.
16:47:45 <n8fr8> Otherwise, I think we need to do some hands-on testing of the latest python-for-android schemes and see if A) it builds without too much hassle B) it doesn't add a huge amount of size to the resulting app and C) there is no performance impact
16:47:54 <dcf1> The server side could easily be pyobfsproxy if that's the easiest.
16:48:03 <blanu> n8fr8: obfsclient is C++, but there is no C++ obfsserver. So for a Dust PT that uses obfsclient we will also have to write a server-side PT using py-obfsproxy. So that's twice the work implementing both sides of a PT.
16:48:21 <n8fr8> right.
16:48:51 <Yawning> blanu: I'd need to see the wire protocol to really comment on a bunch of stuff
16:48:58 <blanu> With obfs4proxy or py-obfsproxy, it is less work to implement both sides.
16:49:06 <Yawning> specs aren't availabel anywhere yet right?
16:49:12 <blanu> Yawning: I will be sending you those docs today.
16:50:09 <blanu> So let me just float this idea then: Why not obfs4proxy? It has some attractive qualities.
16:50:46 <blanu> Builds on Android, has both client and server, and I think probably a smaller runtime than pyobfsproxy.
16:51:48 <blanu> I guess once obvious downside is that it does not implement all of the same transports as obfsclient, which is what Guardian is using now.
16:51:56 <Yawning> well, that can be fixed
16:52:09 <Yawning> implementing scramblesuit as a client isn't hard
16:52:14 <Yawning> >.>
16:52:49 <Yawning> that's the only missing one
16:53:03 <blanu> So I feel like what I'm hearing is 1) n8fr8 wants to try out py-obfsproxy and see how it does and 2) Yawning is down for anything. This all sounds good to me.
16:53:17 <Yawning> indeed
16:53:28 <blanu> So I'll send out the Dust protocol docs to everyone and we can go from there.
16:53:31 <blanu> That does it for me.
16:53:50 <jcam> blanu, n8fr8: I'd encourage making the choice based on long-term value over the specifics of the sponsor here; there's flexibility if we need it in terms of specific PTs on Android. It'd be great to add Dust, but if Dust-on-Android is going to be very difficult, we can re-visit
16:54:03 <Yawning> my local time is kind of screwed up, so it may be a day ish before I can look at docs
16:54:10 <jcam> (I feel like I need to curl my mustache or something when I say things like that)
16:54:18 <Yawning> (as in, localtime for me is Far East Asia)
16:54:38 <n8fr8> oh sorry blanu, let me clarify.
16:54:44 <armadev> jcam: it sounds like if we go with obfs4proxy we can consume all the cake
16:54:50 <n8fr8> If obfs4proxy/golang is an option, then we should do that
16:55:25 <Yawning> I haven't looked at golang on android, but unless Dust is extremely exotic, obfs4proxy should be an ok base/framework
16:55:34 <Yawning> for a new pt implementation
16:55:47 <blanu> jcam: I don't think Dust-on-Android is particularly challenging. I think the challenge is in the multiple PT platforms with different trade-offs. All PTs must face these same issues.
16:56:23 <Yawning> yeah, the reason obfs4proxy exists was "I need an elligator library" >.>
16:56:31 <blanu> I have looked at Go on Android and it seems fine.
16:56:39 <n8fr8> Yes, I agree.
16:56:40 <blanu> Yawning: But you wrote an elligator library! In C++!
16:56:44 <jcam> armadev: I am in favor of all the cake, and it does seem like obfs4proxy is particularly tasty cake, but it's not my place to decide on cake specifics (though, for the record, I prefer red velvet)
16:56:44 <Yawning> that's no longer an issue at this point
16:56:50 <n8fr8> We can build binaries, and use them exactly was do obfsclient now.
16:56:52 <Yawning> blanu: after I finished obfs4 :P
16:56:57 <blanu> Oh I see.
16:57:06 <Yawning> I ported agl's from go to C++
16:57:28 <Yawning> n8fr8: oh, obfs4proxy will just work then
16:57:39 <jcam> armadev: perhaps part of the PT roadmapping can be some guidance on the various PT library support paths?
16:57:49 <n8fr8> as will meek we hope.
16:57:52 <Yawning> when using it as a client, it's basically exactly like obfsclient
16:57:53 <n8fr8> expect!
16:57:57 <armadev> yawning: what jcam said
16:58:03 <Yawning> yeah
16:58:16 <armadev> yawning: in fact, a table alongside the PT designs should be a "PT framework" table
16:58:23 <armadev> since we've got more than one now
16:58:43 <armadev> i guess that could go pretty deep though, with "supporting libraries" and soon you're listing openssl and then it all goes messy
16:59:02 <Yawning> I was thinking about how to do meek correctly on android
16:59:04 <armadev> so, cut it off at some reasonable point before it goes messy :)
16:59:04 <jcam> n8fr8: Psiphon I believe is doing some meek+android work fwiw
16:59:16 <jcam> Yawning: ^^
16:59:22 <n8fr8> okey doke.
16:59:28 <Yawning> just compiling meek-client may work but it'd look blatantly obvious
16:59:41 <Yawning> because of golang's tls implementation
16:59:57 <asn> Yawning: base32 maybe?
17:00:00 <Yawning> (no other client only supports ECDH suites)
17:00:25 <blanu> So it sounds like next steps here are to get obfs4proxy to compile on Android. If it's not too much trouble, we can move forward with replacing obfsclient with obfs4proxy and all of the necessary things that need to happen to make that work.
17:00:32 <Yawning> asn: it's the stupid equal sign thing, was gonna just add them on myself and allow base64 as an option since it's most compact
17:00:38 <blanu> In the meantime, I will maintain an agnostic attitude in developing the Dust API.
17:00:43 <Yawning> but tbh, and as needed
17:01:20 <asn> tor has a base64 without the padding
17:01:33 <asn> which means that maybe stem has a function for it too
17:01:36 <Yawning> blanu: my attitude towards this is, I am fundementally ok with anything, since I know all the codebases and protocols involved
17:01:38 <asn> ah no you are in golang
17:01:54 <Yawning> asn: it's easy if you know how bit the unencoded blob is supposed to be
17:02:04 <Yawning> I can just bolt on equal signs and see if it decodes
17:02:05 <blanu> Yawning: That's a great attitude to have.
17:02:33 <Yawning> eventually I (and maybe arma?) will need clarification on the admin side of things
17:02:45 <Yawning> but that's more armadev's expertise than mine
17:02:54 <Yawning> I just poke at code >.>
17:03:33 <Yawning> also scramblesuit in obfs4proxy would take like, a week or two max since the bulk of the bits I need are already there
17:03:47 <blanu> Oh I had an arma question. armadev: What is the sponsor code for this Guardian-Tor-Dust project? People are always talking about SponsorS and such. I wanted to get in on the lingo.
17:03:49 <Yawning> since obfs4 and scramblesuit are *really* similar under the hood
17:04:49 * dcf1 reins in the meeting to see if anyone else would like to speak.
17:05:05 <Yawning> I saw an infinity0 earlier, not sure if he's here now though
17:05:07 <jcam> blanu: I'm pretty sure at this point it's Sponsor-oh-no-not-again ;)
17:05:26 <infinity0> oh yes, the 3/4 hops thing was the only thing i had in mind
17:05:30 <dcf1> going once
17:05:32 <Yawning> oh ok
17:05:47 <Yawning> going twice
17:05:47 <infinity0> i still don't like the fact that it's 5 hops, but i'll need to think about the problem a bit more
17:05:58 <Yawning> #endmeeting *baf*